Schedule & Retention

Chinaski keeps your content safe with backups on two axes: your app or your server can schedule them automatically, and either can prune old ones to keep disk use bounded. This page explains the schedule settings, what runs when, and how retention works.

Scheduling backups in the app

Under Settings → Backups you can enable automatic backups with two settings:

Backup frequency: Off (default), Daily, or Weekly.
Backup time: the local time to run, default 02:00.

When enabled, the app checks every minute and starts a backup the moment the clock reaches your configured time: once per day for a Daily schedule, or no more than once every seven days for Weekly. If several server workers are running, coordination is handled internally: exactly one fires, and timestamps stored in settings prevent a second run in the same window.

A scheduled run does the whole pipeline on its own:

Creates the archive (database snapshot plus application files), the same safe snapshot procedure manual backups use; failures are recorded as failed runs in the backups history and in the audit log, and the skipped time window can retry later.
Verifies the archive: every backup is smoke-tested (restoration check) before it’s placed in the backups folder, unless you turn verification off. Each run records whether verification passed, failed, or was skipped.
Publishes the archive to the local backups folder and, if you’ve configured cloud storage (an S3-compatible “Spaces” target with keys set in Settings → Backups), pushes it there. In airgap mode nothing leaves the host. If the stored cloud storage key can’t be read, the remote push is skipped rather than attempted half-configured.

Retention (how many backups to keep)

Two settings in Settings → Backups bound how many backups pile up locally: both default to 0, meaning unlimited (retention is opt-in):

Keep last N local backups: delete the oldest archives once more than N exist.
Keep local backups for N days: delete archives older than that many days.

Details worth knowing:

The two rules combine generously, not strictly: a file is only deleted when it is both beyond the last N and older than the day limit (“keep whichever is more generous”).
The backup list page previews the effect: you can see how many backups the current policy would delete before it ever runs.
Every automatic deletion is recorded in the audit log with the policy that triggered it.
Retention sweeps also run once when the app starts, in case backups piled up while the server was down.
Archive naming is timestamped (chinaski_backup_YYYYMMDD_HHMMSS.tar.gz), so nothing is overwritten silently.

The server-side scheduled backup (OS level)

There’s a second, independent scheduling system shipped for systemd deployments:

A daily timer (chinaski-backup@) fires at 03:17 local time (chosen minute to spread load if multiple instances share a host), with a small random delay, and it catches up if the host was off when it should have run.
The backup script makes a consistent snapshot of the database (safe while the CMS is live), gzips it, verifies the file, and stores it under /var/backups/chinaski<instance>. Media files are mirrored alongside. Snapshots older than 14 days are deleted; change that with CHINASKI_BACKUP_RETENTION_DAYS in the instance’s env file (the backup and media paths can also be overridden).
Snapshot and media are owner-only readable (0700 directory).
Before trusting the timer, run a manual backup and confirm both parts complete.

Keeping the two straight

The application scheduler and the OS timer do similar jobs with different scopes (full archive vs database + media snapshot; app-managed retention vs the 14-day default). Running both is fine and conservative. Whichever you rely on: watch the Backups tab’s history: each scheduled attempt records its outcome (success, failure, and what sort of manual/scheduled/API/push backup it was), including verification results for every run.