What 'Recovery Window' Means When Your Database Is Idle

How point-in-time restore works for low-traffic SQLite apps, why an idle database has a narrow visible window, and how to choose the right timestamp.

The 'recovery window' isn't a wall clock

Most backup products talk about retention as 'we keep your data for seven days.' That phrasing makes it sound like the recovery window is a window on a wall clock — pick any point in the last seven days and you can rewind to it. For most production databases that's roughly right, because most production databases are constantly being written to.

For an idle database — a side project, an internal tool, a low-traffic app between customer events — the recovery window doesn't behave that way. It tracks your data, not the clock.

What actually gets backed up

Borela watches your SQLite database for changes and continuously ships those changes to off-server storage. The keyword is changes. If nothing changes, nothing new gets shipped. Your storage doesn't grow, your bandwidth doesn't move, and Borela doesn't pretend a new 'snapshot' exists when there's no new data inside it.

This is the right behavior. A backup that consists of 'the exact same bytes as the last backup' isn't really a backup — it's a copy of a copy. But it does mean the dashboard surfaces the truth: your most recent restorable state is your last write, not the current second.

What you'll see on the dashboard

For an idle project, the dashboard shows something like 'May 2 18:00 → May 5 14:00 UTC (2d 20h of history) · idle 12h.' Read it as: 'I can rewind to any moment between those two times. The newest available state is from 12 hours ago.' That's the entire recovery story, accurately stated.

If you tried to restore to 'May 6 09:00,' Borela would give you the May 5 14:00 state — the most recent capture at or before the timestamp you asked for. There's no error. From the database's perspective, May 5 14:00 IS what May 6 09:00 looked like, because nothing changed between them.

Why this matters during recovery

The dangerous version of this would be: a customer panics, asks Borela to restore to 'an hour ago,' and Borela returns a database that's actually a week old without saying so. We considered showing an error in that case and decided against it. Quietly returning the most recent valid state is what every operator actually wants — they don't want a failure, they want their data back.

What the dashboard does instead is make the asymmetry visible. The 'idle' hint and the 'recent restore points' panel let you see, before you run the restore, what state you'd actually get. The system being honest about that beats it pretending there are seven days of distinct restore points when there are really one.

Choosing the right timestamp

For 'restore from before the bad deploy,' check your deploy log for the start time and use a timestamp a minute or two earlier. Borela rounds down, so being slightly early is the safe direction.

For 'restore last Tuesday at noon,' just write that timestamp. If the database was active at the time, you'll get a state from very close to that moment. If the database was idle on Tuesday, you'll get the last write before Tuesday — which is the same thing 'Tuesday at noon' actually was, data-wise.

For 'restore to a state I can compare against right now,' use borela-agent snapshots to list captured restore points and pick one. The dashboard's 'recent restore points' panel shows the last five for one-click reference.

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

When to expect a wider window

As soon as your app starts writing regularly — handling user requests, running background jobs, processing webhooks — the recovery window fills out. Each write produces a new captured state, and the visible window approaches the full retention period.

This means a busy app and an idle app have very different-looking dashboards even when they're equally well protected. Both can survive a disk failure. Both have seven days of retention. The busy app just shows more 'where you can rewind to' detail, because there's more interesting state to rewind to.

What this means for the babysitter tier

Borela's weekly verified-restore drill works the same way for idle and busy databases: it restores the latest captured state, runs integrity checks, and records the result. For an idle app, that's restoring the same state week after week — which is exactly the right thing to do, because it proves the chain still works, even if no new data has flowed.

Once your idle app starts writing again, you'll see the captured-state timestamp on the dashboard advance. Until then, the proof of recoverability is unchanged: we restore what's there, verify it, and tell you when it stops working.