Back up a database

Goal. Take a backup you can actually restore from. About two minutes.

You need. A database, and the ability to stop whatever is writing to it.

Stop, copy, start

A Strata database is a directory, so the backup tool is the one you already use:

strata ./mydb stop
cp -r ./mydb ./mydb-backup

tar, rsync, a filesystem snapshot and a cloud sync all work the same way. There is no backup command because there is nothing a backup command would know that cp does not.

Verify the copy

A copy is a real database, not a pointer at the original:

strata ./mydb-backup kv get important
strata ./mydb-backup kv put probe 1
strata ./mydb --raw kv count
strata ./mydb-backup --raw kv count

The two diverge from the moment you write to either. That makes a copy a reasonable way to fork an environment, not just to archive one.

What happens if you do not stop first

This is the part worth seeing, because it fails quietly.

A database hosted by a running process, copied while it runs:

strata ./mydb start &
strata ./mydb kv put b 2
strata ./mydb --raw kv count

2

cp -r ./mydb ./mydb-livecopy
strata ./mydb-livecopy --raw kv count

1

The original has two keys. The copy has one. No error, no warning: the copy opens cleanly and is simply missing a write.

The reason is not exotic. Files in the directory are not written atomically with respect to each other, so a copy taken mid-flight captures a moment that never existed as a whole. Every embedded database has this property, and the fix is always the same: quiesce first.

If you cannot stop the writer

Use a filesystem-level atomic snapshot, such as an LVM or ZFS snapshot or a cloud volume snapshot, and copy from that. Those capture the whole directory at one instant, which is the property cp lacks.

Failing that, accept that the copy may be missing recent commits and treat it as a point-in-time approximation rather than a backup.

What a backup does not need

No schema export, no dump format, no version-matched restore tool. The on-disk format is version 1 and every 1.x binary reads it, so a copy taken today opens on a later 1.x release without a migration step. Compatibility and versioning covers what that promise is worth.

Failure modes

The copy is missing recent writes. It was taken while a process held the database. See above.

The copy will not open. If the source was mid-write, the manifest can be inconsistent, and the open fails with unavailable.engine.persistence rather than returning wrong data. Recover from errors covers what to do.

You backed up an empty directory. Check the path. A mistyped path creates a new empty database rather than failing, so a backup script pointed at one quietly archives nothing. Troubleshoot failures has that one.

Next

Inspect database health.