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

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!

> 
> Regards,
> Daniel
> 

Cheers,
Denis