...
- 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.
| Warning |
|---|
| 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
...
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.
| Warning |
|---|
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.
| Info |
|---|
This section mainly applies to EUMETSAT tenancies where LDAP is provided by default. Some ECMWF tenancies may also use LDAP by opt-in. |
...