The Cost of Keeping a Spare

One practical spare can be more valuable than a large inventory of cheap parts. This is the practical question behind the article: what is enough, what fails first, and what should be kept simple?

Start with the job

Choose the service before choosing the hardware. A small server that runs one important workload reliably is more useful than a powerful machine with no clear owner. Write down the expected users, whether the service must run continuously, what data it stores, and what happens if it is unavailable for a day.

The decision points

Failure domains, replacement time and portability. The answer should be based on the workload you can describe today, not a future list of every service you might someday install. Leave room for one sensible change, then stop.

Build it so it can be undone

Keep configuration in a documented location, back up application data separately from the operating system, and record the last-known-good state. Test access from the device you will actually use. If the service is important, write the recovery steps before you need them.

A practical first test

1. Measure the current hardware or service before changing it.
2. Install the smallest useful version of the workload.
3. Run it long enough to see ordinary failure modes.
4. Check logs, storage, temperature and access from another device.
5. Decide whether it earned a permanent place.

The honest trade-off

Every self-hosted service trades money for ownership and maintenance. That can be a good trade, especially for private data, learning or a service that is otherwise expensive. It is a poor trade when the system is critical, undocumented and powered by hardware nobody wants to repair.

Failure domains, replacement time and portability.