A. Minkevich
Auf Deutsch
← Back to AI-Labs

Own the Originals: How I Collect, Organize and Back Up My Media

Most of us produce media with the phone in our pocket. In my case it is a phone plus an action camera. Google Photos makes all of it comfortable: search, faces, maps, “this day three years ago”. I use it and I like it. But the originals live on somebody else’s disk, behind somebody else’s account system. Companies retire products, accounts get locked by mistake, and support for a consumer service is a web form. The photos of your kids should not depend on any of that.

So I follow the rule: the cloud is a viewing copy; the archive is mine. Google Photos keeps compressed versions for convenient access anywhere. The full-quality originals go through a pipeline of three stages: collect automatically, organize deliberately, back up automatically. One evening to set up, minutes per month to run.

 phone camera ──┐ (auto-sync)
 messengers ────┤             ┌─────────────┐      ┌──────────────┐
                ├──▶ inbox ──▶│   archive   │──▶───│ Kopia backup │
 action cam ────┤ (Syncthing) │  (digiKam,  │      │ 2nd drive +  │
 old folders ───┘ (manual)    │ encr. disk) │      │    cloud     │
                              └─────────────┘      └──────────────┘

Stage 1: collect — automatic

Everything new lands in an inbox folder on the PC without me touching a cable. Syncthing does the work (Syncthing-Fork on Android, SyncTrayzor on Windows), syncing one way, phone to PC, so nothing on the PC side can ever corrupt the phone’s originals. Two folders travel this way:

  • The camera media — photos and videos straight from the phone.
  • Selected messenger media. Family photos arrive through WhatsApp, Telegram and other messengers. The habit that makes this manageable: turn off automatic save-to-gallery in every messenger, and manually save only what is worth keeping. The gallery then contains selected media, you decide for and free of noise. Each messenger hides this setting differently — if you want the exact setup I use, ask me via the contact page.

The action camera is the manual exception. Its footage is mostly intermediate material for editing, so I copy it by hand into a backlog folder, together with years of old pre-pipeline media that I gradually process into the archive.

One bonus folder, I additionally use to this setup, syncs in both directions and works as a fast exchange lane between PC and phone: drop a file on either side, delete it on either side when done.

The inbox is, of course, not the archive. Once media is imported (stage 2 is done, see next), whatever the phone does afterwards — deleting to free space, a lost device — cannot touch the archive. I clean my phone without thinking about it.

Stage 2: organize — deliberate

New media moves from the inbox and backlog into the working archive: an encrypted external volume with a plain year/month folder tree. digiKam then does what Google Photos does, but on my disk: indexing, face recognition, tags, search.

Two decisions matter more than the tool choice:

  • Import with a script, not a GUI. digiKam can import and lay out media itself, but I caught it silently skipping files — no error, just missing photos. For an archive there is no worse failure mode, so I wrote Ingest-Media, an open-source PowerShell script that does the intake transparently. It resolves each file’s capture date from EXIF, the file name or the filesystem — and refuses to invent one when all three fail — deduplicates by hash so re-runs and second devices cost nothing, verifies every copy against its source, and never touches the source folder. Every file is copied, skipped with a stated reason, or logged as an error. No silent tools in the intake path.
  • Write metadata into the files. digiKam keeps its knowledge in a database (put it on an internal SSD; it makes a visible difference), but I configure it to also write tags and faces into the media files as XMP. The archive then does not depend on any single application — if I move to something else someday, the metadata travels with the files.

One layout detail worth adopting: camera media and messenger media live in separate branches of the archive, because the date means different things there. In the camera branch it is when the photo was taken; in the received branch, only when it arrived. Mixing the two pollutes good data with approximations.

digiKam’s honest limitation: it is a desktop application, so there is no easy mobile access — which is exactly the role Google Photos still plays for me. Anyone who wants to drop Google entirely can host Immich instead, a client-server gallery that would slot into my VPS stack naturally. A likely future chapter of this setup.

Stage 3: back up — automatic again

Kopia takes encrypted snapshots of the archive and sends them to two places: a second external drive and a cloud. Kopia speaks to Backblaze B2 and similar storage natively; for Google Drive or OneDrive it needs rclone as a bridge — that is how I use my paid Google Drive space. Together with the working copy this gives the classic 3-2-1: three copies, two kinds of media, one off-site.

Note what is not on the list: Google Photos. Compressed copies on a third-party service are a convenience, not a backup. They never count.

Hard-won hints

  • Verify imports — and re-verify the archive. Count and hash at intake; the one tool that fails silently will eventually hold your only copy of something. Disks quietly begin to corrupt data over time too, so the ingest script stores a hash manifest and can re-check the whole archive against it, catching bit rot while the backups can still allow for the recovery of the damaged data.
  • Back up the keys, not only the data. The archive volume is encrypted and so are Kopia’s snapshots. If those passwords exist only on the same PC, the backup system simultaneously serves as a self-destruct mechanism, which you cannot rely on. Password manager plus one offline copy.
  • Restore something occasionally. A backup that has never been restored is a hope. Pulling one random album out of Kopia twice a year is enough to turn it into a fact.
  • Compression is fine — in the right place. The right place is the viewing copy: I upload to Google Photos in reduced quality, which saves cloud space and loads fast on a weak connection, and for everyday media the quality loss is invisible. The backups are different: Kopia stores bit-exact copies of the originals — its compression is lossless, like a zip archive. Lossy compression belongs in the convenience layer, never in the archive or its backups.

That is the whole system. The phone stays empty, the archive stays searchable, and no company’s product decisions stand between my family and its photos.