Restores a Linode's backup to the specified Linode.
- Backups may not be restored across regions.
- Only successfully completed backups that are not undergoing maintenance can be restored.
- The Linode that the backup is being restored to can't be the target of a current backup.
When you restore a backup, the restored disk is assigned the same UUID as the original disk. In most cases, this is acceptable and doesn't cause issues. However, if you try 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'll encounter a UUID "collision".
When this happens, the system selects, and mounts, only one of the disks at random. This is because both disks are sharing the same UUID. Your instance may fail to boot because the API can't tell which disk is root. If your system boots in this scenario, you won't see an immediate indication if you're booted into the restored disk or the original disk, and you'll be unable to access both disks at the same time.
To avoid this, only restore a backup to the same Linode if you don't intend to mount them at the same time, or you're comfortable modifying UUIDs. If you need access to files on both the original disk and the restored disk simultaneously -- for example, if you need to copy files between them -- you should restore the backup to a separate Linode or create a new Linode using the desired backup_id.
To learn more about block device assignments and viewing your disks' UUIDs, see our guide on Configuration Profiles.
Backups aren't encrypted even when they're taken from an encrypted disk. When a backup is restored, and if encryption is enabled, the data stored on the disk is encrypted again.
linode-cli linodes backup-restore 123 123456 \
--linode_id 234 \
--overwrite true
<https://techdocs.akamai.com/cloud-computing/docs/getting-started-with-the-linode-cli>
linodes:read_write
<https://techdocs.akamai.com/linode-api/reference/get-started#oauth>