🚧 FastCMS is under active development — not ready for production use. APIs and features may change without notice.
FastCMS
Infrastructure

Backup & Restore

Database backup and restore with a safe two-phase restoration process. Automate with cron and store backups off-site for disaster recovery.

Backup & Restore

FastCMS provides database backup and restore functionality to protect your data and enable disaster recovery.

localhost:8000/admin/backups

Database Backups

Create and manage database backups for disaster recovery

Total: 12 backups
Page 1 of 1
FilenameSizeCreatedPathActions
backup_2026-03-04_09-00-00.db
4.2 MB2026-03-04 09:00data/backups/backup_2026-03-04_09-00-00.db
backup_2026-03-03_09-00-00.db
4.1 MB2026-03-03 09:00data/backups/backup_2026-03-03_09-00-00.db
backup_2026-03-02_09-00-00.db
4.0 MB2026-03-02 09:00data/backups/backup_2026-03-02_09-00-00.db
backup_2026-02-28_09-00-00.db
3.9 MB2026-02-28 09:00data/backups/backup_2026-02-28_09-00-00.db

Important Backup Information

  • Restoring a backup will OVERWRITE your current database
  • Always create a backup before performing major operations
  • Store backups in a secure location separate from your server
  • Test your backups regularly to ensure they can be restored

What Gets Backed Up

A backup includes:

  • Database file (app.db)
  • Uploaded files in data/files/
  • Backup metadata (timestamp, app version)

Creating a Backup

Via API:

curl -X POST "http://localhost:8000/api/v1/backups" \
  -H "Authorization: Bearer ADMIN_TOKEN"

Response:

{
  "filename": "backup_20250115_100000.zip",
  "size_bytes": 1048576,
  "created": "2025-01-15T10:00:00",
  "path": "data/backups/backup_20250115_100000.zip"
}

Via Admin Dashboard:

  1. Navigate to /admin/backups
  2. Click Create Backup
  3. Download the backup file

Listing Backups

curl "http://localhost:8000/api/v1/backups" \
  -H "Authorization: Bearer ADMIN_TOKEN"
{
  "items": [
    {
      "filename": "backup_20250115_100000.zip",
      "name": "backup_20250115_100000",
      "size_mb": 1.5,
      "created": "2025-01-15T10:00:00"
    }
  ],
  "total": 1
}

Restoring from a Backup

Restore requires a server restart to complete safely.

Step 1: Stage the restore

curl -X POST "http://localhost:8000/api/v1/backups/{filename}/restore" \
  -H "Authorization: Bearer ADMIN_TOKEN"

Response:

{
  "status": "pending_restart",
  "message": "Backup staged for restore. Please restart the server to complete restoration.",
  "backup_filename": "backup_20250115_100000.zip"
}

Step 2: Restart the server

uvicorn app.main:app --host 0.0.0.0 --port 8000

On startup, the server will automatically:

  1. Detect the pending restore
  2. Back up the current database to .db.before_restore
  3. Replace the database with the backup
  4. Restore all files
  5. Clean up the staging marker

How Restore Works

The restore process uses a two-phase approach to avoid database locking:

Phase 1 — Staging (when you call the restore endpoint):

  • Extracts backup to data/backups/restore_staging/
  • Creates a .restore_pending marker file
  • Returns immediately

Phase 2 — Execution (on server startup):

  • Detects the .restore_pending marker
  • Backs up current database first (safety net)
  • Replaces database and files from staging
  • Cleans up staging directory

This ensures no locking conflicts and automatic safety backup.

Deleting a Backup

curl -X DELETE "http://localhost:8000/api/v1/backups/{filename}" \
  -H "Authorization: Bearer ADMIN_TOKEN"

Automated Backups

Linux/Mac (cron) — Daily at 2 AM:

0 2 * * * curl -X POST http://localhost:8000/api/v1/backups \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Python script:

import requests
import schedule
import time

def create_backup():
    response = requests.post(
        'http://localhost:8000/api/v1/backups',
        headers={'Authorization': 'Bearer YOUR_ADMIN_TOKEN'}
    )
    if response.status_code == 200:
        print(f"Backup created: {response.json()['filename']}")

schedule.every().day.at("02:00").do(create_backup)
while True:
    schedule.run_pending()
    time.sleep(60)

Best Practices

  1. Regular Schedule — Back up daily or before major changes
  2. Retention Policy — Keep 7 daily, 4 weekly, 12 monthly backups
  3. Test Restores — Monthly test restore to verify backups work
  4. Off-site Storage — Copy backups to S3, GCS, or Azure Blob
  5. Monitor Space — Ensure adequate disk space for backup files

Disaster Recovery

Complete data loss scenario:

  1. Stop the FastCMS application
  2. Locate your most recent backup file
  3. Extract the backup:
    unzip data/backups/backup_20250115_100000.zip -d data/backups/restore_staging
  4. Replace database:
    cp data/backups/restore_staging/database.db data/app.db
  5. Restore files:
    cp -r data/backups/restore_staging/files/* data/files/
  6. Restart FastCMS and verify data

Backup Storage

PropertyValue
Default locationdata/backups/
Filename formatbackup_YYYYMMDD_HHMMSS.zip
Contentsdatabase.db, files/, metadata.json

On this page