Docker volume restore after live backup: how to detect silent data inconsistency

Docker has no native volume snapshot command, so my backup workflow is the common workaround: run a helper container that tars the volume contents, then restore later by extracting the archive into a freshly created volume. This works for stopped containers, but I need to back up volumes while the owning container is still running.

The concern is consistency. If the application has open files or writes during the tar run, the archive may capture partially written data, and the restore appears to succeed while silently producing corrupt or stale files. Application-level flush or driver-specific snapshot options (where the volume driver supports them) are possible mitigations, but they are not universal across platforms.

Assume a recent Docker Engine release with the default local volume driver on Linux.

1. After restoring a volume that was backed up while the container was active, what is a reliable way to verify data integrity beyond comparing file hashes, which only catches some corruption modes?

2. Is there any documented Docker behavior or driver option that gives atomicity guarantees for this tar-based approach, or is stopping the container the only safe option?

3. For databases or write-heavy apps, should consistency be delegated entirely to application-level dump tools instead of volume-level backup?