Every guide to self-hosting anything ends with a line telling you to back it up. Almost none of them explain how, which is unfortunate, because backing up a Docker stack is not the same as backing up a folder and the difference is where the data goes missing.

Three things live in different places

A single copy of "the server" usually captures one of the three things you need to protect and misses the other two.

There is the configuration: compose files, environment files, the proxy configuration. These are small text files and they belong in version control. The caveat is that environment files hold secrets, and version control is not where secrets go.

There are the volumes: uploaded files, photographs, documents, certificates. Large, mostly static, and straightforward to copy.

And there are the databases, which look like files and are not.

Stopping the database is not the fix

The instinct on discovering that a running database cannot be safely copied is to stop the container, copy the files and start it again. It works, and it means the service is down for the duration of every backup, which is why nobody keeps doing it.

Dump the database instead of copying its files. A dump asks the database for a consistent export from a single point in time, which it can produce from a single transaction while still serving requests. Both of the common databases have a tool for it and neither requires downtime.

What you must not do is take a file-level copy of a database that is running. It will usually appear to work. It will restore into something subtly broken, and you will find out at the worst moment, which is the only moment anyone restores anything.

Order is not a detail

If the dump and the file copy are separate steps, the dump has to finish before the copy starts. Run them together and the copy captures a dump file that is half written, which restores as far as it got.

This is the most common way a sensible backup plan produces useless output. The two steps are often separate cron entries, scheduled minutes apart on the assumption the dump will be finished. It usually is. The night it is not is the night the database was busy, which correlates with the night you will want the backup.

Chain them explicitly. One script, in order, with the copy depending on the dump having exited cleanly.

Pruning belongs on its own schedule

Backup tools that keep history need to remove old snapshots eventually, and the temptation is to prune at the end of every run.

Pruning takes an exclusive lock on the repository, and on a large one it can hold it for a long time. A prune that runs at the end of the nightly backup can still be holding the lock when tomorrow's backup starts, at which point that backup fails, and the failure looks like a backup problem rather than a pruning problem.

Put pruning on its own schedule, weekly rather than nightly, at a time nothing else is running.

The tool choice is decided by where it goes

Comparisons of backup tools often focus on the wrong features. The deciding question is where the copy is going to live.

If the destination is object storage — the sort you rent by the gigabyte — some tools speak to it natively and others do not. If the destination is another machine you own, the picture is different and the tool that could not reach object storage may be the better one. Answer the destination question first and the tool choice mostly resolves itself.

Whatever you pick, the copy should be encrypted before it leaves, and the passphrase should exist somewhere other than the machine being backed up. A backup you cannot decrypt because the key was on the dead disk is a thorough way to have no backup at all.

Then restore it

A backup that has never been restored is a belief, not a copy.

Restore into a throwaway environment and check the thing you actually care about: log into the application, open a document, look at a photograph. Checking that files exist proves the files exist. It does not prove the database dump inside them is loadable, which is the part that fails.

Do it once when you set this up, and again when you change anything about it. The gap between having backups and having backups that work is where most data loss happens.

Where this comes from, and what will date

Composed from backup-tool documentation and several independent published strategies, cross-checked against each other on 31 August 2026. Which tools reach which storage back-ends changes as they add support, so check current documentation before choosing on that basis.

None of this is a disaster recovery plan. It is how to take a copy that will restore. How many copies, how far away, and how quickly you would need them back are separate questions, and the answers depend on what you would actually lose.