What is the 3-2-1 backup rule and how do I apply it to a homelab?

The 3-2-1 backup rule means keeping three copies of your data, on two different types of storage, with one copy stored offsite. For a homelab, that means your live data plus two backups. At least one backup sits on a different device or storage type from the original, and one is physically somewhere else. The rule is simple on purpose. It reduces the risk from a failed drive, an accidental deletion, ransomware, and a fire or theft at home.

What the three numbers mean

Three copies. This counts the live data plus two backups. If your files sit on a server and you copy them once to another disk, you have two copies, not three.

Two media. The copies should not all depend on the same kind of device. The original definition says “two different media types”. In practice, many people read it as at least two separate devices, ideally on different technologies. Examples are an internal array plus an external drive, or local disks plus cloud storage. The point is that one failure, such as a bad controller, a firmware bug, or a power surge, should not take out everything.

One offsite. At least one copy should be outside your building. Fire, flood, theft, and power events can hit everything in one location. Offsite can be cloud storage, a drive at a relative’s house, or a second site you control. Encrypt anything that leaves your property. Keep the keys somewhere that does not depend on the backed-up systems.

What to back up in a homelab

Start by listing what would hurt to lose. Most homelabs fall into three groups.

• Configs. Router, switch, firewall, and access point settings, including VLAN and PoE settings, plus service config files and DNS records. These are small, quick to back up, and painful to rebuild from memory.
• Virtual machines and containers. Back up the disk images or snapshots, and also the definitions and compose files that describe how they run. If a VM can be rebuilt quickly from a script, the script may matter more than the image.
• Data. Documents, photos, databases, and anything you cannot download again. This is usually the most important group.

Things you can easily reinstall, like a base operating system image, generally deserve a lower priority.

A worked example

These numbers are sample figures for illustration only.

Suppose you have a small server with 2 TB of data you care about. It includes 500 GB of VM disks, 1,400 GB of files and photos, and 100 GB of configs and databases. Together that is 2,000 GB, or 2 TB (using decimal units, where 1 TB = 1,000 GB).

With 2 TB of live data, plan on roughly 2 TB of space for each backup copy. Compression or deduplication may reduce this, but don’t count on it. You will also want to keep older versions as well as the latest, so plan extra room beyond 2 TB if you keep a few weeks of history. Look up the current pricing for any cloud storage yourself, since it changes.

Small configs can also go into a separate version-controlled folder or be exported on a schedule. That gives you a copy that is easy to read and compare.

Test your restores

A backup you have never restored is a hope, not a backup. Schedule a test, perhaps every few months, and do it for real:

• Restore a few individual files and open them.
• Restore one VM onto a spare host or an isolated network and boot it.
• Time the process, and write down the steps while you do it.

Also check that backup jobs are actually running. Many backup tools can send an alert on failure, so turn that on.

Common mistakes

• Treating RAID as a backup. RAID keeps a system running when a drive fails. It does not protect against deletion, corruption, ransomware, or a fire, because it faithfully replicates those problems.
• Treating sync as a backup. File sync tools copy deletions and damage to every device.
• Keeping every copy in one place. Two backups in the same room are one fire away from zero.
• Leaving the backup always writable. Malware that reaches your server may also reach a mounted backup drive. Use separate credentials, keep some versions that cannot be changed, or keep a drive disconnected.
• Forgetting the encryption keys. An encrypted backup is useless if the key was stored only on the machine that failed.
• Never testing a restore. An untested backup may fail exactly when you need it.
• Skipping the configs. Rebuilding network settings from scratch often takes longer than people expect.

If your lab holds business records or data covered by retention or privacy rules, confirm those requirements with the official source or a qualified professional.