Server Backup System Setup
Backup system setup with verified restores
A backup you have never restored from is not a reserve copy, it is a hope. The surprises tend to surface at exactly the wrong moment: the database dump is truncated, the archive is inconsistent, the disk filled up three months ago, and the failure emails were going to spam.
What is included
- scheduled daily copies of the database and site files;
- pushing copies off the server — to another host or to object storage;
- rotation: several daily, several weekly, one monthly;
- copying the server configuration — without it a restore stretches into hours of reconstructing settings;
- alerts on failed runs, because silence is usually mistaken for success;
- a test restore onto a separate environment — so you know the copy works.
Why a copy on the same server does not count
It protects against an administrator's mistake or a bad update, which is worth something. But it does not protect against a disk failure, an account suspension at the host, or ransomware that reaches everything it has access to. So one copy always lives away from the main platform.
How many copies to keep
A single most-recent copy is a dangerous illusion. If the problem started three days ago and you have only just noticed, that one fresh copy already contains it. Retention depth is chosen to match your rhythm: for a store with dozens of orders a day this is enough, for busier ones the database needs copying more often.
What you receive
A working scheme with documentation: where the copies live, how to restore and how long it takes. Plus a restore proven in practice, rather than an assumption that it would work.
Tags: backup, linux, rsync, borg, disaster recovery