Website backups that actually save you: 7 rules for encrypted, off-site backups
Most "backups" fail exactly when you need them: same server, never tested, no encryption. Here are seven rules for backups that survive a real disaster — and how to stop doing them by hand.
Everyone has backups — right up until the day they need them. Then they discover the backup lived on the server that just died, hadn't run in three weeks, or restores into a broken mess. A backup you haven't tested isn't a backup; it's a hope. Here are seven rules that turn hope into something you can actually recover from.
1. Automate it — or it won't happen
A backup you have to remember to run is a backup that quietly stops running. Schedule it. Daily is a sane default for most sites; busier sites want more frequent database snapshots. The only good backup cadence is one no human has to think about.
2. Follow 3-2-1
The classic rule still holds: 3 copies of your data, on 2 different media, with 1 off-site. It sounds like overkill until a single failure — a dead disk, a bad deploy, a deleted bucket — takes out everything stored in one place.
3. Get it off the server
This is the one people skip. A backup sitting on the same VPS as the site dies with the VPS. Push backups to object storage — an S3 bucket, Backblaze B2, or an SFTP target on another machine. Off-site is the difference between "we lost an afternoon" and "we lost the business".
4. Encrypt before it leaves
Your backup contains everything: database, customer data, secrets, config. The moment it leaves your server it's a juicy target. Encrypt it before upload (AES-256 is the standard), and store the storage credentials encrypted too. An unencrypted backup in a misconfigured bucket is a breach waiting to happen.
5. Back up the database and the files
A files-only backup restores a site that can't connect to its data; a database-only backup restores data with no site around it. You need both — uploads, config and code and the database — ideally captured close together so they're consistent.
6. Keep versions, not just "the latest"
If your only backup is last night's, then a problem you notice a week late — a corrupted table, a quiet ransomware encrypt, a bad migration — is already in your backup. Keep a retention window (e.g. daily for a week, weekly for a month) so you can roll back to before the damage.
7. Test your restores
The single most skipped step, and the only one that proves the rest worked. Periodically restore a backup to a throwaway location and check the site actually comes up. A restore you've never run is a coin flip on your worst day.
The easy way
Done by hand, this is a pile of fragile glue: a cron job, mysqldump, a tar, a gpg step, an aws s3 cp, a retention script, and a restore runbook nobody has rehearsed. It's exactly the kind of thing that rots silently.
A panel should just do it. ShadowPanel runs scheduled, AES-256-encrypted backups of your files and databases straight to your own S3 or SFTP target, keeps a history with retention, stores your storage credentials encrypted at rest — and restores any snapshot in a click. You get all seven rules by default, instead of a runbook you hope still works.
Back up the right way
Free tier — 3 sites, no credit card — and you can install on any Ubuntu VPS in about ten minutes:
curl -fsSL https://shadowpanel.de/install.sh | bash