In short: SolusVM Disaster Recovery (DR) restores virtual servers from their latest backup onto a different, healthy compute resource after the original one fails. You start it manually, and SolusVM then automates the restore. It is not High Availability, and it is not just “backups switched on.”
Key takeaways
- DR restores the latest backup. Anything changed since then is lost.
- Any server with at least one valid backup can be recovered, even if DR isn’t enabled on its plan. The plan setting controls what you sell, not what is technically possible.
- Enabling DR on a plan does nothing until your compute resources are configured for it.
- Recovery needs a compatible destination with enough free RAM, vCPU, and disk.
- Your backup schedule sets your recovery point. Your restore concurrency and capacity set your recovery time.
Start with RPO and RTO
Your Recovery Point Objective (RPO) is how much data you can afford to lose. Your Recovery Time Objective (RTO) is how fast you must restore service. In SolusVM, daily backups mean a recovery point up to 24 hours old. Recovery time depends on backup size, how many servers restore at once, and destination capacity.
Step 1: Get backups right
- Keep backup nodes on dedicated servers, not on compute resources. SolusVM strongly recommends this, since a shared server can lose your servers and their backups in one failure.
- Back up regularly and often. The Resilience Status page flags servers as “Expired” when their newest backup is more than seven days old, but your own RPO should be much tighter.
- Check the “Without backups” count. Those servers cannot be recovered.
Step 2: Offer DR on your plans
- Go to Compute Resources > Plans and add or edit a plan.
- Select Offer backups, then Offer disaster recovery feature.
- Optionally set Disaster recovery price in % (0 to 100% of the base server price). The default of 0 makes DR free.
- Save.
Decide your policy before an outage. Servers on non-DR plans with backups are technically recoverable, so state in your SLA whether you will do it. If you sell through WHMCS, you need the SolusVM WHMCS module version 1.0.55 or later for customers to add DR when ordering.
A simple product ladder works well: standard VPS, then VPS with backups, then VPS with DR, then HA where it fits.
Step 3: Prepare your compute resources
A plan flag alone doesn’t make recovery possible. Open Disaster Recovery > Resilience Status and click a compute resource to see which others can act as its destination. Each destination must match on:
| Check | What must be true |
| Status | Online, with SolusVM Agent reachable from the management node |
| IP blocks | Includes all blocks used on the source |
| Virtualization | KVM to KVM, VZ to VZ |
| Storage | Has all storage types present on the source |
| Source | SolusVM 1 imports recover only to other SolusVM 1 imports |
| Architecture | Same (for example, x86-64 to x86-64) |
| Capabilities | Matching “libvirt” capabilities |
Also confirm that the compatible destinations have enough combined RAM, vCPU, and free disk for everything you would recover. A compatible node with no free capacity is not a plan.
To speed up recovery, raise the Restore value under “Concurrent Backups” on the destination compute resource and on each backup node. The effective limit is the lowest of those values, so there’s no universal number. Tune it to your network, storage, and CPU.
Step 4: Test before you need it
Don’t test on a production compute resource. Failing a node makes every server on it appear down, and a careless test can cause IP conflicts. Instead:
- Use a test compute resource hosting only test servers, with a compatible destination.
- Simulate failure by shutting the test node down. This is the recommended method.
- Start a recovery from the Disaster Recovery page.
- Verify that the server boots, keeps its IP and MAC, and works as expected.
- Record the backup age, the time to restore, and any surprises. These become your real RPO and RTO.
- Bring the source back, then clean up (see below).
Step 5: Know your outage runbook
- Try SSH to the affected compute resource and check whether the SolusVM Agent is running and reachable. If you can’t get in, or you know it’s an outage, proceed.
- Go to Disaster Recovery, open the compute resource, and select servers. You can pick servers with DR enabled, or any with backups.
- Choose Auto (load-balanced) or Manual destinations, and check the resource summary.
- Optionally notify server owners by email.
- Start the recovery and monitor Disaster Recovery > Activities. If it fails, fix the cause and click Retry.
SolusVM recreates each server with the same configuration, including IP and MAC. It restores the latest backup and starts the server if it was running.
After recovery: clean up
- If the source is gone for good, delete it from Compute Resources.
- If the source comes back, View original data to check for anything worth salvaging, such as data newer than the backup. Then Delete original data to avoid IP conflicts. Deletion is permanent.
- Consider migrating recovered servers off the destination to avoid overcommitting it, especially if limits are set to “Unlimited.”
Don’t forget the management node
DR protects customer servers, not the control plane. Schedule management node backups (daily, weekly, or monthly) to a backup node. They include configuration, certificates, license files, and the PostgreSQL, Redis, InfluxDB, and RabbitMQ data. You can restore from the interface if it’s still reachable. If not, install SolusVM on a new server, download the backup, and run ./installer -restore <backup file>.
DR vs. High Availability
| Disaster Recovery | High Availability | |
| Trigger | Manual, by an administrator | Automatic after failure is confirmed |
| Recovery source | Latest backup | Shared storage |
| Data loss | Anything since the last backup | Not bound by backup age (shared storage) |
| Supported servers | KVM and VZ | KVM only, no containers |
| Storage requirement | Backups on a backup node | Shared LVM (iSCSI) or NFS |
| Destination | Any compatible compute resource | Same failover domain |
Use them as layers. Backups give you recovery points, DR gives you a restore process, and HA gives you automatic failover for eligible workloads.
Already have a backup system?
The API endpoint /api/v1/disaster_recoveries/prepare creates a new server with the configuration of one on an unavailable compute resource. Your own pipeline can then restore data onto it.
FAQ
Does DR start automatically? No. An administrator starts it, and SolusVM then automates the restore.
Can customers be charged for DR? Yes, as a percentage of the base plan price from 0 to 100%.
What is lost? Everything since the latest backup.
Can KVM recover onto VZ? No. Virtualization types must match.
Does a server need DR enabled to be recovered? No. It needs at least one valid backup and a compatible destination.
How do I know it works? Test on a dedicated test node, and check the Resilience Status page regularly.