[rear-users] [rear/rear] b0278f: Add --warning=no-xdev to suppress 'file is on a di...

Gratien D'haese gratien.dhaese at it3.be
Fri Jun 15 16:50:42 CEST 2012

On Tue, 12 Jun 2012 20:51:20 +0200 (CEST), Dag Wieers wrote:
> On Tue, 12
Jun 2012, Schlomo Schapiro wrote:
>> Do you happen to know which
versions of tar support this option? Not that
>> we fail on
older/conservative distros...
> Yes, we need to take care of that. But
in my opinion the whole NETFS name 
> makes this harder. I think it would
be better to change BACKUP=NETFS into 
> BACKUP=TAR, just like we have

BACKUP=NETFS uses by default tar, but with
BACKUP_PROG we can overrule this
(e.g. pax, rsync or star).

I like the
current style, and if we go for BACKUP=TAR then we need to define for
new flow a specific backup program and maybe scripts.
I'm not too fond of

> The BACKUP_URL specifies the location anyway.

That is correct,
but doesn't say anything about the BACKUP_PROG, right?

> If I currently
want to make this more advanced for tar, we make the 
tar/rsync/custom-backup script even more complex. We have the 
infrastructure to test and set capabilities, but 50_make_backup.sh is not

> adapted to it.
> The downside of splitting this script is that we
have to duplicate the 
> progress code.

I would prefer to post-pone this
for rear-1.15 at least. Let us first get the current version
stable before
releasing it. Much has changed in the meantime.

> PS For tar we need to
take into account --selinux to, based on the 
> capabilities of tar. Same
for rsync...

True and last year I did lot's of tests already. The
BACKUP_URL must be capable of storing ACLs, SElinux attributes, otherwise
bad luck.
It looks easier then it really is. We will/must make backup
script more complex to handle all the situations (or at least the prep
That is why I still prefer the current way - it simply works.

Can you make an issue for splitting BACKUP=TAR and the capabilities ?
we can, but wait with it (I'm not ready for this idea yet :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pikachu.3ti.be/pipermail/rear-users/attachments/20120615/9bca1dd9/attachment.html 

More information about the rear-users mailing list