Back
SiTech
Backups Aren't Simple: why a second disk is not enough
SiTech AI Team2 წთ. საკითხავი

Backups Aren't Simple: why a second disk is not enough

A new blog post walks through why a backup must not be a mirror of your disk: snapshots, rotation, deduplication and tested restores are what actually stand between you and data loss.

Data loss happens more often than most people expect, and almost always at the worst possible moment. Aleksandar Filipovski makes that point in a new blog post with a family story: photos moved onto an external drive to free up space were erased when his father formatted the drive so a TV set-top box could use it. The photos were recovered, but the lesson stayed.

A second copy is only the start

The first principle is simple — keep a copy of your files somewhere else. On its own it is not enough. A connected drive can be encrypted by ransomware or emptied by a mistyped command. A backup therefore should not be a mirror of the original disk: RAID 1 and similar schemes reproduce mistakes as faithfully as they reproduce files, and cannot rewind time. What is needed are snapshots.

Snapshots raise two questions. How often they are taken is the Recovery Point Objective: under 30 seconds at financial institutions, 24 hours or more at small companies. How long they are kept is a storage problem, solved by rotation — daily snapshots kept 14 days, weekly ones seven weeks, monthly ones a year.

Deduplication and real-world failures

File changes follow a fat-tailed distribution, so most files in a snapshot set are identical. Deduplicated backups that store one copy and reference it from every snapshot therefore save disk space and bandwidth. rsnapshot does exactly this with hard links, and the approach survives rotation because only directory entries are deleted, never the files themselves. Those bandwidth savings carry a direct price when the second machine is a cloud service.

Home labs bring their own failures: containers create root-owned files that break backups run from a normal cron job, and databases that flush data to disk in batches restore corrupted unless they are dumped separately. Hardware is a risk too — which is where the 3-2-1 rule comes from: three copies, two media types, one offsite. Object storage such as S3 adds constraints: metadata is lost on upload and many small files are expensive, so archives have to be packed into chunks.

Use the tools that solved this already

The post's honest conclusion is that building this yourself is not worth the mental load; Borg and Restic already handle encryption, chunk-level deduplication and checksums. None of it counts, however, unless restores are actually tested — roughly every six months, the author suggests.

SSiTech

SiTech — AI-powered web development

We build fast, modern websites and bring AI into real business workflows. Have a project or a question? We'd love to help.