Manual Backup

Automatic backups run on a schedule, but you can also take a point-in-time backup any time you want — before big content changes, before applying an update, or as an off-site copy to download and store elsewhere. Everything lives under Backups in the admin area.

Creating one

Click Create backup on the Backups page. The archive builds in the background and, when finished, your browser downloads the .tar.gz file directly — named chinaski_backup_<date>_<time>.tar.gz.

• Contents: the database, the media library, themes, and site templates — a complete point-in-time capture.
• Verification: unless you turned verification off, the archive is checked (extract-and-validate) before it’s published; a failed verify keeps a bad archive from being stored.
• Publish then prune: the archive lands in the instance’s local backups/ directory via an atomic rename — the listing never shows a half-written file — and the local retention policy applies (keep the last N backups and/or backups for N days), with every pruned file logged to the audit trail including the retention values used.

Two long-running edge cases are handled for you: creation runs against a two-minute watchdog (a wedged tar aborts with a “took too long” flashback rather than hanging the page), and a scheduled backup firing in the same second as a manual one can’t interleave — the staging names are process-id separated.

Getting archives off the server

Any archive in the local list (not just one you just made) can be downloaded from the Backups page — the download route streams the file as an attachment. File names are validated against the exact backup-name pattern, so the download control only ever serves backup archives.

Space (DigitalOcean Spaces) copies are listed separately when configured; local files and Spaces copies are tracked independently (uploading to Spaces is a separate action on the local backups list).

Cleaning up

• Delete removes a local archive (single click on its entry, audited with the filename in the record).
• Local retention is the same policy that applies to scheduled runs: keep the last N backups and/or backups for N days, both configurable in the Backups tab (0 = unlimited for either). Pruning runs after every backup creation, manual ones included, and each pruned file is recorded in the audit trail with the retention reason.
• Staged-but-unfinished uploads from a crashed creation are swept automatically (anything in staging older than an hour), so failed attempts don’t pollute the listing.

What manual backups are for

The schedule covers the everyday drift; manual ones are for moments you want a guaranteed-matching pair: right before a deploy of new template files, before a restore dry-run experiment, or as the macOS-style “golden” archive you download and keep elsewhere. Since the archive is the same format the restore path consumes, a manual download doubles as an off-server recovery artifact — the disaster-recovery runbook consumes exactly this file.