Re: error restoring Unix socket ... path too long to be stored properly

On Mon, 3 May 2021 21:48:50 +0200
Denis Corbin <[email protected]> wrote:

> On 03/05/2021 20:16, imschmeg wrote:
> > On Mon, 3 May 2021 19:35:58 +0200
> > Denis Corbin <[email protected]> wrote:
> >   
> 
> [...]
> 
> > As long as this is just a problem with sockets, it is manageable.
> > Another likely source of sockets in the homedir is in .gnupg, which
> > I found in another user's homedir that I have not tested yet.  I
> > suspect that gnupg won't mind if they are deleted at logout, but at
> > least I have the EA-tagging technique if I need it.  
> 
> yes, you can even run the find command from dar just before entering a
> particular each home directory using the something like this:
> 
> dar -c backup -R / --backup-hook-include "home/*"
> --backup-hook-execute "find %p -type s -exec setfattr... \;" ...other
> options to dar...
> 
> Well, I would not invoke "find" directly but through a small script
> that would leverage the %c macro that comes with
> --backup-hook-execute option.
> 
> The interest of doing so appears if the time to backup is long and you
> have a heavy user activity:
> - it is more probable to flag all newly created sockets for the
> backup, than what you get when running find first, then dar,
> - the find command does not put much stress too much the disk I/O as
> it concerns just an single user home directory at a time, and while
> this user's file's metadata is still in cache, dar does not lead the
> extra I/O to read and eventually backup these metadata.

I am backing up user homedirs individually (each is the -R for its own
dar run) vs. the system root, hence --backup-hook-include has nothing to
do.  Also, the user is not logged in during the backup.

If I use --backup-hook-execute, isn't the overhead a shell spawn for
every file?  Wouldn't that be more than the single find up front?

I have done some timings, and the find -type s up front is surprisingly
fast even for large dir trees, probably because the file system is on a
SSD.