Craig,
Using rsync (rather than tar) to restore, I think I confirmed several
bugs with the handling of sockets and SELinux attributes
Hopefully, I have provided enough info to debug...
In summary:
0. All my ACLs are dumped & restored properly (with rsync) --> GOOD
1. Sockets are restored as regular files not special files --> BUG?
2. SELinux attributes are not dumped for directories and links --> BUG?
3. SELinux attributes for regular files are generally handled OK, but
sometimes dump generates an SELinux entry where none exists
in the source. This happens for a few files where the
SELinux entry previously existed in earlier backups on the
host... I don't understand this... and need to investigate
it further
Here are some examples showing the behavior
1. Sockets are dumped as 'sockets' but restored as 'regular' files
srw-rw-rw- 1 postfix postfix ? 0 May 21 03:39
/mnt/backuppc/all/myhost/256/root/var/spool/postfix/private/scan
-rw-rw-rw- 1 postfix postfix ? 0 May 21 03:39
/tmp/tmprestore/root/var/spool/postfix/private/scan
srw-rw-rw- 1 postfix postfix ? 0 May 21 03:39 /var/spool/postfix/private/scan
Note that the first listing shows a backuppc-fuse mounting of the dump,
confirming that the dump is stored properly.
Note that rsync itself has no problem copying sockets and special
files.
Also, special files (--specials) should be included under the -D
flag that I use for both rsync dump and restore commands (see below)
2. SELinux for 'links' & 'directories' fail to Dump the SELinux entry but
otherwise dump & restore properly
(see the /mnt/backpupc/all/myhost line which shows the backuppc-fuse version)
drwxrwxr-x 6 root root ? 1024 Jan 28 2019
/mnt/backuppc/all/myhost/256/root/usr/local/lib/mac/
drwxrwxr-x 1 root root ? 428 Jan 28 2019
/tmp/tmprestore/root/usr/local/lib/mac/
drwxrwxr-x. 1 root root system_u:object_r:lib_t:s0 428 Jan 28 2019
/usr/local/lib/mac/
lrwxrwxrwx 1 root root ? 17 Nov 20 2009
/mnt/backuppc/all/myhost/256/root/usr/local/etc/motd -> motd.good
lrwxrwxrwx 1 root root ? 17 Nov 20 2009
/tmp/tmprestore/root/usr/local/etc/motd -> motd.good
lrwxrwxrwx. 1 root root system_u:object_r:etc_t:s0 17 Nov 20 2009
/usr/local/etc/motd -> motd.good
(note that it succeeds though for the corresponding link target (see below)
3. SELinux for 'regular files' generally dumps and restore properly
For a handful of files, dump creates an SELinux entry even though
the source didn't have such entry. Perhaps it was wrongly
inherited/merged from an earlier backup???? I need to investigate
this further... as it is quite strange
Dump & Restore succeeds here (most common)
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 11 Jan 17 2008
/mnt/backuppc/all/myhost/257/root/usr/local/etc/motd.good
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 11 Jan 17 2008
root//usr/local/etc/motd.good
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 11 Jan 17 2008
/usr/local/etc/motd.good
Dump seems to create a new SELinux entry where none existed
previously in the source; Restore then restores it...
-rw-rw-r--. 1 root root system_u:object_r:lib_t:s0 5889 Aug 12 2002
/mnt/backuppc/all/myhost/257/root/usr/local/lib/emacs/site-lisp/gin-mode.el
-rw-rw-r--. 1 root root system_u:object_r:lib_t:s0 5889 Aug 12 2002
root/usr/local/lib/emacs/site-lisp/gin-mode.el
-rw-rw-r-- 1 root root ? 5889 Aug 12 2002
/usr/local/lib/emacs/site-lisp/gin-mode.el
---------
Note the command I use to restore is:
/usr/bin/rsync_bpc --bpc-top-dir /var/lib/backuppc --bpc-host-name \
myhost --bpc-share-name root --bpc-bkup-num 257 --bpc-bkup-comp 3 \
--bpc-bkup-merge 257/3/4 --bpc-attrib-new --bpc-log-level 1 -e \
/usr/bin/sudo\ -h --rsync-path=/usr/bin/rsync --recursive --super \
--protect-args --numeric-ids --perms --owner --group -D --times \
--links --hard-links --delete --partial --log-format=log:\ %o\ %i\ %B\ \
%8U,%8G\ %9l\ %f%L --stats --acls --xattrs / myhost:/tmp/tmprestore/root
And from the logs, the corresponding dump command was:
/usr/bin/rsync_bpc --bpc-top-dir /var/lib/backuppc --bpc-host-name \
myhost --bpc-share-name root --bpc-bkup-num 257 --bpc-bkup-comp 3 \
--bpc-bkup-prevnum -1 --bpc-bkup-prevcomp -1 --bpc-bkup-inode0 3325462
--bpc-attrib-new \
--bpc-log-level 1 -e /usr/bin/sudo\ -h --rsync-path=/usr/bin/rsync \
--super --recursive --protect-args --numeric-ids --perms --owner \
--group -D --times --links --hard-links --delete --delete-excluded \
--one-file-system --partial --log-format=log:\ %o\ %i\ %B\ %8U,%8G\ %9l\ %f%L \
--stats --acls --xattrs --timeout=72000 myhost:/ /
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/
