[rear-users] [rear/rear] b0278f: Add --warning=no-xdev to suppress 'file is on a di...
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
> 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=RSYNC or BACKUP=TSM.
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
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
True and last year I did lot's of tests already. The
BACKUP_URL must be capable of storing ACLs, SElinux attributes, otherwise
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...
More information about the rear-users