Re: Bug#174525: ITP: dar -- Disk ARchive: Backup directory tree and files.
On Sat, Dec 28, 2002 at 01:12:10PM +0100, Russell Coker wrote:
> On Sat, 28 Dec 2002 08:28, Brian May wrote:
> > - The Author recommends linking with -static, so restoration programs
> > will work without extra libraries. I haven't decided if this is a good
> > idea or not, if it needs to be applied to all binaries. lintian
> > gets upset if my package contains static binaries.
>
> I suggest having a separate "dar-restore-static" package for that.
Good idea.
>
> > - My version is compiled with ATTR (EA) support, however, DAR gets very
> > verbose if the filesystem doesn't support ATTRs (IMHO errors of type
> > "Operation not supported" need to be ignored). These warnings
> > will disappear if the -Uu flags are used (don't archive ATTRs).
>
> Maybe you could patch it to check for ATTR support on backup at the start of
> each file system. If a file system does not support ATTR then display a
> single message "File system /var does not support ATTR." and continue on with
> no further messages. Of course it's a bit more serious if you do a restore
> with ATTR support and the file system doesn't like it...
The problem with this approach is that it would need to be done
on a per file basis rather then per filesystem (eg. consider backing
up multiple filesystems).
Looking at the code though it should be trivial to check errno==ENOTSUP
at the appropriate place, and just return an empty EA list in this
case (exactly what would happen with the -Uu flag or
if EA support wasn't enabled when compiling).
I suspect that the write routine only attempts to write EAs
if there are EAs to write, so theoritically it should already
be OK. Even if there are EAs to write and you want to extract
anyway, it should be possible to use -Uu flag to prevent
dar from complaining.
> > - ssh can be used for backups (just pipe the data via ssh to the
> > destination file), for incremental backups (generate catalog at server
> > and send it to client first). However, I am not certain about restores
> > (client requires 2 pipes to server, one in each direction; this makes
> > me nervous about potential deadlocks).
>
> Shouldn't be a problem, just do "ssh client restore-comand" and then the
> client's stdin and stdout are the two pipes you need. Gotta test it first of
> course, but I expect it to work.
That only brings STDOUT and STDIN to the local computer.
The hard part will be doing:
dar ... | ssh client darr_slave | dar ...
where both dars represent the one process (so the above
command line wont work).
In other programs (eg. rsync, scp, cvs) it is more usually done like:
dar ... -e ssh client darr_slave
dar currently doesn't support this.
I have heard that Bi-Directional communications like this is a risky,
and buffering issues have caused big problems even for programs like
rsync (hopefully resolved now).
--
Brian May <bam@debian.org>
Reply to: