The Unbeaten Path: Why Your Home Directory Shouldn't Be Backed Up
If you read any guide on backing up a personal server or a developer workstation, you will inevitably find the same sacred cow grazing in the center of the pasture: the home directory. It is presented as the non-negotiable core, the ultimate prize to be preserved at all costs. We are told to snapshot it, mirror it, and replicate it across continents. Yet, I have come to believe this is a profound misdirection. To build truly resilient and fluid systems, we should consider a different path: don't backup your home directory.
The logic is so ingrained it feels like heresy to question it. Our dotfiles, our shell history, our painstakingly crafted configurations—they feel like us, an extension of our digital self. To lose them would be a kind of amnesia. But this emotional attachment is precisely the problem. It conflates the system's state with our own identity, creating a brittle anchor that resists the very change and adaptation that system administration demands. By zealously preserving every scrap in `/home`, we are not building a safety net; we are cultivating a museum of our past decisions, many of which were likely flawed or temporary.
Instead, I advocate for a system of disposability. Your shell aliases, your editor preferences, your terminal color schemes—these are not precious artifacts. They are expressions of a current need. By not backing them up, you are forced to codify the truly important parts. The script that automates your deployment isn't just a file in `/home/user/bin`; it's an entry in a Git repository. The server configuration isn't a collection of text files scattered about; it's defined in an Ansible playbook or a Dockerfile. These things, the actual engines of your service, are version-controlled, documented, and backed up by their very nature of existing in a repository. They are separate from the ephemeral environment you happen to be working in today.
The Liberating Force of Forgetting
There is a liberating power in allowing your working environment to be transient. When you accept that your home directory is a scratchpad, a temporary workshop, you are freed from the baggage of outdated configurations. How many old, half-remembered scripts linger in your `~/bin`, their purpose lost to time? How many environment variables are set that no longer apply? By starting fresh—or, more accurately, by rebuilding your environment from a small set of version-controlled 'seed' files—you are forced to re-evaluate what is actually necessary. This process is not a disaster recovery; it's a periodic pruning, a deliberate act of hygiene that prevents the accumulation of digital cruft.
This is not about recklessness. It is about intentionality. By drawing a bright line between the disposable workspace and the permanent, version-controlled assets, you create a system that is far more robust. A server failure becomes an opportunity to rebuild a cleaner, more purpose-built environment, not a frantic scramble to restore a sprawling, monolithic snapshot of the past. The true backup isn't a tarball of your entire drive; it's the git repository, the infrastructure-as-code definitions, and the documented procedures that allow you to reconstruct a working system from first principles. The home directory is just a temporary camp you set up along the way, and there is a profound freedom in knowing you can break camp and move on without having to carry every single stone you ever touched.
Notes & further reading
A few pages I came back to while writing this: