[Borgbackup] Are regular check necessary?

Thomas Waldmann tw at waldmann-edv.de
Tue Oct 10 16:34:06 EDT 2017


> just recently I started evaluating borg as possible replacement for my
> rsync + ZFS snapshots backup strategy.
> So far, everything looks very good and I like borg a lot.

Glad you like it. \o/


> Q1: Are regular check necessary / recommended? Are there any best practices?

Yes, do them once in a while.

They can take quite some time, depending on your repo size and what
exactly you choose to check and how fast your hw / network is.

How often also depends on how reliable you think your hw is and how
important your data is.

Guess everything between once a week and once a year can make sense
depending on that.

> Q2: What can lead to corruption of the archive?

Often it is some hardware issue:
- hdd / ssd malfunctioning, media bitflips
- memory malfunctioning (usually non-ECC memory)
- other hw malfunctioning

HW sometimes has some CRC or ECC checks in place, but they are
relatively weak, so even with them there can be undetected corruption.

Some hw does not have checks at all, e.g. non-ECC memory.(*) :(

Sometimes there can be also other issues, like filesystem issues:
- caused by fs driver errors
- power failures
- other system crashes

Theoretically, also borg software bugs could corrupt a repo, but we did
not have such bugs in recent versions.

Borg tries to avoid that by all means by using a log-like data storage
plus transactions. So even if a backup breaks down, we can just roll
back the incomplete transaction to the previous (valid and consistent)
repo state.

> FYI, my borg backend is FreeNAS (which is based on FreeBSD) and a
> mirrored ZFS pool, so there is (almost) no risk of bit rotting.

That's a quite nice setup. If one disk has a undetected bitflip
(undetected by the hardware), zfs can detect that and choose to use the
valid data from the other disk.

If you want more safety:
- use ECC memory / other good/reliable hardware
- do a 2nd borg backup to some other hardware / location

You should avoid to lose data from a borg repo. As it is deduplicated,
there is no redundancy.


(*) https://github.com/borgbackup/borg/issues/2281

-- 

GPG ID: 9F88FB52FAF7B393
GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393



More information about the Borgbackup mailing list