[Borgbackup] What to do if file is lost?

[Marian Beermann]

On 06.07.2016 17:57, Tomasz Melcer wrote:
> On 06.07.2016 17:44, Marian Beermann wrote:
>> The data files is another story. There's no forward error correction in
>> Borg itself, so errors can be detected but only some minor errors can be
>> corrected. "borg check --repair" will replace corrupted data chunks with
>> runs of zeroes of the same length, while saying where it did that.
>> Corrupted commit tags can take some more data with them to nirvana.
> 
> So, please correct me if I'm wrong:
> 
> Let say there was a bad block inside one of the data files. After
> recovery I can just run `borg check --repair`, and while some of the
> data will be lost, other chunks will still be there. Therefore, I can
> fully recover all past backups except for the chunk(s) hit by the bad
> blocks.

Well it always depends on what block is exactly hit and how.

You may lose a lot of FS structure through one unlucky bad block
equating to tons of data loss, or maybe just a data block somewhere.
If it's only in the data, then check--repair has an easy job and it'd be
really only that block, if it also hit's structure metadata more chunks
in the same file may be lost.
If it hit's a commit more may be lost.
If it hit's the one chunk you're interested in right now you have a
problem and so on.
If it hits the metadata of an archive the archive may loose some files
upon repair or may be un-repairable, but no data *per se* would be lost.

But in principle, yes, and from a pure statistics view the likelihood of
data itself being affected instead of metadata is high for a single block.

> 
> One more question. If the next backup will happen to have the same
> chunk, will it be added to the backup, filling the missing part for
> older backups? In some scenarios I find it likely that a possible bad
> block could just hit a chunk of one of the files that are still
> available on the live system.
> 

Yes, but the old backup archive will still have a run of zeroes in it.

To explain why, a rough sketch how data storage works in Borg (also
explained in the internals docs in more detail). A file item has a chunk
ID list, which lists the chunks containing the file data in order (and
some metadata). If check finds that one of these is gone, then it
creates a *new* chunk, same size as the corrupted one, made from zeroes,
stores it, and *edits* the chunk ID list of the affected file to refer
to the zeroes chunk instead.

If you do a new backup after that, then the corrupted chunk simply won't
be in the repository any more and will be newly stored by the backup.
But since creating a new backup doesn't touch old archives the old
archive will still have a run of zeroes there.

Arguably this could be improved (e.g. when repairing a file, edit the
chunk ID list, but also store how it was edited - when the affected
chunks are stored back in the repository these files may be healed
"retrospectively" then.)

Cheers, Marian