Backups that actually restore
This is the article we most wish people read on day one, because the day you need it is the worst possible day to discover you did it wrong.
We do not back up your server
Not the disks, not the databases, not quietly in the background. Our servers are unmanaged and we have no access to your data, so there is nothing for us to copy even if we wanted to. A failed disk or a bad command is yours to recover from.
The rule that has not changed in thirty years
Three copies, two different media, one off site. For a single server that usually means: the live data, a copy on another machine, and a copy somewhere else entirely — another provider, another country, your office.
A backup on the same machine is not a backup. A backup on a second disk in the same machine survives a disk failure and nothing else.
Tools worth using
- restic or borg — deduplicating, encrypted, incremental. Both are excellent and either will do.
- rsync with hard-linked snapshots — simple, transparent, easy to verify by hand.
- For databases: a real dump, or replication to a second machine. Never a file copy of a running database.
Encrypt before it leaves the machine, and keep the key somewhere other than the server it protects.
Test the restore, not the backup
A backup job that reports success every night proves only that a job ran. Once a quarter, restore something into a scratch directory and open it. People discover broken backups during an outage, and that is a bad moment to find out.
What ransomware changes
Anything your server can write to, malware on that server can also encrypt. Use append-only or pull-style backups: the backup host fetches from the server, rather than the server pushing with credentials that sit on it.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base