VPS and VDS backups: snapshots, retention and restores
By the end: You will have written down what to back up, where to keep the copy and how to test recovery. A backup is a data copy you can return to when something goes wrong.
A server backup plan defines which data you copy, how often you copy it and how you recover when needed. A completed backup job does not, by itself, prove that the application can run successfully from that copy.
Applies to: Planning for a self-managed VPS, VDS or dedicated server. This guide does not install a particular backup product or describe unverified customer portal features. For web hosting backup terms, use the hosting backup guide.
Copies exposed to the same failure do not provide independent protection.
- Copy on the same disk
May undo an accidental edit, but can disappear with the original if the disk fails.
- Virtual machine snapshot
Returns to a state where supported; it is not protection independent of the same storage.
- Separate backup destination
A copy separate from the source server. Access, retention and restore testing still matter.
Snapshot scope and backup services depend on the package; do not assume they are included.
1. Confirm what your service includes
Confirm in your DCHost customer portal service information or with support:
- Does the package include backups?
- If so, which data and disks are covered?
- How long are copies retained?
- Who restores them, and how?
Check: “There is a backup” is not enough. Establish which point you can return to and the restore method.
DCHost virtual servers use Proxmox/KVM infrastructure. This does not mean that every package includes automatic backups, customer-accessible snapshots or a particular retention period. If your product does not include a backup service, plan operating system, application and data backups separately.
When discussing backup scope with support, provide the server ID, data types, size, rate of change, retention needs and restore requirements. You need appropriate access to the source server and involvement from the person responsible for the application.
2. Separate snapshots from independent backups
Simple example: Two copies in different folders on the same disk can both disappear if that disk fails. The copy's independence from the source server matters as well as its existence.
| Method | What it provides | What it does not solve on its own |
|---|---|---|
| Copy on the server's own disk | Quick recovery from some accidental edits | Failure of the same disk/server or account compromise |
| Virtual machine snapshot | Return to a particular state where supported | Protection independent of the same storage and long-term retention |
| Backup on a separate destination | A restore copy separate from the source server | Guaranteed protection from deletion if access/retention is misconfigured |
| Application-aware data backup | Consistent recovery of files and databases | The entire OS, other services and every dependency |
A snapshot's scope depends on storage and VM settings. Do not assume it includes memory state, every attached disk or an external database. Proxmox's backup method called “snapshot mode” is also different from a VM snapshot. Live databases require application consistency; copying files alone may be insufficient.
3. Set recovery targets around the business
Fill in two blanks:
- Data target: I can accept losing no more than ___ minutes/hours of recent data.
- Time target: I can allow no more than ___ minutes/hours to restore service.
These are your planning targets, not guarantees provided by the package.
Write down answers to two questions: How much recent data could you accept losing? This is your recovery point objective, or RPO. How long can you allow for getting the service running again? This is your recovery time objective, or RTO.
For example, a weekly copy may not fit an online store's tolerance for losing orders placed during the day. These targets are not service guarantees. Check whether the backup frequency, transfer time and an actual restore exercise meet them.
4. List the data to protect
Make one list and record which backup includes each item:
- Application files and uploads.
- Databases.
- Required configuration and scheduled work.
- Email and external storage, if used.
- Dependency information needed for rebuilding.
Check: Do not assume a file backup contains the database. Verify each data type.
Consider application files, uploads, databases, configuration, scheduled jobs and email data where relevant. Include external object storage or databases hosted elsewhere. If configuration files contain passwords or keys, encrypt the backup and keep the decryption key somewhere other than only the source server.
Use a backup method supported by the database software. Arbitrarily archiving a live database directory can create a copy that appears complete but cannot be restored correctly. Plan how application files and database state will remain consistent with each other.
Consistency example: The database may contain an upload record while the matching file is missing from the backup. Test that files and database return to a compatible state.
5. Define retention and monitoring
Add four items to the plan: backup destination → schedule → versions to retain → person receiving failure alerts.
Store backups on a destination separate from the source server. Limit access and assess the risk of a compromised source account being able to delete every historical copy. Decide how many daily or weekly versions to keep and how much storage they require.
Arrange notifications for backup failures, unexpected size changes and declining destination capacity. Keep backups outside public web directories. Manage encryption, access control and recovery keys together.
6. Verify by restoring to a separate environment
A successful backup job does not replace a restore exercise.
- Choose a backup point
Decide which point to restore and which records you expect to find.
- Restore separately
Restore into restricted testing without overwriting live data. Block real notifications and payments before starting the application.
- Check the data
Confirm that sign-in works, files open and important records are correct.
- Record the duration
Record the backup date and restore time; compare them with your targets.
Before real recovery, plan how to preserve orders and records created after the backup.
Perform a real restore exercise:
- Prepare an access-restricted test environment separate from the live server.
- Before starting the application, prevent email, payment and scheduled tasks from acting on real customers.
- Restore the chosen backup into this protected environment.
- Check files, sign-in and important records.
- Record the restore duration and backup date.
Expected result: The application opens in the test environment and important data from the selected backup point is verified. The existence of a backup file does not replace this test.
Restore to an access-restricted test environment rather than overwriting the live server. Prevent the restored application from sending customer email, initiating payments or repeating scheduled jobs. Check critical records, files, login and application operations. Record the backup date and time taken to restore.
Preserve the current data before a real restore. Returning to an older backup can lose records created after it was taken. After a security incident, restoring an older copy is not enough: address credentials and the cause of compromise too. Never remove the last backup without another verified, usable copy.
Before a real restore: Decide how to preserve orders and records created after the backup. Restoring does not simply “add missing items”; depending on the method, it can overwrite current data.