Choose a Restore Point

How recovery windows work, what timestamp to pass, and what an idle database looks like on the dashboard.

What 'recovery window' means

Your dashboard shows a recovery window like 'May 2 18:00 → May 9 14:32 UTC (7d of history).' That's the time range Borela can restore your database to. The left side is the oldest captured state; the right side is the most recent one.

You can restore to any UTC moment between those two times. You don't have to match an exact entry in some list — Borela picks the closest captured state at or before the timestamp you ask for.

Idle databases look different (and that's fine)

Borela only captures changes when your database is being written to. If your app is quiet for hours, no new captures happen. The 'most recent state' on the dashboard will be your last write, not the current wall-clock time.

You'll see this on the dashboard as 'idle 12h' next to the recovery window. That doesn't mean backups are broken — it means there's nothing newer to back up. Restoring to 'now' or 'an hour ago' both give you the same state: whatever was there at the last write.

Choose a timestamp

Use UTC RFC3339 format, e.g. 2026-04-25T18:00:00Z. Pick a moment a little before whatever you want to recover from — Borela rounds down, never up, so being slightly early is safer than being slightly late.

For 'restore from before the bad deploy at 13:42 UTC,' use 13:41 or earlier. For 'restore last Tuesday at noon,' use 12:00:00Z that day.

If your database has been idle and the timestamp you want is newer than the last captured state, you'll get the last captured state. There's no error — that's the latest data Borela has, and it's the same thing your app would have served right before you ran the restore.

borela-agent restore -project app -timestamp 2026-04-25T13:41:00Z -output /tmp/restored.db

List the actual restore points

For exact captured timestamps, run borela-agent snapshots. It prints every retained restore point with a column called SAFE_TIMESTAMP_UTC — copy any value from that column and you'll get exactly that captured state.

This is most useful when you want to compare two specific historical points (e.g., 'restore yesterday at 09:00, then again at 10:00, diff the user table to see who signed up'). The dashboard's 'recent restore points' panel shows the last five for quick reference.

borela-agent snapshots -project app

How far back can I go?

Borela retains seven days of history by default. After seven days, older captures are pruned to keep storage costs predictable. If you need longer retention, that's a setting we can adjust per project — open a support email and we'll work with you.

The seven-day window is calculated from the present moment, not from your last write. If your database has been idle for a week, your earliest available capture might be very close to your latest one.

Always restore to a temporary path

Don't restore directly over your live database file. Restore to /tmp first, inspect the result, then promote it deliberately. Borela's restore command requires -output for exactly this reason: there's no way to accidentally clobber production from one typo.

If the restored file looks right, stop your app, move the current database aside (don't delete it — you may want it later as evidence), copy the restored file into place, fix permissions, and restart.

borela-agent restore -project app -timestamp 2026-04-25T13:41:00Z -output /tmp/restored.db
sqlite3 /tmp/restored.db 'PRAGMA integrity_check;'
sqlite3 /tmp/restored.db '.tables'