Back Up the Container or Its Files? Decide by Restore Shape

You can back up an encrypted container as one object, or mount it and back up the files inside. Both cross the VPN happily, and that is where the similarity ends. They restore different things, they depend on different keys, they cost different amounts of storage, and they fail in different ways when someone needs the data back. Choose the recovery object first, then the transport, then the encryption of the stored copy. The checklist below runs in that order, because almost every backup dispute is really a disagreement about which of those three was decided first.

Two objects, two recovery shapes

An image backup restores a container: you get the encrypted volume back, and you still need its recovery material to open it. A file-level backup restores files and directory trees, and whatever encryption protects them is a property of the backup repository rather than of the original container. A plain copy into a remote folder is a third case, and it inherits whatever protection that folder happens to have.

The middle row is the one people misread. It can be a perfectly good design: the backup program reads plaintext locally and writes an encrypted, authenticated repository. Its security then rests on that program and its credentials, not on the original container password, and the two should not be described as if they were the same control.

Check 1: what must the restore reconstruct?

Ask the question in the form of a recovery, not a backup. If the requirement is "bring this service back on another host", an image plus its recovery material is a coherent answer. If the requirement is "get the finance spreadsheet back from March", restoring a multi-gigabyte image to extract one file is an expensive way to answer it. Both are legitimate recoveries, and they are not interchangeable budgets. A plan that names only one of them will eventually be tested by the other.

Write the restore target into the plan: whole volume, a directory tree, or individual files. Then note what metadata has to travel with them, because ownership, permissions, extended attributes and timestamps are part of a file-level restore and are frequently dropped by copy-based workflows that looked adequate during testing.

Also decide who performs the restore. A file-level repository that any operator can mount is a different access model from an image that requires the key holder to be present, and neither is automatically better. What matters is that the choice is deliberate and written down.

Check 2: what protects the stored copy?

The VPN protects a transport segment. It says nothing about the stored copy once the transfer finishes, and "it went over the tunnel" is not a statement about the backup operator's ability to read your data. If the remote side is operated by someone else, the question is what they can read, not whether the link was encrypted.

For an image, that means protecting the container's key material separately from the image itself. Losing the header loses the volume, so back the header up somewhere the image is not:

cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20

For a file-level repository, verify that the tool encrypts and authenticates content and metadata before it leaves the host, and find out who holds the keys. Restic's design documentation is explicit that it assumes a trusted source host and that encryption does not prevent someone with storage access from deleting backups. Both caveats matter: a repository can be confidential and still be destroyed.

Check 3: is the copy consistent?

A backup that captures a mutating filesystem is a copy, not a recovery point. For an image, use the volume tool's supported method for a stable snapshot, which usually means a snapshot operation or a dismount rather than reading a large file while it changes:

lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonly

For mounted files, use the application's supported consistency procedure for live databases and other coordinated data. A filesystem-level copy and an application-consistent recovery point are different descriptions, and the difference only becomes visible when you try to start the application from the restored copy.

Keep the recovery material on an independent protected route. Losing the original machine should never also lose the only credential that opens its backup, which is exactly what happens when the key file lives on the volume being backed up. Test that separation deliberately: restore on a host that has never seen the original, using only what the plan says is available.

Check 4: does change detection hold for this object?

An encrypted container looks like one large opaque file to most transfer tools, so a small plaintext edit can result in a large reread or a full re-upload depending on the tool and the format. Variable-size chunking and deduplication, as restic documents, can reduce that, but it is a property of that tool rather than of encrypted containers in general.

Measure instead of assuming. Compare a first run with a second run after a small, harmless change, and record bytes transferred as well as elapsed time. Preserve a known-good backup while you experiment, so a test cannot consume your only restore point.

Then finish the checklist with the only test that counts: restore without the original machine. Open a recovered container, or restore selected files with their metadata, and confirm the application or the user can use the result. A fast, well-encrypted transfer that cannot answer that test is a copy of your data, not a backup of it.