Backup of a Database

ArcadeDB allows to execute a non-stop backup of a database while it is used without blocking writes or affecting performance.

There are two ways to perform backups:

  • Manual backup - Execute a one-time backup using SQL or the Studio UI

  • Automatic backup - Schedule recurring backups with retention policies (see Automatic Backup Scheduler)

For manual backups, you can execute the backup of a database from SQL. Look at Backup Database SQL command for more information.

Consistency of TimeSeries data

A backup captures the database schema at a single point in time. TimeSeries types keep their compacted history in separate .ts.sealed files, which are archived alongside it.

(Since v26.10.1) the schema and the list of those files are captured together, so an archive can no longer declare a TIMESERIES type whose data it does not contain. Previously a DROP TYPE running at the same moment as a backup could produce exactly that, and the backup still reported success.

(Since v26.10.1) if one of those files cannot be read while the backup runs, the backup now fails with an error naming the file instead of skipping it and reporting success.

This is deliberate. An archive that silently omits data its own schema declares looks valid until a restore is attempted, which is the worst moment to discover it. A failed backup is visible, and simply running it again produces a consistent archive. The same applies when the database directory cannot be listed at all: that is an error rather than being read as "this database has no TimeSeries data".

Note that this costs nothing in availability. The database is locked only long enough to take the snapshot and list the files, not for the duration of the backup, so schema changes still run normally while a backup is in progress.

Configuration

  • -f <backup-file> (string) filename of, or path to the backup file to create.

  • -d <database-path> (string) path on local filesystem where to find the ArcadeDB database.

  • -o (boolean) true to overwrite the backup if already exists. If false and the backup-path already exists, an error is thrown. Default is false.

Cloud Backups

In a container setting it may become necessary to send backups to an S3 bucket instead of a mounted volume. Currently, ArcadeDB does not support writing a backup to S3 directly, but there are two ways of achieving this:

  1. Using an intermediary container which forwards a volume’s contents to an S3 bucket. The project docker-s3-volume makes this easy.

  2. Mounting an S3 bucket inside the ArcadeDB container directly with the S3 file system via filesystem in userspace.