Re: Error exits on busy systems

On 09/07/2021 14:40, John Goerzen wrote:
> Hello,

Hello,

> 
> First, thank you for dar!

you're welcome!

> 
> I am using dar as part of a script to back up in-use systems.  I have
> observed two nonzero exit codes from dar:
> 
> code 11 - when a file has been modified in-place
> 
> code 5 - when a file has "disappeared".  This happened once while a
> person was running rm -rf on a git checkout of a Linux kernel tree.
> 
> So my questions are:
> 
> 1) Does dar actually abort backup generation in these cases, or does it
> store up the error and just exit with it after the rest of the backup
> proceeds?

dar backs up as much as possible, always.  Code 11 and 5 are not fatal
errors, the process continues to its end, only the files concerned by
the error will be either ignored or stored and flagged as "dirty" (for
code 11).

Note that if a directory is unreadable or inaccessible, all files it
contains will follow the same fate as that directory (ignored from
backup). However, the backup process will continue...

> 
> 2) Is there a way to cause dar to treat these as warnings and proceed? 
> Having a backup fail due to these common race conditions is, for me,
> much worse than having a backup succeed with warnings. That is, I could
> get 500,000 good files backed up and 5 weird ones, or 0 good files
> backed up.

A dar backup should not fail when any of these conditions is met. If so
let me know, this should be seen as a bug.

> 
> I have tried --retry-on-change 20:104857600 which seems to have reduced
> the instances of code 11. 

Excellent! I like when people use options and read documentation ;^)

> But I can't find a way to *eliminate* them,

Well, you can increase the count of retry-on-change even larger and the
amount of acceptable wasted data, still remains that if a file changes
more frequently than it takes to read it entirely, you won't be sure it
is saved properly and though the code 11 will still be reported.

However you can still code 11 and consider as an acceptable backup
result, a file saved with a 'dirty' flag can still be used for
restoration (see the --dirty-behavior option).

> or to eliminate the error code when a file has disappeared.

reality is reality: code 11 and 5 will disappear if all files could be
possible to save safely, and be saved securely/properly.

> 
> I have seen these situations with tar, and it basically treats them as a
> warning. 

Tar will miss (and not report) most of such situations as its time
precision is the second (unless you use --xattr option).

More details at
http://dar.linux.free.fr/doc/benchmark.html

Second point about tar, once the warning is passed, you have not
information kept in backup about the fact such files is most probably
not properly backed up... so you cannot even decide what to do with
those type of 'dirty' backed up files.

> I understand there is a case to be made for them being an
> error, but in situations where I don't have the ability to back up from
> a snapshot of some sort, it is far preferable for me to get a pretty
> good backup than no backup at all.

se the "--dirty-behavior ignore" at restoration time should suite your
need and mimic tar's behavior (if you also consider code 11 equivalent
to 0 at backup time).

> 
> Thanks,
> 
> John
> 
> 

Cheers,
Denis