Knowledge base · Backups

Schedules, retention and alerts

How backup windows work, how retention is enforced and crypto-shredded, and when VaultKeep emails you.

The schedule

Each project has one schedule, under the Schedule tab:

• Hour (UTC): the backup window. Jobs are queued during that hour; the exact minute depends on the queue.
• Frequency: daily or weekly. The Free plan is weekly regardless of the setting; pick the weekday.
• What to back up: the database, and optionally Storage buckets (paid plans, and only if the project has S3 keys).
• Retention (days): how long each backup is kept. Whatever you type is clamped to the plan's maximum (7, 30 or 90 days).
• Weekly verification: on by default. See Verified restores.

Business (managed) projects have two more settings:

• Interval: every 1, 2, 3, 4, 6, 8 or 12 hours, counted from the backup window. Storage sync runs on the same interval and only moves changed files. A missed hourly backup is flagged within about two hours, to you and to support.
• Retention tiers: hourly copies for 7 days, daily copies for 30 days and monthly copies for 12 months. The first backup of each UTC day is the daily copy and the first of each month the monthly copy; each copy is kept for its tier's days and then crypto-shredded. The policy is part of your agreement and is changed by support, not from the dashboard. Deleting a project on these plans pauses backups and destroys nothing for 7 days; every owner and support are emailed, and the deletion can be cancelled from the project page until then.

If an organization has more projects than its plan allows (for example after a downgrade), only the oldest N projects keep backing up until you remove some.

Retention and crypto-shredding

Every night at 04:10 UTC a sweep looks for backups older than their retention. For each one it:

1. deletes the objects from storage (managed R2 or your own destination);
2. destroys the backup's wrapped data key;
3. marks the backup as deleted and writes an audit entry with the number of objects removed.

Because the key is destroyed, an object that somehow survives step 1 is permanently unreadable. Storage-sync backups share unchanged objects with newer runs; the sweep keeps any object a newer manifest still references.

If your own destination is unreachable on the night of the sweep, the key is still destroyed and the failure is recorded in the audit entry. The leftover ciphertext can be cleaned up later, or left, since nobody can read it.

Alerts

Owners and admins are emailed when:

• a backup, storage sync, verification or restore job fails after its final retry;
• a weekly verification fails a check;
• a project has missed its backup window: no successful backup for 2 days (daily) or 8 days (weekly), at most once every 3 days;
• validation of new credentials fails.

Every alert links to the project. There is no separate notification setting yet; if you need a webhook or a Slack integration, tell us at support@vaultkeep.dev.

Running things by hand

On the project page: Back up now, Sync storage (if configured), and Verify on any successful backup. Manual jobs go to the front of the queue.

Still stuck? Email support@vaultkeep.dev with your project name (never your connection string) and we'll take a look.