For the first few years I shot seriously, my archive was a disaster. Every card dump landed in a folder called "Photos," and every second edit spawned "Photos (2)." I once had three copies of the same wedding spread across two drives and a desktop folder, named differently, and I could not tell which one held the final selects. The morning I needed a client's portrait for a print and spent ninety minutes hunting for it, I finally stopped treating file management as an afterthought. A photo library is not a pile of files. It is an asset, and assets need a system.
One naming convention, no exceptions
Everything I keep now follows a single rule: YYYY-MM-DD_Project_City. A fall street session becomes 2025-11-15_Fall_Street_Shanghai. Putting the date first means every folder sorts itself chronologically forever, with no clever sorting tricks on my part. The project name means I never have to open a folder to find out what it holds. The city matters more than I expected — a year later I remember the place long before I remember the subject.
Paid work gets one small modification: the client name goes in front of the date, so a wedding shoot might read ChenWedding_2025-10-04_Suzhou. For a client job, the client, not the calendar, is how I actually search. The rule only works if I never allow an exception. The second I permit a folder called "misc" or "final-final," the whole system is dead. Every rule bends once, then it snaps.
The folder skeleton
Under each project name I keep the same four subfolders: RAW, Selects, Edits, and Deliverables. RAW holds the untouched cards, dumped straight from a card reader and never formatted until the originals are verified somewhere else. Selects is where I cull, and I delete ruthlessly on the first pass — anything soft, blinked, or duplicated goes without sentiment. Edits holds the working files and their sidecar metadata. Deliverables is the only folder a client, an editor, or my past self is ever pointed at.
Above the project folders sit plain year buckets: /Photography/2025/, /Photography/2024/, and so on. That single layer keeps the top of the tree short enough that I can still find things by eye when the catalog is closed. Client work lives in a parallel tree: /Clients/ followed by the client, then the dated project. Splitting personal and paid work this way means I never have to think about where a file belongs, which is the whole reason a system exists.
Catalogs are not backups
The catalog is my map, not my territory. I run Lightroom Classic, and the catalog database is genuinely the most fragile thing in my entire setup — it is one file that grows every day and can corrupt if it is open when a drive disappears. So I treat it accordingly. The catalog backs up automatically on close, every single time, and I copy that backup to two separate drives once a week. Every raw file also gets XMP sidecar metadata written alongside it, so my star ratings, keywords, and edits survive even if the catalog is lost for good.
I learned this the hard way after a corrupt catalog cost me a full weekend of re-keywording. The rule now is absolute: no image ever exists only inside the catalog. If deleting one file would erase a shoot, that shoot is not backed up correctly.
The 3-2-1 rule, in practice
The backup rule everyone quotes is 3-2-1: three copies, on two different kinds of storage media, with one of them off-site. In my studio it looks like this. The shoot I am editing right now lives on a fast NVMe SSD, because speed matters while I work. The full archive sits on a Synology NAS running two mirrored drives. And the work that would hurt to lose goes to a cloud backup for the disaster case. Three copies, spinning disk plus solid-state media, and one of those copies physically off my desk.
It sounds expensive until the first drive fails, and it is not a matter of if. I have had a bus-powered portable drive die in the middle of a shoot and a NAS disk start throwing errors within the same week. Neither time did I lose a photograph, because the copies already existed before I needed them. Redundancy is not paranoia. It is the ordinary price of calling yourself a professional.
Verify with checksums, not hope
A copy is not a backup until you have verified it. I have watched a transfer look perfectly fine in the file browser while silently dropping a folder, and I have seen files arrive at the correct size but the wrong bytes. So now every archive move runs through rsync with checksum verification, and for the genuinely important folders I compare checksums by hand. A cloud service covers the off-site leg and quietly re-verifies stored data in the background, which is more reassurance than any single drive can offer.
The standard I hold myself to is deliberately boring: after a shoot, the original card is not formatted until the images exist in at least two verified locations, and I have opened a sample file from each location to confirm it is a real image and not an empty stub. That one minute of checking has saved me from a silent failure more than once.
Biannual deduplication
Even with a good system, duplicates creep in — exports that became imports, a lens test I shot twice, the same sky saved for a composite. Twice a year, in January and July, I run dupeGuru across the archive and let it hunt by content rather than filename, because my worst duplicates are the ones I renamed by hand. A normal pass reclaims somewhere between 20 and 50 GB, occasionally more after a heavy travel year.
The freed space is nice, but the real prize is a smaller, cleaner catalog that searches faster and is less likely to lie to me. I schedule it on a quiet weekend, review the suggested matches by eye before deleting anything, and then move on. A half-day, twice a year, is a tiny tax for a library that stays honest.
None of this is glamorous, and that is precisely the point. The camera gets the credit, but the system is what lets me pull a frame from 2019 in thirty seconds, hand a client the right folder without hesitation, and sleep through a drive failure. Build the habit early, before the wasteland grows around you.