"" wrote at about 14:42:10 -0400 on Friday, May 22, 2020:
> 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
Regarding #3, it goes away when I erase all previous backups... so
there may be a merging-inheritance problem here as I alluded to
before...
However, #1 & #2 seem to be clear issues with implementation of rsync-bpc...
>
> 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/
_______________________________________________
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/
