Restore a backup to an existing Compute Instance

These steps cover how to restore a backup to an existing Compute Instance, either by adding the restored disks alongside the existing disks or overwriting the existing disks. The target Compute Instance needs to be in the same data center that the backup is stored within, though you can migrate it to any data center you'd like after the restore is complete. The target also needs to have enough free storage space to accommodate the restored disks.

Restoring a backup creates a new configuration profile and a new set of disks on the existing Compute Instance. The size of the disk(s) created by the restore process will be equal to the amount of space allocated to the disk when the backup was created. In some cases, this means you may want to reallocate disk space once the restore is complete. For more information regarding this process, see our Resizing a disk guide.

📘

This process restores all data that was stored on the disk at the time the backup was taken. It does not restore just a single files or directory. If you just need a single file or group of files, complete the normal restore, log in to the server, and then copy those needed files to your local system or any other Compute Instance.

1. From the Linodes page, select the Compute Instance whose backups you intend to restore.

2. Click the Backups tab.

3. Find the backup you'd like to restore and observe the disk space that's required, which is visible in the Space Required column. You will need at least this amount of unallocated disk space on the target Compute Instance to complete the restore.

4. Click the more options ellipsis dropdown menu next to the backup you would like to restore and then select Restore to Existing Linode.

   

5. A menu will open with the Compute Instances that you can restore to. Select a Compute Instance and click Restore.

   

   You will be notified if you do not have enough space on your Compute Instance to restore your backup. Optionally, you can choose to overwrite the Compute Instance you are restoring to.

6. If the amount of unallocated space available is greater than the size of the backup, you can proceed with restoring. If the amount of unallocated space is less than the size of the backup, you can stop the restoration workflow, resize your existing disks on the target Compute Instance to make room for it, and then come back to the restore page after the disk resize operation has finished.

   Depending on your available disk space, you may not be able to shrink your disks enough to fit the restored backup. As an alternative, you can change your Compute Instance plan to a higher tier that offers more disk space.

7. From the Restore to Existing Linode menu, click Restore. Your backup will begin restoring to your Compute Instance, and you can monitor its progress in the notifications area. Note that the time it takes to restore your backup will vary depending upon the restore size and the number of files being restored.

   📘

   If you are attempting to restore a disk to the same Compute Instance the backup was created from, the restoration process will not delete the original disk for you. Manually delete the original disk to make room for the backup, if desired.

8. Once your backup has been restored, you can optionally power up or restart your Compute Instance using that backup. To do so, navigate to the target Compute Instance in Cloud Manager, go to the Configurations tab, locate the configuration profile created during the restore process, and click the corresponding Boot button. For full instructions, review Boot from a configuration profile.

   🚧

   Warning: UUID Collisions

   When you restore a backup, the restored disk is assigned the same UUID as the original disk. In most cases, this is acceptable and does not cause issues. However, if you attempt to mount both the original disk and the corresponding restore disk at the same time (by assigning them both to devices in your Configuration Profile's Block Device Assignment), you will encounter a UUID "collision".

   When this happens, the system selects, and mounts, only one of the disks at random. This is due to both disks sharing the same UUID. Upon successfully booting, you will not see any immediate indication if you are booted into the restored disk or the original disk, and you will be unable to access both disks at the same time.

   To avoid this, we recommend only restoring a backup to the same Compute Instance if you do not intend on mounting them at the same time or are comfortable modifying UUIDs. If you need access to files on both the original disk and the restored disk simultaneously (such as needing to copy files between them), we suggest restoring the backup to a new Compute Instance.

   To learn more about block device assignments and viewing your disks' UUIDs, see Configuration profiles.