My photos lived in five different places and none of them agreed with each other.
Some were on my MacBook. Some were on an old external drive that used to be plugged into a Windows PC.
A few hundred gigs were duplicated across both because at some point past-me panicked and just copied everything "to be safe."
I couldn't search any of it, I couldn't stream a video to my phone without emailing it to myself like it was 2009, and every time I wanted to find one specific photo I'd end up opening four different folders before giving up.
So I gave myself a week.
The goal: turn my old desktop PC into an actual Linux server, organize the chaos into something I could maintain without thinking about it, and get to a point where I could run Docker containers — specifically a photo app called Immich — so I'd finally have one place to see everything.
No more hunting.
Step one: the old PC becomes a server
The desktop had been sitting around doing nothing for over a year, which made it an easy choice.
I wiped it and put Ubuntu Server on it — no desktop environment, just a clean headless install I could SSH into from my MacBook.
Before touching a single file, I mapped out what I actually had to work with:
- The server's internal 1TB SSD
- A 2TB external SSD
- A 4TB external HDD
- A couple of smaller drives in the 128–250GB range sitting in a drawer
That mapping mattered more than I expected. It's the difference between guessing where things go and actually having a plan.
Building a filesystem I could maintain without overthinking it
The biggest realization of the week: my old "organization system" wasn't a system, it was just folders named new and newer and actually final. So before moving a single file, I set up three tiers on the server:
/data/
active/ # current projects, anything touched in the last 30 days
staging/ # things wrapping up, about to get archived
shared/ # accessible to other devices on the network
The rule is simple enough that I actually follow it: when something's done, it moves from active to staging.
When it's been sitting in staging for a couple weeks, it gets archived for real. No more "I'll organize this later" folders, because later never comes.
Attaching and encrypting the external drive
This is the part that ate most of my week, and also the part where I learned a very expensive lesson about typing commands too fast.
The 2TB drive I wanted to use as my main archive had been living on a Windows machine, so it was formatted NTFS.
Since it was going to stay permanently plugged into the Linux server and hold actual personal files, I wanted it both in a Linux-native format and encrypted — if anyone ever walked off with that drive, I didn't want my entire photo library walking off with them.
Here's the full process, if you're doing this yourself:
1. Find the drive
lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT
Double, triple check the size matches the drive you think it is. This step is not optional.
2. Wipe the existing partition table and create a new one
sudo wipefs -a /dev/sdX
sudo parted /dev/sdX --script mklabel gpt
sudo parted /dev/sdX --script mkpart primary 0% 100%
3. Encrypt the partition with LUKS
sudo cryptsetup luksFormat /dev/sdX1
sudo cryptsetup open /dev/sdX1 mydrive
4. Format the now-unlocked drive as ext4
sudo mkfs.ext4 /dev/mapper/mydrive
5. Mount it
sudo mkdir -p /mnt/mydrive
sudo mount /dev/mapper/mydrive /mnt/mydrive
6. Make it survive a reboot
This needs two files. First, /etc/crypttab, so the system knows to unlock it:
mydrive UUID=your-luks-uuid-here none luks
Then /etc/fstab, so it knows where to mount it once unlocked:
UUID=your-ext4-uuid-here /mnt/mydrive ext4 defaults,nofail 0 2
The nofail part matters — it means the server still boots fine even if the drive isn't plugged in that day.
Moving everything over with rsync
Once the drive was actually staying encrypted, it was time to move years of scattered files onto it. rsync became the tool I used for basically everything that week.
Dry run first, every single time, no exceptions:
rsync -avhP --delete -n /source/path/ /mnt/mydrive/destination/
Then for real:
rsync -avhP --delete /source/path/ /mnt/mydrive/destination/
For moving files off the old Windows-formatted external drive once it was readable on the server:
rsync -avhP /mnt/old-ntfs-drive/ /data/staging/
For syncing my MacBook's working folder up to the server over SSH:
rsync -avhP -e ssh ~/Documents/active/ user@serverip:/data/active/
And the nightly mirror that now runs on its own via cron, keeping a second copy of the archive on a separate drive in case the first one ever fails:
rsync -avhP --delete /mnt/mydrive/ /mnt/mirror-drive/
A couple of things I had to relearn the hard way: the trailing slash on the source path changes everything (with it, you copy the contents of the folder; without it, you copy the folder itself), and -a is the flag that preserves permissions and timestamps, which matters a lot once Docker containers start expecting files to be owned by specific users.
The dedup project nobody warns you about
Once everything was actually sitting in one place, I found out just how much of it was duplicates.
Hundreds of gigabytes worth.
Same vacation photos saved three different times because I'd exported them from my phone, then again from a backup app, then again "just in case."
I used a tool called czkawka, which does both exact duplicate matching and perceptual matching for photos that are visually identical but technically different files (different export, different compression, same image):
czkawka_cli image --directories /data/staging --file-to-save results.txt
I always saved to a results file first and actually read it before deleting anything — there's no undo button here. Once I trusted the results:
czkawka_cli image --directories /data/staging --delete-method AllExceptNewest
That one step alone freed up more space than either of the two smallest external drives I owned combined.
Genuinely embarrassing how much of my "storage problem" was just me, saving the same photo over and over without realizing it.
Teaching the files to name themselves
The last piece was fixing years of files named things like IMG_4821.jpg and video (3).mp4, which is useless when you're trying to find a specific memory six months later. I wrote a small Python script that reads the EXIF data off photos (and falls back to the file's modified date for things without EXIF) and renames everything to a consistent YYYY-MM-filename pattern:
from PIL import Image
from PIL.ExifTags import TAGS
from datetime import datetime
import os
def get_exif_date(filepath):
try:
img = Image.open(filepath)
exif = img._getexif()
if exif:
for tag, val in exif.items():
if TAGS.get(tag) == "DateTimeOriginal":
return datetime.strptime(val, "%Y:%m:%d %H:%M:%S")
except Exception:
pass
return None
def get_default_date(filepath):
return get_exif_date(filepath) or datetime.fromtimestamp(os.path.getmtime(filepath))
The script asks for confirmation before renaming anything and defaults to the EXIF date if it can find one, falling back to the file's modified date otherwise.
It's not fancy, but it turned a folder of meaningless filenames into something I can actually scan with my eyes and find what I'm looking for.
Why any of this mattered for Docker
All of this — the tiers, the encryption, the renamed files — was really just groundwork for the actual goal: running Immich in a Docker container so I could browse, search, and stream my own photo and video library like it was a real app instead of a graveyard of folders.
Immich needed a place to put its database (fast, so it stays on the internal SSD) and a place to read my existing media library from (the encrypted external drive, added as a read-only external library so it indexes my files without duplicating them).
None of that would have worked cleanly if the filesystem underneath it was still a mess. The server setup wasn't really about the server. It was about finally being able to open one app and just... see my own life, organized.
What I'd tell past me
Map your drives before you touch anything.
Dry run every rsync command. Know exactly which device you're pointing a command at before you hit enter, especially anything with wipefs or cryptsetup in it.
And budget actual time for deduplication — it's not a five minute afterthought, it's its own project.
Is anyone else sitting on a personal archive that's secretly 40% duplicates? Tell me I'm not the only one.