Re: [Dar-support] MAYBE BUG in dar 2.7.2 with hardlinks handling

[Alexey L. <moo...@ma...>]

On 08.12.2021 15:51, Denis Corbin wrote:
> But things are not implemented that way...
> ... (lines snipped) ...

Thanks. You had confirmed conclusions I came to after cloning dar 
sources from git today and spending a couple hours reading the code.
Just to be on the same page - I wasn't expecting dar's existing 
filtering mechanisms to be in any way similar to the "provided filelist 
instead of recursing over filesystem" approach. Thus I wanted to take a 
quick look at the implementation details to judge if it would be easy or 
not to implement "filelist approach". By the looks of it it won't be 
easy at all.


> I agree, however this would lead to a complete change of design in dar
> for a need that is a bit away of its target...
> ... (lines snipped) ...

Agree with you absolutely. It could had been a viable thing to implement 
in case no major changes were required - but that's not the case. Being 
a DevOps engineer I take a look a it both from programmers and OPs PoV: 
as a programmer I don't see a point in implementing a niche feature that 
would require a lot of refactoring and/or using some extra hacks meaning 
that implementing it would be costly from coding and testing in terms of 
time and efforts; as an OPs I obey "don't fix what aint broken", "one 
robust tool for one task" and "keep it simple, stupid" approaches and 
this feature would violate all of them. To word it in another way - dar 
is good as it is for what it was designed for, no need to overcomplicate 
it without major reasons.

> I'm pretty sure you have good reasons to use rsync + dar that way, but a
> more simple approach would be to use dar only.
> ... (lines snipped) ...

Of course there's a reason: people from the company management want to 
hove the ability to easily read-only access "directory contents 
snapshot" with 1 day granularity over the network from boxes running 
Windows for at least past two months. So it has to be CIFS share and no 
matter the backup tooling used I have to store all these per-day 
directories laying on a disk next to each other to satisfy the reqs. 
Cross hard-linking daily snapshots using rsync was a natural choice back 
in the day to save space. Nowadays there are some alternatives like VDOs 
or other deduplication solutions that work "under the hood" at 
filesystem level but it wasn't easily available back in - say - 2010.

Doubling down with DAR + a backup strategy on top of the above 
requirement was just an obvious next thing to do when company grew to a 
point to start thinking about resilience and emergency recovery from on- 
and off-site backups. Drop the requirement and I would definitely move 
to using dar-only based backup solution just to simplify and speed 
things up.

Nevertheless thanks again for an interesting discussion and for your 
time spent with me on this topic.


-- 
Regards,
Alexey Loukianov
System Engineer
*nix Expert