VPS Backup Strategy and Disaster Recovery: 3-2-1 Rule

The joke “Those who don’t have backups deserve to be left without backups” is coming true in the corporate world. Every year, dozens of companies in Türkiye lose data worth their annual turnover due to ransomware, incorrect SQL DELETE commands, disk failure or the error of their own users. Most have this in common: The backup exists but is untested or insufficient.

In this article, we will explain the modern backup strategy, the 3-2-1 rule, RTO and RPO targets and how VDS Panel automates this discipline.

3-2-1 rule

Industry standard backup strategy:

• 3 copies: Have at least 3 separate copies (original + 2 backups)
• 2 different media: Different physical devices (SSD + HDD, or SSD + cloud)
• 1 offsite: At least 1 copy in different geography (different DC or cloud region)

Example:

• Original data: on your VPS (SSD)
• Backup 1: On another partition of the same VPS (SSD, daily)
• Backup 2: AWS S3 or Cloudflare R2 (object storage, offsite)

This structure protects against disk failure, data center disaster, and regional outage.

RTO and RPO: Two critical metrics

RTO (Recovery Time Objective): Time to recover the system after the disaster. How long can you stay “down”?

RPO (Recovery Point Objective): How much data loss can you tolerate? It determines how often you take backups.

Backup types

Full backup

The entire database is backed up every time. Restoration is easy, storage is expensive.

Incremental backup

What has changed since the last backup. Storage efficient but restore time complicated (full + incremental chain).

Differential spare

What has changed since the last full backup. Compared to Incremental, restoration is easy and storage is medium.

VDS Panel backup architecture

The panel defaults to:

1. 01
   Check every 15 minutes

   The panel scheduler scans the status of all databases every 15 minutes and calculates the time function between the last backup.
2. 02
   Daily full backup

   A full backup is taken every night at 03:00 with pg_dump or mysqldump. Format: custom compressed (pg) or sqlgz (mysql).
3. 03
   encryption with age or gpg

   The backup file is encrypted with your public key. The panel or the attacker cannot decrypt.
4. 04
   Local storage

   30 days retention under /var/backups/vdspanel-license. Old backups are automatically deleted.
5. 05
   Optional offsite upload

   If you have an S3 or R2 account, each backup is also sent to cloud storage. Local is preserved in case of unsuccessful upload.
6. 06
   Event log recording

   Each backup operation is recorded in the panel event log. In case of failure, a warning is sent to the admin.

Restore test

Most common backup mistake: not testing at all. You have backups, but you are trying the restoration process for the first time during a disaster. Result: it usually doesn’t work.

Ransomware protection

The biggest threat in modern backup is ransomware. Once an attacker enters the server, he can also encrypt backups. Protection:

Immutable backups

A file written once with S3 Object Lock or B2 compliance mode cannot be deleted for a certain period of time. Even if the attacker is root, he cannot modify the backups.

Append-only shares

Only write permission on the backup server, no deletion. Old backups remain safe.

Air-gapped copy

The most critical backup is on physically unconnected media such as USB/tape. Ransomware cannot reach you.

VDS Panel offers S3 Object Lock integration; There is an append-only policy example for R2 in the documentation.

Disaster recovery plan

Backups are not enough, scenario is required:

1. Complete server loss: New VPS, panel installation, restore from backup. RTO: 30 min.
2. Database corruption: Restore from last backup. RTO: 5 min.
3. Wrong migration/deletion: Go back to the backup from a few hours ago. RTO: 2 min.
4. Ransomware attack: Restoring from immutable backup to clean VPS. RTO: 1 hour.
5. Regional disaster (DC fire): Restoration in a different region from offsite backup. RTO: 2 hours.

Write a runbook for each scenario. When a problem arises, proceed with pre-planned steps rather than panicking.

PITR (Point-In-Time Recovery) for PostgreSQL

Daily backup is not enough in some cases. For example, you ran an incorrect UPDATE today at 14:35; If you revert to a night backup, all changes between 14:00 and 23:00 will be lost.

You can get back to seconds precision with PITR:

• WAL (Write-Ahead Log) archiving is active
• Panel provides shippping WALs every hour
• Restore time: return to “2026-04-22 14:34:59”

VDS Panel supports PITR on Kubernetes with the CNPG (CloudNativePG) module. Indispensable for critical production.

Cost optimization

Backup storage cost:

• Local VPS disk: ~0.05 €/GB/month (already shared)
• Cloudflare R2: $0.015/GB/month, exit free
• Backblaze B2: $0.006/GB/month, affordable
• AWS S3 Glacier: $0.004/GB/month (restore slow)
• AWS S3 Standard: $0.023/GB/month

Offsite backup cost ~$0.15 per month for 10 GB database. Compared to the risk of data loss, it is almost non-existent.

Conclusion

Backup is an indicator of data maturity. “I have a backup” is not enough; It should be “I have a backup, it is encrypted, I have an offsite copy, I test it monthly.” Turn the 3-2-1 rule into a daily routine, determine your RTO and RPO targets in writing, and test the restoration process at least 4 times a year.

VDS Panel activates this discipline automatically. 15-minute scheduler, age/gpg encryption, S3 and R2 upload, 30-day retention, event log — all enabled by default. You can contact us via contact form for security details and installation.