Re: questions about --retry-on-change and --ref

On Sun, 25 Apr 2021 22:08:37 +0200
Denis Corbin <[email protected]> wrote:

> ...
> When doing a differential backup, a dirty entry found in the archive
> of reference always lead dar to consider the file has change since the
> archive of reference ans "subsequent dar incremental backup ... [will]
> pick up the changes" to use your words. However if the files is
> changing again, it will be flagged as dirty in the differential
> backup.

OK - that is the answer I was hoping for.  Thanks.

> 
> > 
> > If one dar archive is itself still being written while being used
> > as a --ref argument for another, what will happen?    
> 
> First, this is not supported. To use an archive as reference it must
> be completed. Second dar will not be able to read an archive until it
> completes as before it will lack the catalogue (=table of content).
> You can however feed a archive of reference with --sequential-read
> mode, in that case if the archive of reference is under construction
> by a first dar instance and some data is lacking for a second
> instance of dar to read it, the system will suspend this second dar
> instance up to the time some data is available for reading.

I'm going to use a lock around the backup processes so that this
kind of overlap doesn't occur.

One other question comes to mind that is somewhat related.  Suppose
that a backup is broken slightly (a bit flipped, for instance).  Will
using that backup as a reference with dar --ref to make an
incremental or differential backup detect the breakage and fail?  I am
using par2 with dar, so I can potentially fix such breakage, but I have
noticed that par2 verify is quite slow on large archives, so I don't
run it every time prior to using a backup as a --ref (my plan is to run
par2 repair once a month). What I'm most afraid of is some
breakage in a --ref archive that gets propagated to subsequent
incremental backups without detection by dar, and that such breakage
cannot be fixed with par2 repair running on those incremental backups.
So, I am hoping that dar does at least a quick checksum check of its
--ref argument backup. The man page does not specify an error code for
this case, though, unless this case counts as part of exit code 5.