How often to drill

The interval between drills has an exact meaning, and it is not “how diligent we are”. It is the longest a backup can be broken before you find out. Drill weekly and you have accepted being wrong for up to a week. That is a defensible position for most databases; it is only indefensible when nobody has said it out loud.

What a drill costs

A drill is a real restore, so it costs what a restore costs: the I/O to move the archive, the time to replay it, and a sandbox for the duration. The measurement is in the evidence — the restore duration is recorded separately from the checks — so after the first few drills the cost is not an estimate.

It costs nothing on the database itself. The restore happens in a disposable sandbox from a backup that already exists, and Probavi runs no agent on the database host. Whatever the interval, production does not feel it.

Choosing an interval

Work from the consequence rather than from the calendar.

Daily for the database whose loss would end the business, or whose recovery time objective is measured in hours. If a broken backup is an existential problem, a week of not knowing is not a schedule, it is a gamble.

Weekly for the ordinary case. Long enough that the cost is trivial, short enough that a silent failure is caught inside one billing cycle of the data it affects.

Monthly for archives and cold data that changes rarely, where the failure mode is media or key loss rather than a drifting job.

A game-day quarterly, or after any change to the recovery path. A single drill proves one database restores; a game-day proves a whole service comes back in dependency order, and that is a different claim.

Two adjustments are worth more than the base interval. Drill after every change to the backup path — a new engine version, a new retention policy, a moved repository — because that is when backups break, not on a random Tuesday. And drill the database you understand least more often than the one you understand best: the estimate you are least sure of is the one worth measuring.

The trend needs repetition, not frequency

Restore duration tracked across drills is what turns a passing history into an early warning. The number drifts upward long before it crosses your stated objective, and the drift is visible while there is still time to act.

That signal comes from having enough comparable measurements, not from having them close together. Weekly drills over six months give twenty-six points against a moving baseline. Daily drills over three weeks give twenty-one points that all look the same, because the database did not grow enough in three weeks to say anything.

If the trend is what you are after, the useful lever is consistency — same source, same sandbox parameters, same checks — rather than a shorter interval. Changing the sandbox memory limit between drills makes the earlier measurements incomparable, and a trend built from incomparable numbers is worse than no trend at all.

Periodic, in the sense the frameworks mean

Recovery-testing obligations are generally written as periodic testing that is documented, rather than as a specific interval. A drill on a timer satisfies the periodic part by construction, and the evidence log satisfies the documented part without anyone writing a report.

That is a reason to pick an interval you will actually keep rather than the shortest one you can imagine. An interval that survives a year of ordinary operations produces a year of dated records; an ambitious one that gets switched off in month two produces an awkward gap in exactly the history it was meant to build.

Probavi supports demonstrating compliance; it does not make anyone compliant and guarantees nothing. Which obligations apply to you, and what satisfies them, is a question for your own advisors.

Where the scheduling itself lives

Probavi ships no scheduler and no daemon. Drills are started by cron or a systemd timer, with a lock file and a timeout, and the mechanics — including the flock pattern to copy — are documented in the repository under running on a schedule.