Incremental Photo Backups: Why My Script Only Uploads What's New

I added a single photo to my library, reran my backup script, and watched the destination count tick up by exactly one. Here's what that small moment taught me about versioning, incremental sync, and why it's worth testing your own backup tooling before trusting it.

Where this picks up

By this point I've already got three scripts sitting in my working directory, built up over the course of earlier sessions working on this photo backup project. I'm not going to rebuild that context here — if you're just joining, the short version is that these scripts handle exporting, organizing, and syncing photos from a local library out to a remote destination. This particular session is shorter than most, because I only want to test one specific thing: what happens when I add a single new photo to the library and rerun the backup.

So the setup is simple. I go into the Photos app, pick a photo that isn't in the synced folder yet, and export it using Export, then JPEG, dropping it straight into the folder my scripts already watch. That's the entire "trigger" for this test — one new file sitting where the sync script expects to find a full library.

The reason I wanted to isolate this is that it's the kind of thing that's easy to assume works correctly and never actually verify. You write a backup script, you run it once, it works, and then you move on with your life trusting it forever. I wanted to actually watch what happens on a second run, with a library that's mostly unchanged.

Checking the count before I touch anything

Before running the script again, I check the current photo count at the destination. It's sitting at 25. That number matters because it's my simplest possible verification tool — I don't need to dig into logs or diff file lists to know whether something happened. If the script does its job correctly, I should see that number move by exactly one after I add exactly one photo. Anything else — it staying at 25, or jumping by more than one, or the whole library re-uploading — would tell me something is off.

This is also just a good habit in general when you're testing automation: pick a signal that's cheap to check and hard to misread. A count is about as unambiguous as it gets. I don't have to trust my own reading of a wall of terminal output; I just have to look at one number before and one number after.

Running the script and watching it work

I rerun the backup script — the one I've been calling "03 backup photos" throughout this project — the same way I'd run it on any normal day. Nothing special about the invocation. What's different is what it reports back this time. Instead of walking through the entire library and re-processing everything, it calls out a single file: 396.jpeg. That's the new photo I just exported, and it's the only one the script mentions as needing to be uploaded.

That's the whole payoff, honestly. The script doesn't say "uploading 26 photos" or churn through the full set — it identifies the one file that's new and handles just that one. I refresh the destination, and the count moves from 25 to 26. One new photo in, one new photo synced, nothing else touched.

The reason this works, as I understand it, comes down to a sync API call with versioning enabled. Versioning is what lets the sync process compare what's already at the destination against what's in the source folder and figure out the delta, rather than treating every run as a full re-upload. So rerunning the script isn't a full library push each time — it's closer to "check what's changed, send just that."

I want to be upfront that I'm describing the behavior I observed here more confidently than I'm describing the mechanism underneath it. I didn't walk through exactly which service or API is doing the version comparison in this segment, and I'd rather not gloss over that gap. If you're building something similar, don't take "it only uploads new files because versioning is on" as a guarantee that transfers to your own stack without checking. Different sync APIs and backends handle diffing differently — some hash file contents, some compare timestamps, some rely on explicit version markers you have to set up yourself. The count-based test I ran is good evidence that this setup, in this run, behaved incrementally. It's not a substitute for reading your own provider's docs on how it determines what's changed.

Why this small test matters more than it looks

It would've been easy to skip this check entirely. The script ran fine the first time I set it up, so why bother rerunning it against a near-identical library just to watch a counter? But this is exactly the kind of test that catches expensive mistakes before they happen. A backup script that silently re-uploads your entire library every single run isn't broken in an obvious way — it still backs everything up, technically. It's just slow, wasteful, and eventually going to hit rate limits, storage costs, or bandwidth caps you didn't plan for, especially as a library grows into the thousands of photos.

The incremental behavior I saw here is what makes a backup script something you can run on a schedule without thinking about it — daily, hourly, whatever cadence makes sense — instead of something you have to babysit because each run is expensive. Watching the count move from 25 to 26, instead of the script re-touching all 26 files, is the difference between a sync tool you trust in the background and one you're quietly afraid to automate.

I'll also say I was genuinely unsure about a couple of UI details while working through this — not everything about the export flow or the exact ordering of steps was crisp in my head in the moment. That's fine for a working test like this one, but it's worth you double-checking the specific menu paths and options in your own version of whatever photo app or backup tooling you're using, rather than assuming my exact clicks map one-to-one onto yours.

How to run this test yourself

If you've got any kind of backup or sync script in your own workflow — photos or otherwise — this is a cheap way to sanity-check it. Note the current count or file list at your destination. Add exactly one new file to the source. Rerun your script. Check whether the tool reports processing just that one file, and whether the destination count moves by exactly one.

If it does, you've got good evidence your versioning or diffing logic is working as intended. If it doesn't — if it reprocesses everything, or misses the new file, or the count doesn't match — that's worth catching now, on a small library, rather than discovering it later when a run takes twenty minutes instead of two seconds, or you get an unexpected bill from whatever storage or API service you're syncing to.

It's a small test, but it's the kind of small test that tells you whether you can stop thinking about your backup script at all — which, honestly, is the whole point of writing one in the first place.

Conclusion

If you've got a sync or backup script of your own sitting somewhere, don't just assume it's doing incremental updates — add one file, rerun it, and watch the count. It takes a couple of minutes and it's the cheapest confidence you'll ever buy in a piece of automation you're about to trust with your data.