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.dbList the actual restore points
Run borela-agent snapshots to inspect retained replica files and their SAFE_TIMESTAMP_UTC values. Using one of those values includes the listed file in the restore plan. Several files captured in the same second can share a safe timestamp, so inspect the restored database before using it in production.
The dashboard's recent restore points panel shows the last five listed files. Select one to fill in a copyable restore command, or use borela-agent snapshots to inspect older history.
borela-agent snapshots -project appHow far back can I go?
Solo and grandfathered legacy plans retain seven days. Standard, Business, and Scale retain fourteen days. Older captures are pruned according to the applied tier policy; check the agent's reported policy status before relying on the full window.
The retention window is calculated from the present moment, not from your last write. If your database has been idle for the full window, 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'