Schedules and retention

Setting cadence and retention for a source, and understanding where those settings actually live.

Who owns what

The ownership model depends on the agent's mode:

• Managed mode. The orchestrator is the sole authority for schedules and retention. You set them in the dashboard; the agent receives them via heartbeat. There is no "override" concept; the dashboard value is the value.
• Standalone mode. The agent has no internal scheduler. System cron or systemd timers invoke one-shot commands (restorable backup, restorable restore-test, restorable prune). Schedule fields in config.yaml are documentation for the customer's crontab, not inputs to the agent.

Backup schedule

Managed mode

From the source detail page, Schedule section, set a 5-field cron expression (UTC). Changes reach the agent on the next heartbeat (default 60 seconds). The next backup runs at the next matching cadence boundary.

Standalone mode

Add an entry to your crontab or a systemd timer that invokes restorable backup --source <slug>. The backup_schedule field in config.yaml documents the intended cadence but the agent never acts on it.

Restore-test schedule

Independent from the backup schedule. Typical pattern: daily backup, weekly restore test. A restore test proves that backups taken since the last test are still restorable; weekly cadence is the sweet spot between catching drift early and not hammering the scratch environment.

Managed mode

Set the restore-test cron in the dashboard, same as the backup schedule. A manual Run restore test now button on the source detail page triggers a one-off test outside the schedule. This does not shift the next scheduled run.

Standalone mode

Add a crontab or systemd timer entry that invokes restorable restore-test --source <slug>. The restore_schedule field in config.yaml documents the intent; the agent does not act on it.

Retention

Managed mode

Restorable applies S3 Object Lock at upload time. The retention window is set per source in the dashboard (range 7 to 365 days), capped by your tier ceiling. Objects are immutable until the lock expires; neither you nor Restorable can delete them early.

Standalone mode

Set retention_days in config.yaml (minimum 7 days). The restorable prune command deletes backups older than the configured window from your storage bucket. Run it on a timer alongside backup and restore-test.

After expiry

In managed mode, the backup metadata row stays in the database after ciphertext expires. In standalone mode, restorable prune deletes both the ciphertext and its metadata file. In both cases, signed receipts persist independently (they live in the receipts directory, not alongside blobs), so the evidence chain stays verifiable even after ciphertext is gone.

Standalone mode summary

In standalone mode the agent runs without an orchestrator. Schedule fields in config.yaml are documentation for your crontab or systemd timer. The agent has no internal scheduler; it only executes backup, restore-test, and prune as one-shot commands. See Airgapped or cron for full setup instructions.

What cannot be set per source

A handful of things are org-wide, not per source:

• The weekly evidence email cadence (always Mondays).
• The transparency-log tree-head signature cadence (hourly).
• The operator impersonation auto-expiry (one hour).

Rate limits

The orchestrator refuses to queue more than one concurrent backup command per source, and more than two concurrent backup commands per agent. Rapid Run backup now clicks are absorbed into the same command if a run is already underway.

Restore tests run strictly one at a time per source. They can overlap with backups for the same source.