Copying a Docker Volume folder while the database is writing may create archives that appear complete but cannot be restored. The correct method depends on the data type: the upload file, database, queue and config do not have the same consistency points. The backup is valuable when kept independent, warns of errors, and has been attempted to recover.
Quick answer:Inventory volumes and their owners, set RPO/RTO, and use a dump or native compatible method for the database. For files, pause/freeze or snapshot synchronize. Keep the output with copy metadata, checksum, and encryption outside the host, then check the program's integrity in the separate Restore environment.
First, figure out what you're getting.
The name volume alone does not tell the meaning of the data. Record the mount path within the container, the author service, the program version, the associated dependencies, and the change rate. The recoverable cache may not be a backup, but user uploads and keys are essential for decryption.The Docker Volume Guide is published byThe difference explains volume, bind mount and tmpfs.
RPO and RTO determine the method
If a maximum of one hour of data is lost, a daily backup is not enough. If recovery is to be done in thirty minutes, a few hundred gigabytes of storage is not appropriate. RPO is the acceptable distance from the last data and RTO is the time of recovery.
A file-level backup or an application-aware backup?
For immutable files or uploads that do not change during backup, a file-level archive is suitable. For PostgreSQL, MySQL, and other databases, native tools or snapshots are required to synchronize with the database. Live data directory files without a formal protocol may take pages and logs at different times.
Three patterns of consistency
- Stop controlled:Stop the writer gracefully, grab the files and upgrade the service; simple but with downtime.
- A logical dump:The database provides a consistent output; restore and measure its time/volume.
- Synchronized snapshot:With storage tools and quiesce database; faster, but more complex and platform-dependent.
For sensitive transactions, in addition to periodic backup, an archive log or replication may be required. Replica is not an independent backup; erroneous deletion or corrupted data can be replicated.
Archive template for file volume
Docker Volume can be mounted to a read-only tool container and written to an archive output in another destination. The exact command must have the name of the volume and destination path specified. Before running, stop the author or ensure consistency with the program method. Do not copy from the Internet examples with a variable, wildcard, or vague path on the production; first confirm the target with a reading inspect.
docker run --rm --mount source=app_uploads,target=/source,readonly --mount type=bind,source=/srv/backups/app,target=/backup alpine:3.20 tar -C /source -czf /backup/uploads.tar.gz .This is the sample for the file volume with the exact name.app_uploadsIt's not a live database. The destination must already exist, have enough space and proper permissions. Tag the image tool in the runbook pin and update. The compact archive is not encrypted and should be protected at a later stage.
Dump the database inside the container.
Use both the client tool and the recommended database method. Do not reveal credentials in the command line or log; a secret file or pipeline security tool is better. Keep the dump output outside the same database volume. Zero output line alone is not enough: check the unusual size, error log, checksum, and real Restore.
Backup of several related volumes
The store may have a database, upload, and object storage. Taking each at different times can make the file and record reference incompatible. Design a maintenance window, snapshot group, or appropriate scan marker. Also save the config and image digest release alongside the backup to see which version the data was executed with. Keep the secret necessary to decrypt the data separate and secure; otherwise Restore is useless.
Independent destination and multi-copy rule.
Backup on the same host or volume is not independent of disk failure and error deletion. Keep at least one copy outside the default domain and separate with the credential. An immutable or object lock version can help with deletion and ransomware, but it has retention and costs.The server backup manual.Examines the maintenance and restore layers more fully.
Encryption and recovery key
Backup data is usually more complete than production. Access control and audit are required in the transmission and at the encryption destination. Do not store the encryption key only within the same backup and log recovery to authorized people.
Retention and deletion controlled
Keeping all versions is not permanent. Set a daily/weekly/monthly policy based on RPO, law and fee. Deletion should only target validated and expired backups; scripts with globes or blank variables are dangerous. Have a dry-run, destination allowlist, and list report removed. Long-term retention of personal data also creates a privacy obligation.
What does Checksum prove?
Checksum shows that the file is unchanged or corrupted after production; it does not prove that the backup was compatible from the beginning. Keep the checksum and metadata with the archive and re-scale at the destination. For multifile sets, an accurate manifest is useful with the size, time, and version of the tool.
Also record the version of the dump and restore tools. Check the compatibility of the versions according to the same database documentation; a random installation of the latest version can delay recovery during a crisis.
Restore Test step by step
- Set up a separate, unconnected environment for production.
- Recover the saved version of the tool, image and configuration.
- Check the checksum and the archive re-opening capabilities.
- Restore the database and files in documented order.
- Control the unwanted migration before you clone.
- Test the data number/sample, login and critical flow.
- Record the real-time Restore and manual steps.
Restore environment should not send actual email, payment, or webhook. Disable external credentials or replace them with sandboxes.
Recovery on the new volume
To reduce risk, you often create a new volume, restore the data, and attach a test stack to it. After the correction, a controlled cutover is performed. Direct overwriting of the original volume reduces the return path. If you have to replace it, take a fresh backup and snapshot before the operation and specify the freeze time of writing.
Job monitoring is backing up.
Track the last successful run, time, volume, checksum, destination upload, and age of the last Restore Test. job run is different from recoverable file. Very small or fast backups can be marked as empty volume/name error. The alert must have owner and runbook and activated before passing RPO.
Common Mistakes
- Tar retrieving from the directory of data a live database without a consistent method
- Keep only copies on the same server.
- Backup of the wrong volume due to the project prefix Compose
- Enter a password in the command or log CI
- There was no Restore test and no real-time recovery.
- Encryption without key management
- Deleting the backup with the wildcard is uncontrolled.
When is special intervention needed?
If a processing service has a few related volumes or very limited downtime, a simple archive is not enough.DevOps clock supportIt can design and run inventory, consistency, out-of-host backup and Restore Test for the same stack.
Common Questions
Is the snapshot Volume a backup?
It can be part of the solution, but program consistency, domain failure independence, retention and Restore Testing are still necessary.
Should we turn off the container for backup?
For changing files, controlled pause is the simplest consistency; the database can have a native tool or a synchronized snapshot.
How many times do we test Restore?
Based on sensitivity and changes, the storage or backup process will be repeated after a major change in schema.
Is there a copy of the folder?/var/lib/docker/volumesIs that enough?
Not as a general method; it depends on the implementation of the host and may be incompatible with the live database.