Backups and restores

Nautvia backs up your database. It does not back up your media volume or your server's disk — see Media volumes.

Daily backups

Turn them on per database from the Backups tab. From then on a dump runs every night at 03:00.

Retention comes from your plan:

Plan	Daily backups kept
Solo	7 days
Studio	14 days
Agency	30 days

Older dailies are deleted automatically. Manual and imported backups are never deleted automatically — they stay until you delete them, and they are billed for storage while they exist.

Taking one now

Back up now runs an immediate dump. Do this before anything you might regret: a module upgrade, a data patch, a bulk import.

How a backup runs

The dump is produced on your database server and uploaded straight to object storage:

mysqldump --single-transaction --quick --routines --triggers | gzip | curl -T - "$PRESIGNED_URL"

--single-transaction means it does not lock your tables, so it is safe on a live store. The upload uses a short-lived signed URL, so no storage credentials ever land on your server. Completion is confirmed by reading the object's size back, not by trusting the exit code.

Backups are stored in Germany, whichever location your servers are in — our backup storage exists only in Europe. For a store in Ashburn, Hillsboro or Singapore this means the dump crosses a region on its way out; it is encrypted in transit and at rest, but say so if that does not suit you.

Importing a dump from another host

Backups → Import uploads a .sql or .sql.gz of up to 5 GB from your browser straight to storage. It then appears in the list like any other backup, ready to restore.

Larger than 5 GB, or your dump lives on a server rather than your laptop? Write to [email protected] — see Migrating a store.

Restoring

This is the part worth reading before you need it.

A restore never overwrites your live database. It creates a new logical database on the same cluster, imports the dump into it, and stages it to the environment.

Your store keeps running on its current database throughout. To actually switch over, deploy. The old database is then detached — but not deleted, so you can switch back by attaching it again and deploying.

During import Nautvia strips DEFINER= clauses, CREATE DATABASE, USE and replication statements from the dump. Those are what make a dump from another host fail with permission errors, and removing them is what makes a foreign dump import cleanly.

A restore of a large database takes a while; the job allows up to three hours.

Downloading

Download gives you a link valid for five minutes. Keep your own copies of anything you cannot afford to lose — a backup that only exists in one provider's storage is one account problem away from not existing.

Verify your restores

Nobody has a backup strategy; they have a restore strategy. Restore into a new database occasionally and look at it — the whole point of restores not touching your live data is that testing one is free.

When a backup fails

Everyone on the team gets an email and an in-app notification with the reason. Backups are also skipped, silently and by design, when the database server is powered off — a stopped environment does not produce failures every night.