[Borgbackup] Can different error codes of individual files be mapped to different results?

Thomas Waldmann tw at waldmann-edv.de
Mon Sep 6 15:54:40 EDT 2021


> Sometimes SSHFS is hosted by some dial-up DSL internet connection and
> that connection might simply reconnect during the time a backup is
> executed. SSHFS simply disappears in those cases.

This is a bug in sshfs, please use their issue tracker to report and 
discuss this.

Expected behaviour of a mounted, but non-working filesystem is to yield 
errors, not just appear empty.

Thus, no borg issue here.

> When this happens,
> it seems that BORG only recognizes missing files and considers that a
> warning instead of an error.

Borg has no expectation about how your files / directories should look like.

It just relies on whatever you give to it being the state which you 
actually want to back up.

If you give it an empty directory, it will be happy to backup that for you.

Also, if a filename was present in a directory, but later (when trying 
to open and read it) is gone, borg will just log a warning.

Warning means that borg has no strong opinion about whether this is OK 
or an ERROR, but that this needs to be reviewed by the operator. 
Frequently happens for temporary files or otherwise active file systems.

Thus, no borg issue here.

> Those symlinks can't be properly resolved on the NAS of course,
> so it answers with missing files.

When accessing symlinks, there are 2 modes: follow and nofollow.

When backing up, borg usually uses NOFOLLOW, so it just backs up the 
symlink, not the object it points to.

There is some exception for --read-special, see the docs.

So, no borg issue here. Maybe your network filesystem / NAS is doing 
something wrong?

You can also just try this on a local filesystem (like ext4) to verify 
borg's behaviour.

> So, is there some error code mapping of individual files or alike? 

Problems with "disappearing" files are usually due to backing up temp 
files (solution: just exclude temp locations) or due to active 
filesystem (solution: do a snapshot, so it is not actively changing).

Alternatively, review the warnings manually and ignore the ones which 
are no problem.




More information about the Borgbackup mailing list