Moving in for real · The Home Server Book

This final chapter verifies the conditions for importing irreplaceable data.

The gate #

Do not move real data until every checklist item below is true.

If one of those is not true, that is your next task. The order of the chapters was chosen for this list.

Keep the original for a while

Do not delete your photographs from wherever they currently live because they uploaded successfully. Keep the old copy until the new one has been backed up, restored from, and used normally for a few weeks.

Keeping the old copy for another month is cheaper than discovering an incomplete backup after deletion.

Import a small difficult batch first #

A decade of photographs is not the same operation as a test upload.

Do a small batch first. A hundred photographs, including the awkward ones: a long video, a live photo, a HEIC from a phone, a scanned image with no metadata, something with a wrong date. Check they arrive intact and dated correctly. Fixing an import setting after thirty thousand files is much worse than after a hundred.

Import over the local network. A large remote import adds an unnecessary internet path and may be interrupted. At home, use the trusted local https://photos.example.com route from chapter 8.

Watch the disk while it runs. Thumbnails and transcodes are generated as it goes, and they are large. df -h /srv in another terminal, or the dashboard from chapter 14.

Track the processing queues. Face analysis, metadata extraction and video transcoding run after upload. A full first import may take days on a small machine. Use queue progress and resource metrics to distinguish work in progress from a stalled job.

Use Immich's supported CLI for an upload library. It requires Node.js 20 or newer. Create a temporary API key in the user's settings with only the upload permissions offered by your installed version, then avoid putting it in the command or shell history:

$ npm install --global @immich/cli
$ read -rsp 'Temporary Immich API key: ' IMMICH_API_KEY; printf '\n'
$ export IMMICH_API_KEY IMMICH_INSTANCE_URL=https://photos.example.com/api
$ immich server-info
$ immich upload --dry-run --recursive --album /path/to/small-test-batch
$ immich upload --recursive --album /path/to/small-test-batch

Check the asset count, dates, albums, videos and Live Photos in the web and mobile clients. Then repeat the dry run and upload for the full source. Do not use the CLI's --delete or --delete-duplicates options during migration. When the import is complete, revoke the temporary API key and run unset IMMICH_API_KEY IMMICH_INSTANCE_URL.

If the source directory must remain the authoritative filesystem, use Immich's documented external-library feature instead of uploading it. That is a different ownership model: mount it read-only, add it in Administration → External Libraries, and include both the original files and Immich's database metadata in restore tests.

Back up after the import, before you delete anything

The first post-import backup is unusually large and may expose storage, credential or transfer-time limits.

Run it deliberately, watch it finish, then restore a representative set. That successful check starts the observation period; it does not end it. Keep the source copy through several weeks of normal use and at least one further successful backup before deciding whether to remove it.

Quotas #

A full shared filesystem can stop every service, including its databases.

In Immich, open Administration → Users, edit each user and enter a finite storage quota in GiB. An empty value means unlimited, and external libraries do not count towards this quota. The filesystem alert from chapter 14 remains necessary underneath it.

Test the control before choosing final values: give a test user a quota only slightly above their current use, upload until Immich refuses the next asset, confirm existing photographs remain readable, then set the intended household quota. Leave capacity for the database, thumbnails, transcodes, backups in progress and system updates.

Leave headroom so databases retain space for writes, temporary files and maintenance.

Telling your family #

The technical work is done. The thing has users now.

Tell them what it is, in one sentence: photographs live at this address, use this login, it is our own machine. Show them once, on their own phone, and make sure the app is set to back up automatically, which is the whole point and the thing they will not do by themselves.

Be honest about the arrangement. It is a computer in the house, run by you, and when it breaks it stays broken until you fix it. People are fine with that if you say it once, and annoyed if they discover it during a holiday.

Two things to write down where they can find them: how to reach it, and who to tell when it does not work.

What to do when you are away #

Decide before you leave rather than from a hotel.

Administration is on the private network, so with a client on your laptop you can fix most things from anywhere. That is worth confirming before you travel, not during.

Have someone at home who can restart the machine safely. Show them how to press the power button briefly and wait for a graceful shutdown before pressing it again. Pulling the power risks filesystem and database corruption; reserve it for a completely unresponsive machine, wait before restoring power, and treat the next boot as a recovery event.

Consider silencing non-urgent alerts while away. An email about disk trends is not useful on a beach; a failed backup still is.

The handover document #

The genuinely useful thing to leave behind. One file, in the repository, that someone else could follow.

What it needs:

What runs, and where. The table from chapter 1, updated to what you actually installed.
Where the data lives. Which directories, which tier, what is excluded from backups.
Where the secrets are. Not the secrets: where. Which password manager, which drawer.
How to restore. The exact commands, tested. This is what the annex drill is for.
What to do when it will not boot. Console access, a live USB, whether the disks are encrypted, where any recovery key is kept, and how to read the files elsewhere. Confirm the actual state with lsblk -f; do not assume it from this book.
What you would do differently. The decisions you would revisit, so the next person does not have to rediscover them.

Side readingA restore drillRepeat the exact file and database recovery checks twice a year, without touching the live copy.

Write it for someone who knows Linux but not your machine. That someone might be a friend, a partner, or you in three years having forgotten all of this.

The maintenance that keeps it alive #

A home server does not need much, and the little it needs is not optional.

Weekly, informally: glance at the dashboard. Anything red, anything trending badly.

Monthly: check for pending reboots and take them. Read release notes for anything that had a security fix. Confirm backups are still succeeding, which the alert should already have told you.

Twice a year: the restore drill. Half an hour.

When you add something: decide public or private, put its data in the right tier, add it to backups, add it to the handover document. Four steps, every time, or the system degrades one application at a time.

Planning my import

Think through the order of operations for moving a large library in

Paste this into a new agent session. It carries everything the agent needs to know about where you are, and asks it to walk you through the problem rather than fix it for you.

I am about to import a large photo library onto my server for the first time. I want to think through the order: what to test first, what to watch while it runs, when to back up, and when it is safe to delete the originals.

Done #

You have a server that holds your family's data, that you understand, that is backed up and tested, that tells you when it breaks, and that someone else could take over.

The habits outlast the tools: decide who can reach a thing before you run it, know which of your data is irreplaceable, test the control rather than trusting it, and prefer the boring arrangement you can explain at 11pm. They apply to every machine you will run.

What you picked up

The gate is a list of things that must be true, not mostly true. Anything unticked is your next task.
Import a small awkward batch first. Import the bulk over the local network.
Back up after the import, verify restores, and retain the source through an observation period.
Quotas stop the most likely failure on a shared machine, which is accidental.
Tell your family what it is and who to tell when it breaks, once, plainly.
Write the handover document for someone who knows Linux but not your machine.
The habits transfer even when the tools do not.