What You Build Now to Protect What Matters Later

There are some parts of a homelab that are enjoyable because they let you do something new. A new service appears. A DNS name starts resolving. A dashboard begins to feel useful. A site goes live. A photo library opens in a browser and stops being an idea.

Backups are not like that.

Backups belong to a different category of work. They are for a day you hope never comes. They exist for failure, not for novelty. You build them because eventually something important will break, or disappear, or become unavailable at exactly the wrong moment. The strange thing about backup work is that when it is done well, it often feels unrewarding. Nothing seems different. The service still works. The site still loads. The photos are still there. The point is not that anything changes today. The point is that something might still be there tomorrow.

That is what made backups feel like the right next step.

The obvious place to start was Immich.

That was partly because it was the newest meaningful service, but mostly because it was the first one where the data felt personal in a different way. Photos are not like configs. They are not like a container image that can be pulled again, or a dashboard that can be rebuilt in an afternoon. They carry memories with them. They become harder to shrug off. Losing a service is annoying. Losing photos feels different.

So I built a backup VM.

I kept it simple. One VM on anvil, enough storage to hold local copies of the things that matter, and a structure that was easy to understand. That mattered to me. I wanted the backup system to be boring in the best possible way. Not clever. Not elegant for its own sake. Just clear. A place for local copies, database dumps, configuration files, and logs. Something I could come back to months later and still understand without needing to reconstruct my own thinking.

The first version of the Immich backup was straightforward. Pull the data across. Dump the database. Copy the key configuration files. Keep the logs. Make it repeatable.

That sounds simple, and in one sense it was. But even there, small details mattered. Database dumps should be done properly, not just assumed from volume copies. SSH trust needed to be in place so the backup could happen without interactive prompts. DNS had to resolve the right names. The script had to be explicit enough that future me would know exactly what it was doing. Even the choice to use the DNS name instead of the raw IP in the script mattered a little. It made the process feel less like a command and more like a relationship between systems that already knew each other.

Then came the offsite layer.

A local backup is useful. It is fast to restore from, easy to inspect, and better than pretending snapshots are enough. But it is still local. If the wrong host dies, or the wrong storage disappears, or the wrong failure takes out more than one layer at once, local can stop being enough very quickly. So I added Backblaze B2 and restic.

That was the point where the backup system began to feel real.

Restic appealed to me for the same reason a lot of the better homelab tools appeal to me: it does something serious without trying to be dramatic about it. It encrypts. It deduplicates. It keeps snapshots. It works well with B2. It feels like the kind of software that assumes its job is to be dependable rather than impressive.

That is exactly what I wanted.

Once the repository was initialized and the first real backup had gone up, the shape of the system changed in my head. Before that, I had a backup plan. After that, I had an actual offsite copy. Those are not the same thing.

The first backup took a while, as first backups usually do. That was expected. The second run was the satisfying one. No huge upload. No surprise growth. Just a new snapshot and zero bytes added because nothing had changed. That was one of the most reassuring moments in the whole process. It meant the deduplication was working, the data path made sense, and the cost curve was likely to be reasonable. It turned the backup from an expensive-sounding idea into something calm and believable.

Then came the part I think matters most: testing restore.

Not a full disaster recovery drill. Not yet. That would have been more performance than proof. What I wanted was something smaller and more honest. Can I see the snapshots? Can I inspect what is in them? Can I restore the configuration files? Can I restore the database dumps? Can I prove to myself that this is not just data disappearing into a cloud bucket under the comforting name of safety?

The answer, thankfully, was yes.

That felt important.

A lot of backup systems are trusted too early. The job runs. The logs look fine. A bucket fills up. Everyone moves on. But the first real trust comes when something comes back. A restored config file says more than a successful upload ever can. It proves not just that the backup exists, but that the path back still exists too.

I do not think the backup system is finished. I do not think backup systems ever really are. There will still be questions about what to exclude, what is redundant, what generated data is worth keeping, and how much history is enough. There will be more services to protect. There will probably be cleaner ways to do parts of it later. But it has crossed the line from “something I should really set up” to “something that exists and works.”

That matters.

Backups are one of those things that can feel boring right up until the moment they become one of the most important things you have built. They do not add a new visible capability. They do not make the lab more exciting. They make it more survivable. And at some point, if a homelab is going to hold anything real, survivability becomes part of the work.

That is where I think this lab is now.

Still growing. Still uneven in places. Still becoming. But a little more willing to trust itself than it was before.

That is what the backup work gave me. A quieter kind of confidence.

And honestly, that may be one of the most useful things a homelab can produce.