Skip to main content

​
SafariDesk Backup and Restore

SafariDesk production backups must cover:
  • PostgreSQL database
  • Uploaded files
  • .env
  • Release version or image tag
The repository includes backup and restore scripts in:
Related pages:

​
What Must Be Backed Up

Do not rely on container filesystems for persistence.

​
Backup Script

Create a backup:
The script writes to:
Expected output files:
The database backup command runs inside the db container and uses the actual container environment:
The uploads backup command reads /mnt/safaridesk through the backend container.

​
Custom Backup Directory

Set BACKUP_DIR to write backups somewhere else:
Make sure the target directory exists or can be created by the current user.

​
Back Up .env

The script does not copy .env. Back it up separately using your secret-management or server-backup process. Manual example:
Protect this file. It can contain:
  • Django secrets
  • Database password
  • SMTP password
  • OAuth secrets
  • AI provider keys
  • License key
  • Stripe keys
  • Twilio credentials

​
Verify a Backup

List backup files:
Check the SQL file is not empty:
Check the uploads archive:
For production, periodically test restore on a separate non-production host.

​
Restore Database Only

Stop background processing before restore:
Restore the database:
Start services:
Run health checks:

​
Restore Database and Uploads

Stop services that can write data:
Restore database and uploads:
Start services:
Collect static files:
Run health checks:

​
Restore Behavior

The restore script:
  1. Runs psql inside the db container.
  2. Reads the SQL backup from the host.
  3. Optionally clears /mnt/safaridesk/* inside the backend container.
  4. Extracts the uploads archive into /mnt/safaridesk.
Important:
  • Upload restore replaces current upload contents.
  • Database restore imports into the current database.
  • Test restore before relying on the process for production incidents.

​
Restore to a New Host

  1. Install Docker and Docker Compose.
  2. Clone the SafariDesk monorepo.
  3. Restore the production .env.
  4. Confirm SAFARIDESK_IMAGE_TAG matches the backup.
  5. Start database and Redis:
  1. Restore database and uploads:
  1. Start the full stack:
  1. Collect static files:
  1. Verify:

​
Backup Before Updates

Always back up before:
  • Pulling a new release
  • Running migrations
  • Changing image tags
  • Changing database settings
  • Changing upload storage
  • Running large data imports
Recommended pre-update command:
See Update Guide.

​
Backup Scheduling

The repository does not install a scheduler by default. Use host cron, systemd timers, or your infrastructure backup tool. Example cron entry:
Move backups off the application server after creation. Recommended remote targets:
  • Object storage
  • Encrypted backup server
  • Managed backup service
  • Company disaster-recovery storage
Placeholder links:

​
Retention

Choose a retention policy before production use. Example:
  • Hourly backups for 24 hours
  • Daily backups for 14 days
  • Weekly backups for 8 weeks
  • Monthly backups for 12 months
The repository does not currently include automatic pruning. Add pruning only after confirming backups are safely copied off-server.

​
Restore Checklist

  • Correct backup files selected.
  • .env restored.
  • SAFARIDESK_IMAGE_TAG matches the backup.
  • Current database backed up before restore.
  • Write services stopped.
  • Database restored.
  • Uploads restored if needed.
  • Services restarted.
  • Static files collected.
  • Health checks pass.
  • Login works.
  • Uploads open.
  • Worker and beat are running.