Ask a new Docker user what they back up and they often say the containers. That sounds sensible and it is wrong. Containers are meant to be disposable: they are built from images that can be pulled again at any time. What cannot be rebuilt from an image is your data, and that is what a backup strategy must protect.

A one-server project needs a backup plan that is simple enough to actually run and complete enough to actually restore from. The plan below covers the three things that matter: the data volumes, the configuration, and a tested restore. Everything else is optional.

Application data lives in volumes: database files, uploaded content, and configuration that the container writes while running. Those volumes are the irreplaceable part of your setup, and they are what your backup must copy. A running database should be backed up with its own dump tool where possible, because copying live database files directly can produce a corrupt backup.

Alongside volumes, back up your compose files and environment files, which describe how everything fits together. These small text files are the recipe for rebuilding your whole stack, and without them a data restore becomes guesswork. Store them in version control or alongside the backups, so the recipe and the ingredients travel together.

Follow the simple rule: at least one copy off the server. A backup that lives on the same disk as the original protects against accidental deletion, but not against disk failure, which is the failure you most need to survive. An off-site copy can be another cheap server, an object storage bucket, or even an external drive rotated regularly.

Automate the copy with a scheduled job, and keep a few generations rather than a single latest copy. If corruption or a bad change goes unnoticed for a week, a single backup may contain the same problem. Three or four rotating copies give you a way back to before the problem appeared.

An untested backup is a hope, not a plan. Once a quarter, restore your backup to a separate location and check that the application actually starts and the data is intact. This test regularly reveals small surprises: a missing environment file, a volume path that changed, or a backup job that quietly stopped running months ago.

Write down the restore steps while you test them, because the person restoring after a real failure will be stressed and in a hurry. A short document with the commands in order turns a crisis into a procedure. The best backup strategy for a one-server project is not the most sophisticated one. It is the one that has been tested and can be followed at midnight under pressure.

Practise your restore on a fresh server, not just on the same machine, because a real disaster may mean new hardware. Install the container runtime, copy your compose and environment files, restore the volumes from backup, and start the stack. Note every step that required guessing, and fix the documentation so the next restore needs none.

After the restore, verify more than startup: log in, check recent data, and confirm scheduled jobs run. A stack that starts but serves stale data is a partial failure dressed as a success. A restore test that checks real functionality, done quarterly, is the difference between believing you have backups and knowing you have them.