Restoring a SolusVM 2 server backup replaces the target disk state with an earlier recovery point. Plan the data-loss window explicitly. Where the installed version and backup support it, restoring into a new isolated server lets you inspect the result before replacing the live service.
IN THIS ARTICLE
Prepare for the change
Record the target server ID, selected backup time and application recovery objective. Preserve valuable changes made after that backup. Arrange console access, a maintenance window and a plan for DNS, IP addressing and application credentials.
01 Restore a SolusVM 2 server backup safely
- Inspect the backup record and successful completion status. Verify the required storage and destination compute resource are available and compatible with the backup format.
- Choose in-place restore only when replacement of current data is intended. Otherwise use the supported create-server-from-backup workflow and isolate the recovered copy from production integrations.
- Stop application writes or place the live service in maintenance as appropriate. Prevent the restored copy from sending duplicate messages, scheduled jobs or payment requests during testing.
- Start the restore from the server backup controls and monitor the task. Avoid submitting the same restore repeatedly while it is queued or running.
- Boot the recovered server, inspect its console and validate the application before returning traffic. Reconcile any transactions that occurred after the recovery point using the application recovery procedure.
Will a restore bring back every snapshot?
No. Snapshot retention and backup recovery are different mechanisms. In particular, restoring a qcow2 server can discard its existing snapshots. Confirm the consequences before approving an in-place operation.
Check the backup or recovered data
Test files, database consistency, authentication, time synchronization and a representative application action. Verify the actual recovered date against the intended point. Confirm networking and certificates use the intended identity, then establish a fresh backup baseline.
If the change does not work
If the restore fails, preserve the task error and source backup. Check temporary-space requirements and backup/storage compatibility before retrying. An incremental chain needs its required components. Avoid deleting the current guest or older recovery points until a working restored system is confirmed.