Backups are a security control

Backups are usually filed under reliability. They are equally a security control, because the answer to a compromise, a ransomware event and a bad deploy is the same: go back to a known good copy. What decides whether that is possible is where the copy is and who can reach it.

The test that matters

Assume an attacker has your server and every credential on it. Which copies survive? If the answer is none, you do not have a backup - you have a second copy of the same risk.

What survives

• Off-site, on a different provider - see off-site copies.
• Write-only from the server. The server can add a backup and cannot list or delete one.
• Versioned or immutable, so overwriting with corrupted data does not destroy the good copy.
• Retained long enough to cover a compromise you did not notice for a month.

# a push-only key: the server can write, and nothing else
restic -r s3:s3.example.com/backups backup /var/www /var/lib/mysql
# the credential used here has PutObject and no DeleteObject

Retention beats frequency

Hourly backups with two days of retention are useless against something that started three weeks ago. Keep daily for a month and monthly for a year - see retention: how long is enough.

Restoring a compromised site is not a restore