You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

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 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
  • We will see in this article how to repair the LDAP configurations

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.

Repairing the LDAP configurations after restoring the backup

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.

  • No labels