Overview

The Backup page lets you create point-in-time snapshots of your entire site content. If something goes wrong — accidental deletions, bad bulk edits, or corrupted data — you can restore to a previous state.

Backups can be stored locally or synced to cloud providers for off-site safety.

Creating a Backup

Click Create Backup to take a snapshot. The backup includes:

• All documents across every collection
• Media metadata (file references and alt text)
• Document statuses, schedules, and translation groups
• Site settings and configuration

Backups are stored as compressed archives alongside your content (local) or uploaded to your configured cloud provider.

Backup List

The page shows all available backups with:

• Date and time of creation
• Size — total archive size
• Document count — number of documents included
• Label — optional description you can add when creating
• Cloud badge — shows where the backup is stored: local, pcloud, or s3

Cloud Backup Providers

Backup destinations are pluggable. Configure them in the Backup tab under Settings.

Local (default)

Backups are stored on the server filesystem alongside your content. No configuration needed.

pCloud (WebDAV)

pCloud offers 10 GB of free storage with EU data residency. The CMS connects via WebDAV protocol.

To configure:

1. Go to Settings → Backup
2. Select pCloud as the backup provider
3. Enter your pCloud WebDAV credentials
4. Click Test Connection to verify

S3-compatible

Any S3-compatible storage provider works. Recommended options:

To configure:

1. Go to Settings → Backup
2. Select S3 as the backup provider
3. Enter endpoint, bucket, access key, and secret key
4. Click Test Connection to verify

Storage Quota Management

Set backupMaxStorageGB to automatically prune the oldest backups when the limit is reached. This prevents cloud storage from growing unboundedly.

Restoring a Backup

Click Restore on any backup to roll your content back to that point in time. This operation:

1. Replaces all current content with the backup's content
2. Preserves the current backup list (so you can undo the restore)
3. Creates an automatic pre-restore backup for safety

Warning: Restoring replaces ALL current content. Any changes made after the backup was created will be lost.

GitHub-backed Sites

Restore works fully for GitHub-backed sites. When restoring:

• Each document is pushed back to the GitHub repository via the GitHub Contents API
• The CMS fetches the current SHA for existing files to handle create vs. update correctly
• _data/ files (site settings, etc.) are always restored locally regardless of adapter

This means a restore on a GitHub-backed site updates both the local cache and the remote repository.

Best Practices

• Create a backup before major operations (bulk edits, AI generation runs, schema changes)
• Label your backups descriptively (e.g., "Before SEO rewrite" or "Pre-launch content freeze")
• Use cloud providers for off-site safety — local backups are lost if the server fails
• Set a storage quota to keep cloud costs predictable

Related

• Trash — recover individual deleted documents
• Site Settings — configure backup retention
• Storage Adapters — filesystem vs. GitHub storage