Skip to content

Restoring replicated VMs on a remote cluster

Prerequisites

For an overview and detailed explanation of the preliminary steps refer to the snapshot tutorial.

  1. Primary HyperCloud site dashboard is able to connect to the remote instance using SSH keys
  2. Create and configure the /var/run/cluster-control/facts/snapshot/remote.json file
  3. Add a SNAPSHOT_SCHEDULE to the Attributes header of the target VM (e.g. hourly:local=3,remote=6)

Initializing the replication

After an initial copy of the dataset is completed, the system will replicate new snapshots to the remote system on an hourly schedule, maintaining six (6) snapshots locally, and twelve (12) on the remote cluster.

An example replication schedule:

Remote replication

Snapshots will be taken at the top of the hour, every hour. Depending on the size of the VM, this may take some time to happen for the first replication.

Procedure to restore

On the remote HyperCloud instance (in the dashboard's web GUI), navigate to Storage → Marketplaces → HyperCloud Remote Backups, click the Apps button.

Once the first snapshot has completed, it will appear in the apps list (wait a few minutes and refresh the page if nothing has shown).

snapshot apps list

Info

The name of the snapshot is made up of various elements based on the source. In the example above: REMOTE-Master_Site-one-1-1-0-auto-v2-hourly-202310041100-1 - REMOTE refers to the snapshot being from a remote cluster - Master-site is the prefix set in the remote.json file - The first 1 is the image ID - The second 1 is the instance (or VM) ID - The 0 is the disk position (0 is the root or OS disk, see below for multiple disks) - auto denotes the type of snapshot - hourly is the period

Click on the desired restore point (date and time), this will open up more information about the snapshot.

Downloading the backup

Restoring the snapshot follows the same process as downloading a normal application from the marketplace.

  1. Click import which will bring up the screen below:

    download backup

  2. Change the name and template name if desired.

  3. Select a destination datastore and click download button

Multiple virtual disks

If the VM has a second (or more) virtual disks attached, these will appear as other 'Apps'.

For example, a source VM configured as so:

virtual disks

Will appear as seen below in the remote backups apps list in the marketplace:

multi disk

  • REMOTE-Master_Site-one-1-1-0-auto-v2-hourly-202310051000-1 where the third numeric 0 is present, signifies the OS disk
  • REMOTE-Master_Site-one-2-1-2-auto-v2-hourly-202310051000-1, where the third numeric 2 is present, signifies the first disk (vdb)
  • REMOTE-Master_Site-one-2-1-3-auto-v2-hourly-202310051000-1, where the third numeric 3 is present, signifies the second disk (vdc)

Each of these disks will need to be downloaded individually.

The status of the download can be viewed by navigating to Storage → Images. When the download is complete, the icon at the far left of the image name will change from gray to green, and the status will change from LOCKED to READY.

locked images

Creating a restore template

Depending on the requirement, the data disks can be set to persistent before moving forward with the process. To achieve this:

  • Select the image
  • Click the pen icon icon on the persistent line
  • Select yes from the drop-down list

For a simple restore, the above step is not necessary.

The download process will have added a simple template for each image. Navigate to Templates → VMs to see the list of these templates. The templates for disks 2 and 3 can be ignored and/or removed.

Tip

If this is a frequent operation, creating a template with networking and other custom variables pre-set may be desired, where it will only need to be updated with the correct disk attachments.

For this example, the template created from downloading the OS disk will be used.

In the Templates → VMs menu, click the template for the root disk, e.g.: REMOTE-Master_Site-one-1-1-0-auto-v2-hourly-202310051000-1

  1. Click the blue Update button.
  2. Modify the settings as required:
    • CPU and memory
    • Add extra disks if needed
    • Configure networking
    • Add any context information needed
  3. Click the green Update button to commit the settings.

Instantiate template

Now, the VM can be instantiated as usual, giving it a name and checking the settings are correct.

In the instance where multiple disks are attached, it would appear as seen below:

recovery instance

Conclusion and clean up

When the VM has booted, additional disks can be attached to recover files, etc.

Once this recovery process is completed, it is recommended that the instance be terminated, and all artifacts deleted. This will not affect the replicated snapshots; however, it will recover storage space. To achieve this:

  • Terminate the VM
  • Remove the templates, selecting the Delete all images option.