Automated off-site backups for every database

Every production database now backs up automatically to storage that lives outside the cluster it protects, and can be restored to any point in time within the last 30 days.

What changed

Before this, database protection was volume-level only. A restore could return a database to the last snapshot - up to a day earlier on the lowest tier - but not to a chosen moment. Recovering from a bad migration or an accidental delete meant losing everything since that snapshot.

Now the write-ahead log is shipped continuously as transactions commit, alongside a full base backup on a schedule set by the service's tier. The practical effect is that the recovery point is the last committed transaction, not the last snapshot.

Why off-site matters here

The backups deliberately do not live on the same storage as the databases. Keeping them there would put the backup in the same failure domain as the thing it protects, which is the one arrangement guaranteed not to help on the day it is needed.

How it was verified

The restore path was exercised end-to-end before the rollout: a database was backed up, restored into an isolated environment, and compared against the original row-by-row with content checksums. No data loss. Every service was then confirmed to hold both a live archive stream and a completed base backup - a backup that exists only in theory is not a backup.