Backup Practice: 30-Day Rotation and Restore Drill

Every morning the backup dashboard glows green. All jobs successful, no warnings, no errors. The IT lead ticks the item off and moves on. A year later, at 03:14 in the morning, ransomware encrypts the file servers. At 09:00 the team stands in the server room and realises: the backups are there, but restoring them takes not the planned four hours but two and a half days. And the database restore fails, because the log truncate has not run cleanly for eight months.

We see this pattern regularly in the field. Backups are built, put into production and never touched again. The real core question — can operations actually be restored in the promised time in an emergency — is never asked. In this article we describe a resilient 30-day rotation following the grandfather-father-son principle, the quarterly restore drill, and the RTO/RPO matrix that belongs on the wall in the data centre.

Why 30 days and why grandfather-father-son

The retention period is not an arbitrary number. In SMB practice, 30 days is the minimum needed to cover two typical threat scenarios: first, creeping data corruption, which often only becomes apparent after two or three weeks; second, ransomware, which in modern campaigns sits in the network for several days to weeks before the encryption trigger fires. Anyone with only seven days of retention risks restoring already compromised snapshots.

Grandfather-father-son (GFS) staggers retention so that you can still look deep into the past with a manageable storage footprint:

• Son — daily backups, retained for seven days
• Father — weekly full backups, retained for four to five weeks
• Grandfather — monthly full backups, retained for twelve months

This gives you a recovery point for every day of the last week, for every week of the last month, and for every month of the last year. Storage growth is not linear but degressive if you deduplicate sensibly.

Example rotation with Proxmox Backup Server and TrueNAS

In most of our projects the primary backup runs on Proxmox Backup Server with a TrueNAS SCALE as the secondary target. PBS 3.x delivers incremental deduplication, TrueNAS provides the independent second instance on ZFS with snapshots. The rotation maps cleanly onto the PBS prune options:

keep-last: 7
keep-weekly: 5
keep-monthly: 12
keep-yearly: 3

The corresponding sync job to the TrueNAS target runs at night after the local backups complete. On TrueNAS an additional ZFS snapshot policy versions the backup datasets themselves, protecting the PBS data against compromise of the PBS host. That is the second of three neglected areas we frequently encounter — the first is the missing off-site copy, the third is the restore drill.

The 3-2-1-1-0 rule, briefly explained

The classical 3-2-1 rule has been extended for the current threat landscape. We work with 3-2-1-1-0:

• 3 copies of the data, including original
• 2 different storage media
• 1 copy off-site
• 1 copy offline or immutable (air-gap or S3 Object Lock)
• 0 errors in the last restore test

The last digit is the decisive one. It forces testing to actually happen. Without this point, every backup strategy remains a paper tiger.

The quarterly restore drill

A restore drill is not a large-scale DR test but a controlled, documented recovery exercise that runs in four steps:

1. Random selection. A team member picks a VM or dataset from the backup console. Not the “easy” one, not the “important” one — one determined by dice or a random generator.
2. Isolated recovery. The restore runs onto a separate Proxmox host or into an isolated VLAN so that the production environment is not affected and any co-restored malware cannot activate.
3. Verification at the application layer. It is not enough that the VM boots. The database must open, the ERP must accept a login, a test document must be versioned and reopened. For each system we document which concrete functional test counts as “restore verified”.
4. Logging. Start time, end time, issues found, actual RTO. The log goes into the operations documentation and forms the basis for the next revision of the RTO/RPO matrix.

In a typical customer project we regularly discover on the first drill that the theoretical RTO was optimistic by a factor of two to five. Causes are usually: uncached deduplication metadata, an overloaded 1-GbE connection to the backup target, or simply the absence of recovery runbooks within reach of the on-call colleague.

The RTO/RPO matrix

Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are not backup-software settings but business targets. The matrix should be spelled out explicitly per system:

System	RPO (max. data loss)	RTO (max. downtime)	Backup frequency	Test cycle
ERP database	15 min	2 h	Log shipping every 15 min + daily full	monthly
File server accounting	1 h	4 h	Snapshots hourly, PBS daily	quarterly
File server marketing	24 h	24 h	PBS daily	quarterly
Terminal server	24 h	8 h	PBS daily	quarterly
Domain controller	24 h	1 h	PBS daily, second DC live	semi-annually
Web server	24 h	4 h	PBS daily	quarterly

This matrix has two functions. First, it forces management to take a position — a one-hour RTO for the file server carries a very different price tag than 24 hours. Second, it makes IT auditable. If the ERP restore during the drill takes four hours but the matrix allows two, that is a documented action item.

Typical silent failures

Backups that run green but fail on restore follow a handful of recurring patterns:

• VSS failures on running SQL services without clean log release — backup reports “OK”, database is inconsistent on restore.
• Missing or expired encryption keys on PBS encryption — the chunk repository is there, extractable but not usable.
• NTFS permissions are backed up but unusable when restored against a different domain SID.
• Application servers with hard-coded IPs that find no external resources after restore into an isolated VLAN and thereby block verification.
• Bandwidth throttling in the backup software that fits regular operations but slows the restore unusably.

None of these failures are found by the monitoring of the backup software — only by an actual restore.

DATAZONE supports you

For SMB customers we build backup strategies that hold up in an emergency — from GFS rotation through 3-2-1-1-0 implementation to a logged quarterly restore drill including the RTO/RPO matrix. If you are unsure whether your current backups can be restored at all, talk to us. We run a first controlled restore test with you and document the actual recovery times — calmly and with defensible numbers. Details on our backup consulting or directly via our contact form.