Almost everyone has something configured to run backups. The problem is that “having a backup” and “being able to restore at a critical moment” are two very different things. A backup that has never been tested is not a backup: it’s a hope.
The 3-2-1 principle is the starting point: 3 copies, on 2 different media, with 1 copy offsite. And to that you have to add what’s rarely said: backups must be encrypted, there must be a defined retention period, and restoration must be tested regularly — not on the day it’s needed.
I handle the design, implementation and maintenance of your infrastructure backup strategy, without depending on whatever backup service your hosting provider throws in.
Common problems
- The backup is on the same server. If the server dies, the disk fails or ransomware hits, the backup goes with it. A copy stored in the same place is not a real backup.
- Hosting backups. The backups included with hosting are usually on the same infrastructure, with short retention and no encryption. They work for minor mistakes; for real disasters, they’re not enough.
- No encryption. Backups contain customer data, orders, credentials. Storing them in plain text on an external bucket is both a security issue and a compliance problem.
- Nobody has ever tested a restore. The backup exists, but the restoration process has never been run under real conditions. When it’s urgently needed is the worst time to discover it doesn’t work.
- Insufficient retention. An error that goes unnoticed for several days requires being able to go back more than 24 hours. Without enough retention, some scenarios become unrecoverable.
How I approach it
The strategy design starts from real requirements: what needs to be protected, how often the data changes, how long the service can be down (RTO) and how far back in time you need to recover (RPO). There’s no one-size-fits-all solution.
From there, implementation includes automation, integrity verification, backup rotation and documentation of the restoration process — which is what actually matters when you need to use it.
What’s included
Strategy design
- Definition of RPO (how much data loss you can afford) and RTO (how quickly you need to be operational).
- Identification of what needs protecting: database, files, configurations, data volumes.
- Selection of external destinations: cloud storage (S3, Backblaze B2, Hetzner Storage Box and others), dedicated backup server or offsite.
Implementation
- Automated backups with frequency matched to the data change rate (hourly, daily, weekly).
- Backup encryption at source before leaving the server (GPG, restic, duplicati and others).
- Secure transfer to the external destination with integrity verification.
- Configured rotation and retention: daily, weekly and monthly copies as needed.
- Alerts if a backup fails or doesn’t run within the expected window.
Verification and testing
- Periodic restore test in a staging environment to confirm the backup is usable.
- Automatic integrity verification of backup files.
- Step-by-step restoration process documentation, so anyone on the team can execute it under pressure.