Re: Is there a way to get a different return-code when incremental backup didn't actually find a difference?

On Monday, October 11, 2021 7:41:49 PM CET Denis Corbin wrote:
> On 11/10/2021 15:36, Daniel wrote:
> > Hi Joost!
> > 
> > I have a few ideas, but the answer will not be too professional, sorry
> 
> > bout that :-):
> Nice list of pointers, thanks Daniel!
> 
> > 1. When running dar, you can direct the output to a file, for instance:
> > dar ... > /backup/date.log
> > This file contains lines that start with "Adding file" or "Adding
> > folder" and that is what exactly means there has been changes (besides
> > perhaps permission-changes, that might be with other strings).
> > If there is no change, then there are none of the strings above in the
> > file which can be checked easily with a grep and after you can easily
> > delete the archive created with no data.
> > 
> > 2. You can use -T option aswell to get info about what was archived with
> > minimal scripting.
> 
> yep, you have also -Txml to parse XML output. XML output is a more
> stable dar output over time, from dar version to dar version.
> 
> > 2. We got here the option "-d" which diffs the archive and the place to
> > be backed up. You can use this option to tell before backing up if it
> > will save anything (simple greps and scripting again).
> > 
> > 3. Usualy stroage costs less than retrieval, so if that is the case, you
> > must know that when in need of specific files or dirs, the log file you
> > can create in my "1." above can be used to tell which archive contains
> > the most recent version of the file for instance. Directories can be a
> > bit more problematic because of lot of files, but you can tell when
> > anything was archived in that dir and which archive contains it.
> > Also you can use the command that Denis gave us few years ago to even
> > tell which slice contains the file or dir that needs to be retrieved:
> > "./dar -t /path/to/backup/with/backuparchive -al -E "touch %b.%N.%e" -g
> > etc/xml/xml-core.xml | sed -rn -e 's/.*\s+(.*\.[0-9]+.dar) has a bad or
> > corrupted.*/\1/p'"
> 
> There is a more simple way to do the same, since release 2.5.0:
> 
> dar -l <backup> -g some/relative/path/to/file -Tslice
> or more widely:
> dar -l <backup> -Tslice
> 
> <backup> as always can be replaced by an isolated catalogue, so you
> don't have to fetch anyting from a cold storage at the cost of storing
> the isolated catalogues locally.
> 
> By the way, the use of an isolated catalogue also applies to restoration
> (see -A with -x option)
> 
> > (you can search for this in the forum)
> > Actually I have created a good method with the above (100% thanks to
> > Denis of course) to minimize costs when using Azure cold storage where
> > the retrieval costs tons compared to storage :-)
> > 
> > Hope I helped anything... :-)
> 
> It helped me at least :) thanks!

Thank you Daniel and Denis,

I will look into these options.
Also going to check if storing them into "dar_manager" files can make this 
simpler as well.
I prefer not having to parse large outputs to find this, so need to wait for my 
current full backup to finish before I'll have any new incrementals to deal 
with. (No incrementals are currently stored locally, so need to wait)

--
Joost