I'm running around 15 containers, including services such as Jellyfin, Paperless, and Vaultwarden, on Ubuntu 22.04 with an ext4 filesystem. I'd like to automate daily backups of all Docker volumes instead of manually listing and copying them.
I've considered volume-backup images, Restic or Borg with the volumes mounted, and simply backing up my Compose files along with the data directories. Ideally, the process would run without stopping services, but I'm unsure whether that provides reliable backups—especially for databases. What backup strategy or tools work well for this setup, and when is it necessary to stop or pause containers?
5 Answers
Filesystem snapshots are a good way to get a consistent point-in-time copy while containers continue running. Btrfs or ZFS can create atomic snapshots, which can then be sent to another disk or server. Since the host uses ext4, you would need to migrate the data or use a storage layer that supports snapshots; a normal file copy on ext4 does not provide the same atomic guarantee.
You don’t necessarily need a Docker-specific backup utility. Docker volumes are directories on the host, so Restic, Borg, or another standard backup program can back them up. Just avoid treating the entire Docker storage directory as an easy restore target: restoring it may require stopping Docker and all containers first. Back up Compose files, secrets and configuration, application data, and database exports as separate, clearly documented parts.
The safest general-purpose approach is to briefly stop the containers, archive the named volumes, and start only the containers that were running before the backup. That gives you a predictable, consistent filesystem state. A scheduled script or systemd timer can automate it, and the resulting archives can then be copied to another machine or backup target. Keep your Compose files in version control separately.
Whether live backups are safe depends on the application. Copying ordinary static files while containers run is usually fine, but copying an active database’s files is not the same as making a database backup. Use a database dump, checkpoint, or application-specific export for services that store frequently changing data. Otherwise, the backup may contain an inconsistent or corrupted database.
The important part is testing the restore. Bring the backup up as a separate set of containers and verify that the applications and databases actually work, rather than assuming a successful archive means the backup is usable.
A practical setup is to use a scheduled job that creates database dumps, briefly stops only the services that need filesystem consistency, archives the relevant volumes, and then starts those services again. Store multiple generations off the host and periodically perform a full restore test. A backup that never gets restored is only a theory.
Stopping everything is simple, but you can reduce the outage by handling databases separately. Use each database’s native dump or backup command, then copy the mostly static application data while the other services remain online.