Things you should know before you start

  • Pre-requisites: having a backup of the VM in question done following this article: Backup your instance
  • Restoring a backup to a new VM while the old one still exists will break the LDAP configuration of both the original and the new VM (generally only an issue on EUMETSAT tenancies where LDAP is provided by default)
    • This happens because the VM is a clone of the original with all of its configuration, including LDAP, but the original is still there

Optional: delete the old/original VM before restoring

You can delete the original VM before beginning the restoration.  Keeping it has the advantage that you have know the restore works before you delete the original, but the disadvantage that there may be some clashes (e.g. with LDAP configuration) that you will need to manually repair.

If you choose to delete, make sure to tick the "Preserve backups" option on the deletion screen, or you won't have anything to restore from!

Restoring the backup to a new instance

Select the instance you want to restore, click on Backups, there you will see a list of backups so you can click on ACTIONS → restore

Once you click Restore, you will be asked if you want to restore to a new instance, then you can click on the RESTORE button, and, after that you will see a series of screens very similar to the ones you see when you create a new VM so you will be able to select the VM name, layout, plan, security group, etc.

Backup images do not retain information on the VM plan, security groups, network, etc - you will have to record this independently.

Also, when a VM is restored, it will very likely have a new IP address.


Repairing the LDAP configurations

Note that this is only necessary if the original VM exists at the time a new VM is restored from the backups.

This section mainly applies to EUMETSAT tenancies where LDAP is provided by default.  Some ECMWF tenancies may also use LDAP by opt-in.


Right after we restore the backup we are going to have this situation:

  • the new VM in failed state
  • the original VM apparently fine, but the DNS records in LDAP will be misconfigured (two records will exist in a round-robin configuration), preventing us from repairing the LDAP config in the new VM

Example: in the screenshot below the original VM is backup-test-01 and backup-test-02 is a new VM restored from a backup of the first one:

In order to fix this, we need to repair the original VM first, we can do that by clicking on the original VM, then ACTIONS → Run Workflow, that will show the dialog below where we should choose Enroll VM to LDAP.  This will re-do the LDAP configuration, which deletes the now-corrupted LDAP information on the server and recreates it fresh.

After that, to verify that everything worked fine, we should be able to see an item in the VM history like this:

Now that we have the original VM repaired, we should also repair the new VM.

Given that the new VM is in failed state, you are not going to be able to execute the Enroll VM to LDAP workflow:

To work around that, you can simply click on ACTIONS → Restart Server.  This will clear the failure flag.

Once the VM is up and Running again, you will be able to execute the Enroll VM to LDAP workflow in the same way you did for the original VM.  As a new VM, it must have a new and unique hostname and this will be registered in LDAP.