I also assume that tar doesn't capture ACLs and XATTRs for backup
either then
What transfer mechanism does the CGI restore use?
Because when I use the direct download mode, it also doesn't restore
the ACLs and XATTRs.
In any case, I guess I really need to figure out how to use rsync for restore...
Craig Barratt via BackupPC-users wrote at about 21:50:40 -0700 on Thursday, May
21, 2020:
> Jeff,
>
> Unfortunately BackupPC_tarCreate doesn't support acls. Over the years
> different flavors of tar supported different archive formats for certain
> extensions (eg, long file names etc). The POSIX standard for PAX headers
> unified some of the those disparate formats, but didn't define acl or xattr
> support.
>
> Over the last few years it does look like GNU tar provides support for
> acls, but using PAX headers that are not standard. Looking at the tar
> source, it uses headers like SCHILY.acl.access, SCHILY.xattr etc.
> Supporting those headers appears to require the acls and xattrs to be
> converted to descriptive strings. Currently BackupPC rsync treats acls and
> xattr as binary blobs of data that it doesn't need to interpret. So
> unfortunately it would be quit difficult to add acl and xattr support to
> BackupPC_tarCreate.
>
> Craig
>
> On Tue, May 19, 2020 at 11:49 PM <backu...@kosowsky.org> wrote:
>
> >
> > Now that I have btrfs snapshots set up, I decided to test a full
> > backup and restore by comparing the snapshot with the backup-restore
> > via rsync, using the following command:
> > sudo -u backuppc /usr/share/backuppc/bin/BackupPC_tarCreate -h myhost
> > -n -1 -s myshare . | sudo tar --acls --selinux --xattrs -xvf -
> >
> > Interestingly, I found that everything worked *except* that it failed
> > to copy any sockets or any extended attributes.
> >
> > 1. Sockets were not copied at all - but that is seemingly just a tar
> > limitation since tar can't copy 'special' files.
> > Indeed, backuppc-fuse shows that the files are actually backed up by
> > bakcuppc
> >
> > 2. Extended attributes (ACLs and SELinux context) were *never* restored
> >
> > This seems to be a problem with 'BackupPC_tarCreate" since:
> > a] Using tar alone, I can copy the files with all their extended
> > attributes
> > cd <myshare>; tar --acls --selinux --xattrs -cf - mac ) | tar xf -
> > b] Similarly, raw rsync copies all the files faithfully
> > rsync -navcxXAOH --delete <myshare> .
> > b] Backuppc-fuse shows the extended attributes
> > (though that being said backuppc-fuse adds SELinux context attributes
> > to files that don't have them... perhaps there is something wrong
> > with the inheritance??
> >
> > Note: I tried adding ' --xargs --acls --selinux --xattrs'
> > to $Conf{TarClientRestoreCmd} but that didn't help.
> >
> > So, 2 questions:
> > 1. Why doesn't BackupPC_tarCreate restore the extended attributes?
> > 2. Why does backuppc-fuse show extended attributes for files that
> > don't have them originally?
> >
> > ----------
> > Note: I am running ubuntu 18.04 with rsync 3.1.2 and backuppc 4.3.2
> >
> >
> > _______________________________________________
> > BackupPC-users mailing list
> > BackupPC-users@lists.sourceforge.net
> > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> > Wiki: http://backuppc.wiki.sourceforge.net
> > Project: http://backuppc.sourceforge.net/
> >
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
