Plan SolusVM 2 backups around a recoverable application state, a separate storage destination and a tested restore time. A successful scheduled task is useful evidence, but the recovery objective is to restore a working service with the expected data.
IN THIS ARTICLE
Information to have ready
Identify which servers require protection, acceptable data loss and required retention. Confirm the feature is enabled for the relevant plans and account. Budget destination capacity, transfer traffic, temporary space and restore time; do not assume any backup option is automatically included with a Nabtech service.
01 Plan backups for SolusVM 2 servers
- Add a supported backup node or storage destination through the administrator backup controls. Use dedicated access, restricted network permissions and credentials stored outside public documentation.
- Associate the destination with the required compute resources. Test connectivity and write access using the actual service workflow, not only an administrator SSH session.
- Enable the backup entitlement and limits in the intended plan, then configure the individual server schedule where required. Spread large jobs to avoid overwhelming storage or network links.
- For database-heavy applications, arrange a supported application-consistent backup or coordinated quiescence. A hypervisor-level disk copy alone is not proof that an active application can recover cleanly.
- Create an initial backup, inspect its task result, and restore a copy to an isolated test server. Record the observed recovery time and repeat this exercise periodically.
02 Example: keep the configuration needed beside the recovery plan
SolusVM documents a server backup as a disk copy without the server configuration. Keep a protected recovery record for the server identity, compute resource, plan/resources, storage type, assigned network addresses and required virtual hardware. Record where the matching management-node recovery copy and encryption or application recovery keys are held.
During the isolated restore test, use that record to check the recreated machine against the intended configuration, then verify a known application record and a harmless write. Store this information independently of the compute resource being protected. A readable disk backup cannot supply a missing external credential or reconstruct an undocumented network allocation by itself.
Are snapshots the same as independent backups?
No. A local snapshot usually shares the original storage failure domain. Keep independent recovery copies and verify which management configuration, guest disks and application data each backup actually covers.
Check the backup or recovered data
Confirm a recent recovery point exists, its storage is independent of the compute host, and retention operates as expected. Monitor failures, queue delays and destination capacity. Keep access to backup storage available during management-node recovery.
Troubleshoot unexpected results
For stalled jobs, examine the specific task, destination reachability, credentials and available space. Do not manually remove files from an incremental chain to free capacity. Correct the underlying issue, retain a known-good recovery point and run a new controlled backup.