Why hobby data deserves a plan
Makers produce files that are hard or impossible to recreate: circuit designs and schematics, firmware and scripts, 3D models, calibration settings, notes about what finally made a build work, and photographs. Losing a month of work to a single dead drive is a common and avoidable story. A backup plan does not need to be elaborate, but it needs to exist before the failure.
The rule
The 3-2-1 idea is a widely used rule of thumb:
- 3 copies of your data: the original and two backups.
- 2 different kinds of media or storage, so that one type of failure does not take out everything.
- 1 copy off-site, in a different physical location.
It is a guideline, not a guarantee. It is popular because each part answers a specific way that data gets lost, and because it is simple enough to actually follow.
Why each part matters
Three copies. If you have one copy, a failure loses everything. With two, a single failure is survivable, but a failure while you are recovering or an unnoticed problem in the backup leaves you with nothing. A third copy provides a margin. Note that the original counts as one copy; a mirrored pair of drives holding the same data still counts as one copy, because a deletion or corruption affects both. That distinction is the subject of the discussion of RAID and backups.
Two kinds of media. Different storage types fail in different ways. If every copy sits on the same kind of drive, or the same make and batch, a shared weakness could affect all. In practice, “two kinds” can be as simple as an internal drive plus an external drive, or a storage box plus a cloud service, or a drive plus optical or tape media for those who like them. Don’t over-read the wording; the point is variety of failure modes.
One off-site. Fire, flood, theft and power surges affect everything in a building together. An off-site copy might be a drive kept at a relative’s house or workplace and swapped now and then, or a copy held with an online storage provider. If you use a provider, think about what you are uploading. Consider data encryption before the files leave your machine, and keep the key somewhere safe and separate, because a backup you cannot decrypt is worthless. The questions raised for cloud services in general, such as who can read the data, apply here too.
Applying it to a home lab
A reasonable plan starts with sorting what you have:
- Irreplaceable. Personal photos, original designs, source code not stored anywhere else. These get full 3-2-1 treatment.
- Time-consuming to recreate. Server configurations, notes, database contents. Back these up regularly; consider keeping them in version control where possible, with a remote copy.
- Easily reacquired. Downloaded installers and public datasets. A backup is optional.
For source code and text-based project files, a version control system with a remote repository already provides history and a second location. That is useful, but it does not cover everything, since large binary files, settings outside the repository and secrets deliberately kept out of it need their own handling. Keep sensitive items such as API key secrecy in mind: do not copy secrets into places where they will end up unprotected.
For machines and services, work out what you would need to rebuild them: configuration files, data directories, a list of installed software, and a few notes written in plain language. Backing up a whole system image can help, but file-level backups of the important parts are usually quicker to restore and easier to check.
Versions and ransomware
A backup that simply mirrors the original will faithfully copy a mistake or an infection. Prefer backups that keep several older versions, so that you can go back to a time before a file was damaged. Also think about whether the machine you back up from can reach and modify the backup. If a compromised computer can overwrite or encrypt the backup too, then it is not much of a safety net. Keeping at least one copy offline, or on a system that only accepts new data and does not let the source delete it, reduces this risk.
Automate, but verify
People forget manual backups. Use scheduled jobs where you can, and make sure something tells you when a job fails. A backup that quietly stopped months ago is a classic trap. At minimum, check on a calendar reminder that recent files appear in the backup location.
Testing a restore
The part most often skipped is the most important. A backup is only proven when you have restored from it. Try this at intervals, and after any change to the setup:
- Pick a few files at random, including something recent and something old.
- Restore them to a different location, not over the originals.
- Open them. Does a design file load? Does a script run? Is a photo intact?
- Try a larger test now and then, such as rebuilding a small service from the backups in a scratch environment.
- Note how long it took and what was missing, then fix the gaps.
If you use encryption, include the step of recovering the key or passphrase in your test, ideally with a password manager entry or a securely stored paper copy as a fallback.
Keeping it realistic
You do not need to treat every file equally, and no scheme guarantees that data will survive every event. The aim is to make an ordinary failure, such as a dead drive, an accidental deletion or a stolen laptop, an annoyance rather than a disaster. Start with your most valuable files, get to three copies, two media and one off-site, and then test it. Adjust as your collection grows.