Backups and point-in-time recovery
Backups plus a continuous change log let you restore to any second.
A nightly dump only takes you back to last night. Rowsafe keeps two things so you can go back to any second:
- Backups: a copy of the whole database, on a schedule.
- A change log: every change, archived to your bucket within about a minute.
To restore, Rowsafe starts from a backup and replays the log to the second you pick. That's Rewind.
Backup types
| Type | What it copies | Default schedule |
|---|---|---|
| Full | Everything | Sundays 01:00 UTC |
| Differential | What changed since the last full backup | Monday to Saturday 01:00 UTC |
| Incremental | What changed since the last backup of any type | On demand only |
Backups are compressed and encrypted on your server. Your bucket only holds ciphertext.
Run one now: rowsafe backup app (full) or rowsafe backup app --type diff.
The recovery window
You can restore to any moment from the start of the oldest kept full backup to the last archived change. The dashboard and rowsafe status app show where it starts.
- Retention counts full backups: default 2, about two weeks. Change it (1 to 52) in the database's settings or with
rowsafe set app --retention-full 4. - Old backups and their change log are removed for you. Don't add a bucket lifecycle rule that deletes objects: it breaks restores.
How much can you lose?
At most about a minute of changes, usually less.
Older setups archive every 5 minutes. Health shows "Backups can be up to 5 minutes behind"; Apply fix changes it without a restart.
If archiving stops (for example rotated bucket keys), a critical alert fires within about 10 minutes and the database is no longer protected.
Restoring
On the database's Rewind tab, pick any second in the window or a Mark, then:
- Restore a copy next to production, compare, and bring back lost rows. Production keeps running.
- Rewind the whole database, for the worst case. Undo for 7 days.
Server lost? Restore by hand onto a new one with pgBackRest. All three: Restore a database. Proof checks every week that restores work.
By database
| Backups | Change log | Restore to | |
|---|---|---|---|
| PostgreSQL | pgBackRest: weekly full, daily differential | the WAL (details) | any second, or a Mark |
| MySQL, MariaDB | XtraBackup or mariadb-backup: weekly full, daily differential | the binary log (details) | any second, or a Mark |
| MongoDB | mongodump: a full backup every day | the oplog (details) | any second, or a Mark |
| ClickHouse | ClickHouse's own BACKUP: weekly full, hourly differential | none | a backup (one every hour), or a Mark (details) |
| Redis, Valkey | a full snapshot (RDB), sent as to a new replica | every change, from the agent attached as a replica (details) | about a second, or exactly a Mark |
| OpenSearch | own snapshots: every 5 minutes (only what's new), a full one every day | none | a snapshot, or a Mark (details) |
| Qdrant | own snapshots, every 15 minutes (only changed collections) | none | a snapshot, or a Mark (details) |
| Meilisearch | own snapshot, every 15 minutes when something changed | none | a snapshot, or a Mark (details) |
- OpenSearch, Qdrant and Meilisearch: owners can set every 5, 15 or 30 minutes, or hourly, in Settings.
- A whole rewind stops PostgreSQL, MySQL and MariaDB briefly. The others keep running.