[Borgbackup] borg create - with option bit-rot protection/detection for the original data

Thomas Waldmann tw at waldmann-edv.de
Sat May 30 06:48:25 EDT 2020


Interesting idea, but there are some issues:

1. Ideally, the checksum for some data should be computed when the data
is written to the filesystem and should be stored with the data
(filesystems like ZFS do that)

But borg does compute the checksums (chunk ids) when it reads the data
(to create a backup of it), so there is some delay and any bitrot in
that delay time would not be noticed by borg.

A user might even get the impression that everything is fine for sure
although the file was corrupted before borg has even seen it.

2. Also, ideally, bitrot should be detected (and fixed, if possible)
when reading the data. Filesystems like ZFS do that (when accessing the
data or when a regular scrub operation over the complete pool is done).

Borg can't do that and would only notice next time when you run it in
bitrot-detect mode.

3. The borg cache is also just a cache and information about files might
be removed (e.g. if the file was not seen in the last N backups).

4. Also, it is of course a rather expensive/slow operation, because all
files would be read / chunked / hashed completely.

5. The resulting lists of chunkids can only be used for comparison if
the chunker params are the same as at the time when the cache entry was
created (and we do not store the chunker params info in the cache entries).

So I guess users who care about filesystem bitrot are better advised by
using a filesystem with checksums and redundancy. When using a ZFS
mirror, ZFS can even fix bitrot if one side of the mirror still has a
valid copy of the data.


-- 

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


More information about the Borgbackup mailing list