A Field Media Backup Is Not Finished Until Both Copies Verify

A card offload is complete only after the files exist on two independent destinations and both copies verify against the source. Until then, keep the camera card unchanged. A fast drag-and-drop to one portable drive creates convenience, not a defensible field backup.

The copy is not evidence until it verifies

A file can have the expected name and size yet still contain changed bytes. A cryptographic hash converts a file’s bytes into a fixed-length digest. NIST’s Secure Hash Standard specifies SHA-256, and Python exposes it through the standard hashlib module. When the source and a copy produce the same SHA-256 value, that is strong evidence their byte streams match.

The limit matters: a matching hash says nothing about a file that was never copied. Verification therefore needs two layers—an inventory check for completeness and hashes for integrity.

A minimum field offload sequence

1. Freeze the source. Lock the SD card when the card format supports it, or otherwise avoid deleting, renaming or editing files in place.
2. Create a job folder. Use a stable identifier such as date, project and card number. Keep the original camera folder structure inside it.
3. Copy to destination A. This may be the primary work SSD, but do not start editing inside the verified source folder.
4. Copy independently to destination B. Use a second physical device, not another partition or folder on destination A.
5. Compare inventory. Check file count, relative paths and total bytes for the card, A and B.
6. Verify hashes. Calculate SHA-256 for the source files and compare each manifest with A and B.
7. Record the result. Save the manifests and note operator, card ID, destinations and pass/fail status.

Two copies must not share one failure

Two folders on the same SSD can both disappear when the drive is lost, damaged or reformatted. Two devices connected through the same unstable hub can also fail during one event. In the field, put A and B on separate physical media and, when practical, separate them between people or cases after verification. This is an offload-stage control, not a substitute for a later versioned and off-site backup.

CISA’s broader backup guidance calls for offline, encrypted backups and regular tests of availability and integrity. A field team may not reach that full design before leaving a location, but it can avoid the most immediate single-device failure.

Use hashes without turning the offload into a coding project

Many media-management applications can make verified copies. If the chosen tool exposes the algorithm and writes a report, use it. A simple command-line workflow is also possible. Python 3.11 and later provides hashlib.file_digest() for files opened in binary mode:

from pathlib import Path
import hashlib

for path in sorted(Path("CARD01").rglob("*")):
    if path.is_file():
        with path.open("rb") as f:
            digest = hashlib.file_digest(f, "sha256").hexdigest()
        print(digest, path.relative_to("CARD01"))

Run the same manifest process on the source, A and B, then compare paths and hashes. Do not copy and hash the same destination twice while assuming the second run validates separate storage.

The card is the last fallback

Keep the card until both copies pass and the destination devices are safely ejected. For irreplaceable material, retain it longer—ideally until one copy reaches a separate location and a sample file opens from each destination. If verification fails, stop and recopy from the unchanged card; do not erase the only known source to free capacity.

For hardware selection around this workflow, TVG Report’s field offload planning guide separates reader speed from storage and verification needs.

Sources

• NIST FIPS 180-4: Secure Hash Standard
• Python documentation: hashlib
• CISA StopRansomware Guide