Servers.news Guide
A VPS snapshot is convenient when an update goes wrong. It is far less useful when the provider account is locked, the storage platform fails, the region is unavailable, or ransomware reaches the same environment. Real disaster recovery starts with a copy you can still reach when the original infrastructure cannot be trusted.
Snapshots are one of the easiest server features to misunderstand.
You click a button, the provider preserves the state of a virtual machine, and a restore option appears in the control panel. It feels like a backup because, on a normal day, it behaves like one.
The problem appears on the abnormal day.
If the snapshot lives inside the same provider, depends on the same account, uses the same storage platform and can only be restored through the same control plane, several things can fail at once. A regional outage can make both the server and its snapshot inaccessible. A compromised cloud account can expose both. A provider-side incident can leave the underlying storage unavailable even though your snapshot technically still exists.
A snapshot can absolutely be useful. It just should not be the only copy standing between your production system and a blank disk.
If losing access to one provider would also remove your ability to restore the backup, you do not yet have provider-independent disaster recovery.
- Snapshot, backup and replica are not the same thing
- The failure you should design for
- Server failure
- Account compromise
- Regional outage
- Provider failure
- Use the 3-2-1 rule as a starting point
- Back up the things required to rebuild, not just the obvious files
- Databases need more than a filesystem copy
- Decide how much data you can afford to lose
- Make ransomware unable to erase every copy
- Do not use the same credentials everywhere
- A backup is not proven until it has been restored
- A sensible backup design for one production VPS
- Keep snapshots for rollback
- Create scheduled backups
- Send a copy elsewhere
- Protect historical versions
- Document the rebuild
- Test it
- What should stay outside the VPS provider?
- What happens if the provider disappears tomorrow?
- The bottom line
Snapshot, backup and replica are not the same thing
The three are often grouped together because all of them create another version of your data. Operationally, they solve different problems.
| Method | Best for | Main weakness | Good disaster recovery? |
|---|---|---|---|
| VPS snapshot | Fast rollback before updates, configuration changes or risky maintenance | Often tied to the same provider, account, region and storage system | Not by itself |
| Independent backup | Recovering files, databases and complete systems after loss or compromise | Recovery can be slower and requires proper backup design | Yes, if stored independently |
| Replica | Fast failover and high availability | Bad changes, corruption or deletions may replicate too | Useful, but still needs backups |
A snapshot is particularly useful immediately before a kernel upgrade, major package update or application deployment. If the change breaks the machine, rolling back can take minutes.
That is a very different problem from recovering after the entire hosting environment becomes unavailable.
The failure you should design for
Do not start a backup plan by asking, “How often should I back up?” Start with a more uncomfortable question:
What is the largest failure I still want to recover from?
For a hobby server, losing one virtual machine may be the realistic worst case. For a production service, you may need to plan for the loss of an entire cloud account, region or provider.
That decision changes where the backup must live.
Server failure
A second copy on another disk or storage system may be enough if the provider itself remains healthy.
Account compromise
The attacker must not be able to delete production systems and every backup using the same credentials.
Regional outage
A backup stored only in the affected region may be safe but temporarily unreachable when you need it most.
Provider failure
You need enough data, configuration and credentials outside the provider to rebuild somewhere else.
Use the 3-2-1 rule as a starting point
The classic 3-2-1 backup rule remains useful because it forces separation between copies.
For a modern VPS, that does not mean buying tapes and sending them to another building. A practical implementation could be much simpler:
- The live VPS remains the production copy.
- A provider snapshot is retained for fast operational rollback.
- An encrypted backup is sent to object storage under a separate account or provider.
- Older backup versions are protected from immediate deletion where possible.
The important detail is separation. Copying a backup to another bucket inside the same account may improve redundancy, but it does not necessarily protect against stolen credentials or account-wide deletion.
Back up the things required to rebuild, not just the obvious files
A server is more than its application directory.
If you had to create a fresh VPS tomorrow, what would you need before users could connect again?
- Application data and uploaded files
- Database dumps or database-aware backups
- Web server and reverse-proxy configuration
- Container definitions and persistent volumes
- Firewall and network configuration
- Scheduled jobs and system services
- Infrastructure-as-code or provisioning scripts
- DNS records and documentation needed to redirect traffic
Secrets require more care. Private keys, API credentials and encryption keys may be essential for recovery, but storing them beside an ordinary backup can create another security problem. Keep sensitive recovery material encrypted and restrict access separately from the production server.
Databases need more than a filesystem copy
Databases are where many otherwise reasonable backup plans become unreliable.
Copying database files while the database is actively writing to disk can produce an inconsistent backup. Whether a storage snapshot is application-consistent depends on the database, filesystem, hypervisor and the way the snapshot was taken.
For an important database, use the database engine’s supported backup method or a backup tool designed to coordinate with it.
Simple example
A small web application might create a scheduled database dump, archive application files and configuration, encrypt the result and send it to independent object storage. The provider snapshot remains available for quick rollback, but it is not treated as the only recovery copy.
Decide how much data you can afford to lose
Backup frequency should follow the value and rate of change of the data, not a generic schedule copied from another server.
Two useful terms make that decision easier:
RPO — Recovery Point Objective. How much recent data can you afford to lose?
RTO — Recovery Time Objective. How long can the service remain unavailable while you rebuild it?
| Workload | Possible RPO | Typical approach |
|---|---|---|
| Personal site | 24 hours | Daily off-site backup plus periodic snapshots |
| Company website | Several hours | Multiple backups per day plus independent storage |
| Active database application | Minutes to an hour | Frequent database-aware backup or log-based recovery |
| Critical transactional service | Very low | Replication, frequent backups and tested failover architecture |
These are examples, not universal targets. A forum that receives three posts per day and an online service processing thousands of transactions per hour clearly do not have the same recovery requirements.
Make ransomware unable to erase every copy
Ransomware changes the backup problem because the attacker may deliberately look for recovery systems.
If the production server can authenticate to backup storage with unrestricted delete permissions, a compromise of the server may give an attacker a route to the backups as well.
Where the storage platform supports it, consider retention controls, immutable backup versions or object locking. The goal is simple: a compromised production machine should not be able to immediately destroy every historical recovery point.
Do not use the same credentials everywhere
Independence is not only about geography.
A backup stored with another provider but controlled by the same compromised password is less independent than it looks.
Use separate credentials for backup storage. Protect administrative accounts with multi-factor authentication. Give backup jobs only the permissions they actually require, and avoid placing long-lived administrator credentials directly on the production server.
Also think about the credentials required during recovery. If your password manager, DNS account, cloud account and backup encryption key all depend on one unavailable identity system, rebuilding the server may become much harder than expected.
A backup is not proven until it has been restored
A successful backup log proves that a job wrote something somewhere. It does not prove that the result can rebuild your service.
The only convincing test is a restore.
Create a clean VPS occasionally and recover the application without relying on the original machine. Record how long it takes and note every missing piece.
- Can the backup actually be downloaded?
- Do you still have the decryption key?
- Can the database be restored without errors?
- Are configuration files included?
- Do application secrets exist in a recoverable location?
- Can DNS be changed if the original provider is unavailable?
- Does the application start on a clean machine?
- Can you complete recovery without logging into the failed server?
This exercise often finds problems that backup dashboards never show: forgotten configuration files, undocumented firewall rules, missing keys, incompatible database versions or scripts that only work on the original machine.
A sensible backup design for one production VPS
You do not need enterprise infrastructure to improve resilience dramatically.
Keep snapshots for rollback
Take a snapshot before major upgrades or risky changes when the provider makes that practical.
Create scheduled backups
Back up databases, application data and important configuration on a schedule matched to your RPO.
Send a copy elsewhere
Use storage that does not depend on the same VPS, account and failure domain as production.
Protect historical versions
Retain multiple recovery points so corruption or malicious deletion is not copied into your only usable backup.
Document the rebuild
Write down the order required to recreate the server, restore data, configure DNS and validate the application.
Test it
Restore onto a clean machine periodically. A recovery process nobody has tried is still an assumption.
What should stay outside the VPS provider?
At minimum, keep enough material outside the primary provider to create a functioning replacement environment.
| Item | Keep independently? | Why |
|---|---|---|
| Application data | Yes | Usually the hardest part of the service to recreate |
| Database backups | Yes | Needed to restore application state and transactions |
| Server configuration | Yes | Reduces guesswork during an emergency rebuild |
| Infrastructure code | Yes | Lets you provision replacement infrastructure faster |
| Critical keys and credentials | Yes, securely | Recovery may be impossible without them |
| Provider snapshot | Useful locally | Excellent for rollback, but insufficient as the only recovery copy |
What happens if the provider disappears tomorrow?
This is a useful final test because it removes the assumptions that make weak backup plans look stronger than they are.
Imagine that the provider dashboard cannot be opened. The original VPS does not boot. Support cannot give you an immediate recovery estimate.
Could you rent a server somewhere else, retrieve your backup, restore the database, recreate the application configuration and point DNS at the replacement?
If the answer is yes, you have the beginning of real disaster recovery.
If the first step is “log into the old provider and download the backup,” the plan still depends on the system you are trying to survive.
