Your Backup Finished — But Is the File Actually Good? Corruption During Cloud Sync Abroad

Why a Dropped Connection Produces a Corrupted File Instead of a Clean Failure

Most people assume an interrupted upload behaves like a interrupted download — it stops, you get an error, and you retry. That's true for a lot of consumer sync tools, but not all of them, and the failure mode that actually causes damage is quieter than that. Some sync clients write directly to a temporary or partial object on the cloud side and only rename or finalize it once the transfer completes; if the connection drops at exactly the wrong moment — after the finalize signal is sent but before the last bytes are confirmed, or during a retry that silently succeeds on a corrupted chunk — the client's local log shows the file as synced when the object sitting in Backblaze B2, IDrive, or Dropbox is actually incomplete or internally inconsistent. This isn't a bug specific to one vendor; it's a structural risk in any sync architecture that separates "transfer finished" from "transfer verified," and travel wifi with its captive portals and mid-session drops creates far more opportunities for that gap to matter than a stable office connection ever does.

The practical result is that you can look at your backup software's dashboard, see a green checkmark next to a file, and still have a broken copy sitting in the cloud. This matters most on travel because the entire reason people run cloud backup abroad is to safely delete originals off a laptop or card to free up space for the next leg of a trip — which means the moment you trust that green checkmark and hit delete on the source, a silently corrupted backup becomes an unrecoverable loss. Sync tools rarely re-verify a file's integrity after the fact unless you explicitly ask them to, because doing so for every file on every sync would be slow and expensive at scale, so the responsibility for catching this shifts to you.

Why Backblaze, IDrive, and Dropbox Can Report Success on a File That Isn't Actually Good

Backblaze's consumer backup client and B2 both use checksums internally (typically SHA1) to validate a chunk on upload, which sounds like it should catch this — and for most transfers it does. But the check happens per-chunk during a healthy connection; if the connection drops mid-chunk and the client's retry logic re-sends what it believes is the same data but the local file itself was already partially read or the source file changed on disk (common with video files still being written by transcoding software, or files on an external drive that briefly disconnected), the checksum can pass against a chunk that doesn't represent the file you think it does. IDrive's desktop client behaves similarly — checksum validation is real but it's validating that the bytes it received match the bytes it sent, not that the bytes it sent were a complete and correct representation of the source file at the moment the sync started.

Dropbox's file sync (particularly for very large files, which get block-level synced) has documented cases of files showing as "up to date" in the client while the actual cloud copy lags or differs, usually resolving itself on the next sync cycle — but if you've already deleted the local original by the time that discrepancy would have resolved, there's nothing left to reconcile against. None of this means these tools are unreliable for normal use; it means they're built around continuous, self-healing sync assumptions that don't fully hold on a connection that only shows up for twenty stable minutes at a time between hotel wifi drops, which is the exact environment a lot of traveling photographers and videographers are working in.

Why RAW and Video Files Show Corruption Differently Than a Photo or Document

A corrupted Word document or JPEG usually fails loudly — it won't open, or it opens with an obvious visual glitch across the whole image. Video and RAW files corrupt more quietly because of how their containers are structured. Most MOV and MP4 files store their index — the "moov" atom that tells a player where each frame lives inside the file — either at the very start or, more commonly on files still being finalized, at the very end. If a transfer truncates before that index is fully written or fully transferred, you can end up with a file that's the right size, opens in some players, and appears to play for a few seconds before freezing, glitching into green or gray blocks, or crashing the app entirely — because the player can read raw frame data but can't find or trust the index telling it how frames are ordered and where they end. Camera RAW formats (CR3, ARW, NEF and similar) have their own internal structure with metadata and image data blocks, and a truncated file frequently opens fine as a thumbnail (since thumbnails are often a small embedded JPEG stored early in the file) while the full-resolution RAW data itself is unreadable — which is exactly the trap: the thumbnail looking fine gives false confidence.

This is also why corruption from a bad sync often isn't discovered until much later, sometimes weeks after the trip, when you finally go to edit the footage and the export fails partway through or a specific clip won't load — by which point the local original is long gone and there's no clean way to tell whether the corruption happened during recording, during transfer, or during cloud storage. The only way to close that gap is to check integrity at the time of transfer, not after the fact when the only copy left is the one you're trying to verify.

How to Verify a File Is Actually Intact Before You Trust It — Checksum Tools That Work

A checksum (commonly SHA-256 or MD5) is a short fingerprint calculated from a file's exact contents; if two copies of a file produce the same checksum, they are byte-for-byte identical, and if they don't, something changed or was lost in transfer. On a Mac or Linux machine, the built-in shasum -a 256 filename command generates one instantly with no extra software; on Windows, certutil -hashfile filename SHA256 does the same from Command Prompt. The workflow is simple: generate a checksum for the file on your local drive before uploading, then after the cloud sync reports complete, download that same file back down (or use the service's built-in verification if it exposes one) and generate a checksum on the downloaded copy — if they match, the backup is genuinely intact, not just reported as complete.

For anyone syncing large batches rather than single files, rclone (already useful for resumable transfers) has a built-in rclone check command that compares checksums between a local folder and its cloud destination and lists exactly which files differ or failed, which is far faster than manually verifying file by file. Backblaze B2's web interface and API also expose the SHA1 it stored for each uploaded file, so a quick script comparing that against a locally generated SHA1 catches the same problem without needing to re-download anything, saving bandwidth that matters on slow travel connections. Whichever method you use, the principle is the same: a backup isn't verified because the software's progress bar hit 100%, it's verified because a checksum on both ends actually matches.

A Safe Backup Workflow for Travel: Verify-Before-Delete, Redundant Copies, Staged Uploads

The single highest-impact habit is verify-before-delete: never clear space on a camera card, SSD, or laptop drive by deleting the only copy of a file until you've confirmed — via checksum, not just a green checkmark — that a second copy exists and is intact. In practice this means carrying a portable SSD or a second card as a true local redundant copy that travels separately from your primary drive, so that even if a cloud sync is mid-verification or a connection is too unstable to trust yet, you're never down to a single copy of anything while traveling. This is a stricter standard than the general 3-2-1 backup approach covered in our pre-travel backup guide — that guide is about having three copies across two media types before you leave; this is specifically about confirming the cloud copy you're relying on mid-trip is actually good, not just present.

Staged uploads help more than most people expect: instead of dumping an entire day's or entire trip's footage into one long overnight sync (which, if interrupted, leaves you uncertain which specific files among hundreds are affected), upload in smaller labeled batches — by day, by card, or by project folder — and verify each batch's checksums before starting the next. This turns one large uncertain sync into several small, confirmable ones, and if a batch does fail or corrupt, you know exactly which files to re-check rather than re-verifying an entire trip's worth of footage. It's worth noting this is a different problem from an upload simply stalling or timing out mid-transfer, which is a visible failure covered in our large file upload timeout guide — that's about a transfer you can see is stuck; this is about a transfer that looks finished but isn't, which is the more dangerous version because nothing on screen tells you to worry.

When to Get a Second Set of Eyes on a Backup Setup Before You Trust It

If you're not sure whether your current sync setup (Backblaze, IDrive, Dropbox, or something else) is configured to actually verify what it uploads, or you've already found a corrupted file and need to know whether anything is salvageable, that's worth getting checked properly rather than guessing. We can audit your current backup workflow, set up real checksum verification so you know a file is good before you ever delete an original, and build a staged upload routine suited to how unreliable your specific travel connection actually is.