Snapshots

Snapshots are the backup files created when you backup a database. They contain all the data needed to restore your database to a specific point in time.

File Verification

Databasement verifies daily that backup files still exist on their storage volumes. Missing files are surfaced on the dashboard and in the jobs index with a "File missing" warning.

You can also trigger verification manually from the dashboard.

See Backup Configuration for BACKUP_VERIFY_FILES and BACKUP_VERIFY_FILES_CRON settings.

Deleting Snapshots

On the Snapshots page, tick the rows to delete, or tick the header checkbox to select the whole page and then Select all matching snapshots to extend the selection to every snapshot matching the current search and filters. Filtering on File missing first is a quick way to clean up snapshots whose files were removed from the volume.

Deletion runs in the background on the queue worker, and the snapshots show as Deleting until they are removed. Locked snapshots and snapshots whose backup is still in progress are skipped. Through the API, use DELETE /api/v1/snapshots/{id} for one snapshot or POST /api/v1/snapshots/bulk-delete with a list of ids for many.

Restore Process

When you restore a snapshot, Databasement:

1. Downloads the snapshot from storage
2. Decompresses the backup file
3. Connects to the target database server
4. Drops and recreates the target database (if it exists)
5. Restores the data using native database tools

A pending or running restore can be cancelled from the Restores page or its job logs, with the operate-restores ability. It stops at its next step, or within 30 seconds while a command runs. A restore cancelled after step 4 leaves the target database partially restored.

Restore Commands

MariaDB (10.2 and later):

mariadb --host='...' --port='...' --user='...' --password='...' --skip_ssl \
  'database_name' -e "source /path/to/dump.sql"

MySQL (and MariaDB below 10.2), using the bundled Oracle client:

/opt/mysql-client/bin/mysql --host='...' --port='...' --user='...' --password='...' --ssl-mode=DISABLED \
  'database_name' < '/path/to/dump.sql'

PostgreSQL:

PGPASSWORD='...' psql --host='...' --port='...' --username='...' \
  'database_name' -f '/path/to/dump.sql'

Custom-format snapshots are restored with pg_restore instead, one table at a time by default. For large databases, tick Parallel restore (4 jobs) in the restore dialog to run it with --jobs=4. Leave it off when the database uses an extension whose tables reference each other, such as pgAgent: a parallel restore loads their data in any order and fails their foreign keys.

SQLite:

cp '/path/to/snapshot' '/path/to/database.sqlite'

Firebird:

gbak -rep -user '...' -password '...' '/path/to/dump.fbk' 'host/port:/path/to/target.fdb'

MongoDB:

mongorestore --host='...' --port='...' --username='...' --password='...' \
  --authenticationDatabase='admin' --archive='/path/to/dump.archive' \
  --nsFrom='source_db.*' --nsTo='target_db.*' --drop

info

Redis/Valkey restore is not currently supported. RDB file imports require direct server access.

All snapshots are decompressed with gzip -d before restore.

Scheduled Restores

You can replay the latest completed snapshot of a source database onto a target server on a recurring schedule — useful for keeping a staging or QA database refreshed from production.

A scheduled restore is configured with:

• Source server (and database name, unless the type is whole-instance like SQLite or Redis)
• Target server and destination database name/path
• Schedule — reuses the same cron schedules defined under Configuration → Backup

On each run, Databasement picks the most recent completed snapshot of the source database and runs the normal restore process against the target. Source and target must be of the same database type.