Open Backup and restore in the CMS sidebar. Backups contain all saved pages, media, site settings, custom themes and templates, and installed packages. Save any open edits first: text still only in a browser tab is not part of a backup.

Automatic backups

The CMS takes its first backup when it starts, then checks every minute for the next scheduled backup. The default interval is one day. An administrator can change spec.backup.interval on the Website, for example 24h or 48h. Backups run while the CMS is running; after downtime, an overdue backup is taken at startup rather than attempting to recreate missed snapshots.

The list shows the three grandfather/father/son retention periods:

One archive can cover several periods. The CMS automatically deletes a scheduled archive when it no longer covers a period, unless it is marked Do not delete. Manual backups remain until you delete them. A custom interval changes the time between snapshots; the daily slot still means the latest scheduled snapshot. The dialog shows when the next backup is due and any scheduled-backup error.

Take a backup or download one

1. Save your changes and open Backup and restore.
2. Optionally select Do not delete this backup.
3. Choose Back up now to keep an internal backup, or Back up and download to also save a ZIP to your computer.

Choose Download beside an existing backup to download that snapshot without taking another. Filenames contain the Website name, a UTC RFC3339 timestamp and a short unique suffix, for example example_2026-11-10T15:04:05Z_a1b2c3d4.zip.

Choose Do not delete beside an existing backup to protect it. Choose Allow deletion before deleting a protected backup. Protection does not prevent restoring or downloading the backup.

Internal archives are stored on the site's private storage volume and are never published. Download copies to separate storage if you need to recover from a lost volume. Downloads contain the site's editable source and media; keep them somewhere appropriate for that content.

Restore a saved site

Restore replaces the whole saved editable site, including pages created since the backup. Ask other editors to stop saving during the restore and reload their tabs afterward. Unsaved changes in the restoring tab are discarded after you confirm. The CMS lets active operations finish, then rejects new requests until restore completes, so a waiting save cannot overwrite the recovered site.

1. Choose Restore beside an existing snapshot, or select a downloaded Viking ZIP in Backup ZIP and choose Upload and restore.
2. Confirm Restore site. Leave the tab open until the operation completes.
3. The CMS validates the archive and makes a protected before-restore safety backup of the current saved site. If validation or the safety backup fails, it leaves the current site in place.
4. After success, the editor reloads. Review pages, media, settings and themes.
5. Choose Publish when ready to update the public site. Until then visitors continue seeing the previously published version.

To undo a restore, restore its protected before-restore backup. Restore requires the same additional role as publishing when your administrator has configured publication roles. Backups themselves remain available after a restore; they are not copied into the archive or replaced by restoring it.

ZIP uploads/archives are limited to 2 GiB, with at most 8 GiB of expanded files and 100,000 content files. The private volume needs room for archives, temporary extraction and the safety backup. Large restores can take several minutes. An ordinary ZIP assembled by hand is not a Viking backup: the archive includes a versioned manifest with file sizes and SHA-256 checksums.

Site backups cover saved editable content. Published release history, Kubernetes configuration, sign-in credentials and accounts are managed separately. Administrators should also follow the storage disaster recovery procedure.