Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

[Craig Barratt via BackupPC-users]

Jeff,

I did set the policy to permissive.  If I get some time I'll try again.

Craig

On Sat, May 23, 2020 at 10:30 PM  wrote:

> Thanks Craig.
> The --specials now works (and I agree with both you and Michael that
> it is not useful... but it validates that the restore is 'perfect' as
> far as rsync is concerned)
>
> Regarding selinux, you can turn it on in 'permissive' (non-enforcing)
> mode in which case it shouldn't do anything other than create messages
> of selinux policy violations... but it shouldn't block (or otherwise
> affect any parts of your running system)
>
> Check out the following for some details:
>
> https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
>
> Craig Barratt wrote at about 18:26:34 -0700 on Saturday, May 23, 2020:
>  > While I agree with Michael that restoring sockets isn't that useful
> (since
>  > they are only created by a process that is receiving connections on a
>  > unix-domain socket), I did fix the bug
>  > <
> https://github.com/backuppc/rsync-bpc/commit/3802747ab70c8d1a41f051ac9610b899352b5271
> >
>  > that causes them to be incorrectly restored by rsync_bpc.
>  >
>  > I'm quite unfamiliar with selinux attributes.  Is it possible to add
>  > selinux attributes to a file (with setfilecon) when selinux is disabled?
>  > Unfortunately my attempt to turn selinux on didn't go well - my machine
>  > didn't boot into a usable state, so I'm not willing to turn on selinux.
>  >
>  > Craig
>  >
>  > On Fri, May 22, 2020 at 8:26 PM Michael Stowe <
>  > michael.st...@member.mensa.org> wrote:
>  >
>  > > On 2020-05-22 16:49, backu...@kosowsky.org wrote:
>  > > > Michael Stowe wrote at about 22:18:50 + on Friday, May 22, 2020:
>  > > >  > On 2020-05-22 11:42, backu...@kosowsky.org wrote:
>  > > >  > > 1. Sockets are restored as regular files not special files -->
>  > > > BUG?
>  > > >  >
>  > > >  > Why would one back up a socket?
>  > > > I am testing the fidelity of the backup/restore cycle..
>  > > >>
>  > > >  > If you really think this is sensible, you should be able to
>  > > > accomplish
>  > > >  > it with "--devices --specials" as part of your rsync command
> lines.
>  > > >  >  From the symptoms, you have this in backup but not restore.
>  > > >
>  > > > Actually, in the original text (which you snipped), I shared my
>  > > > rsync_bpc commands for both 'dump' and 'restore', which include the
>  > > > '-D' flag (actually it's the default in the config.pl for both
> rsync
>  > > > dump and restore)... and '-D' is *equivalent* to '--devices
>  > > > --specials'
>  > > >
>  > > > And since I suspected some readers might miss that, I even noted in
>  > > > the text that:
>  > > >"Also, special files (--specials) should be included under the -D
>  > > >flag that I use for both rsync dump and restore commands (see
>  > > >below)"
>  > > >
>  > > > Hence, why I suggested this is a *BUG* vs. user error or lack of
>  > > > knowledge :)
>  > >
>  > > You've mistaken my point -- sure, the -D flag is there, but it's
>  > > behaving like it isn't.  Let's review:
>  > >
>  > > --devices
>  > > This option causes rsync to transfer character and block
> device
>  > > files  to  the  remote  system  to recreate these devices.
> This
>  > > option has no effect if the receiving rsync is not  run  as
> the
>  > > super-user (see also the --super and --fake-super options).
>  > >
>  > > Naturally this begs the question as to whether you're running it as
> the
>  > > super-user, and if you've seen the options as referred to in the man
>  > > page, which I've quoted above.
>  > >
>
___
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/

Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

[backuppc]

Thanks Craig.
The --specials now works (and I agree with both you and Michael that
it is not useful... but it validates that the restore is 'perfect' as
far as rsync is concerned)

Regarding selinux, you can turn it on in 'permissive' (non-enforcing)
mode in which case it shouldn't do anything other than create messages
of selinux policy violations... but it shouldn't block (or otherwise
affect any parts of your running system)

Check out the following for some details:
https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/

Craig Barratt wrote at about 18:26:34 -0700 on Saturday, May 23, 2020:
 > While I agree with Michael that restoring sockets isn't that useful (since
 > they are only created by a process that is receiving connections on a
 > unix-domain socket), I did fix the bug
 > 
 > that causes them to be incorrectly restored by rsync_bpc.
 > 
 > I'm quite unfamiliar with selinux attributes.  Is it possible to add
 > selinux attributes to a file (with setfilecon) when selinux is disabled?
 > Unfortunately my attempt to turn selinux on didn't go well - my machine
 > didn't boot into a usable state, so I'm not willing to turn on selinux.
 > 
 > Craig
 > 
 > On Fri, May 22, 2020 at 8:26 PM Michael Stowe <
 > michael.st...@member.mensa.org> wrote:
 > 
 > > On 2020-05-22 16:49, backu...@kosowsky.org wrote:
 > > > Michael Stowe wrote at about 22:18:50 + on Friday, May 22, 2020:
 > > >  > On 2020-05-22 11:42, backu...@kosowsky.org wrote:
 > > >  > > 1. Sockets are restored as regular files not special files -->
 > > > BUG?
 > > >  >
 > > >  > Why would one back up a socket?
 > > > I am testing the fidelity of the backup/restore cycle..
 > > >>
 > > >  > If you really think this is sensible, you should be able to
 > > > accomplish
 > > >  > it with "--devices --specials" as part of your rsync command lines.
 > > >  >  From the symptoms, you have this in backup but not restore.
 > > >
 > > > Actually, in the original text (which you snipped), I shared my
 > > > rsync_bpc commands for both 'dump' and 'restore', which include the
 > > > '-D' flag (actually it's the default in the config.pl for both rsync
 > > > dump and restore)... and '-D' is *equivalent* to '--devices
 > > > --specials'
 > > >
 > > > And since I suspected some readers might miss that, I even noted in
 > > > the text that:
 > > >"Also, special files (--specials) should be included under the -D
 > > >flag that I use for both rsync dump and restore commands (see
 > > >below)"
 > > >
 > > > Hence, why I suggested this is a *BUG* vs. user error or lack of
 > > > knowledge :)
 > >
 > > You've mistaken my point -- sure, the -D flag is there, but it's
 > > behaving like it isn't.  Let's review:
 > >
 > > --devices
 > > This option causes rsync to transfer character and block  device
 > > files  to  the  remote  system  to recreate these devices.  This
 > > option has no effect if the receiving rsync is not  run  as  the
 > > super-user (see also the --super and --fake-super options).
 > >
 > > Naturally this begs the question as to whether you're running it as the
 > > super-user, and if you've seen the options as referred to in the man
 > > page, which I've quoted above.
 > >


___
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/

Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

[backuppc]

Michael Stowe wrote at about 03:25:45 + on Saturday, May 23, 2020:
 > On 2020-05-22 16:49, backu...@kosowsky.org wrote:
 > > Michael Stowe wrote at about 22:18:50 + on Friday, May 22, 2020:
 > >  > On 2020-05-22 11:42, backu...@kosowsky.org wrote:
 > >  > > 1. Sockets are restored as regular files not special files --> 
 > > BUG?
 > >  >
 > >  > Why would one back up a socket?
 > > I am testing the fidelity of the backup/restore cycle..
 > >> 
 > >  > If you really think this is sensible, you should be able to 
 > > accomplish
 > >  > it with "--devices --specials" as part of your rsync command lines.
 > >  >  From the symptoms, you have this in backup but not restore.
 > > 
 > > Actually, in the original text (which you snipped), I shared my
 > > rsync_bpc commands for both 'dump' and 'restore', which include the
 > > '-D' flag (actually it's the default in the config.pl for both rsync
 > > dump and restore)... and '-D' is *equivalent* to '--devices
 > > --specials'
 > > 
 > > And since I suspected some readers might miss that, I even noted in
 > > the text that:
 > >"Also, special files (--specials) should be included under the -D
 > >flag that I use for both rsync dump and restore commands (see
 > >below)"
 > > 
 > > Hence, why I suggested this is a *BUG* vs. user error or lack of
 > > knowledge :)
 > 
 > You've mistaken my point -- sure, the -D flag is there, but it's 
 > behaving like it isn't.  Let's review:
 > 

So we both agree it's a BUG... :)

I also tried just using --specials which also didn't work..
And '-D' *does* backup & restore devices... so seems like the issue is
that 'specials' are not being restored (but they are dumped
properly)... which is the BUG that I originally reported at the start
of the thread...

 > --devices
 > This option causes rsync to transfer character and block  device
 > files  to  the  remote  system  to recreate these devices.  This
 > option has no effect if the receiving rsync is not  run  as  the
 > super-user (see also the --super and --fake-super options).
 > 
 > Naturally this begs the question as to whether you're running it as the 
 > super-user, and if you've seen the options as referred to in the man 
 > page, which I've quoted above.

Again, referencing the  rsync_bpc command I shared (which you
clipped from the thread), you would see that I ran it as 'sudo' (plus
the default includes the options '--super' anyway)


___
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/

Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

[Craig Barratt via BackupPC-users]

While I agree with Michael that restoring sockets isn't that useful (since
they are only created by a process that is receiving connections on a
unix-domain socket), I did fix the bug

that causes them to be incorrectly restored by rsync_bpc.

I'm quite unfamiliar with selinux attributes.  Is it possible to add
selinux attributes to a file (with setfilecon) when selinux is disabled?
Unfortunately my attempt to turn selinux on didn't go well - my machine
didn't boot into a usable state, so I'm not willing to turn on selinux.

Craig

On Fri, May 22, 2020 at 8:26 PM Michael Stowe <
michael.st...@member.mensa.org> wrote:

> On 2020-05-22 16:49, backu...@kosowsky.org wrote:
> > Michael Stowe wrote at about 22:18:50 + on Friday, May 22, 2020:
> >  > On 2020-05-22 11:42, backu...@kosowsky.org wrote:
> >  > > 1. Sockets are restored as regular files not special files -->
> > BUG?
> >  >
> >  > Why would one back up a socket?
> > I am testing the fidelity of the backup/restore cycle..
> >>
> >  > If you really think this is sensible, you should be able to
> > accomplish
> >  > it with "--devices --specials" as part of your rsync command lines.
> >  >  From the symptoms, you have this in backup but not restore.
> >
> > Actually, in the original text (which you snipped), I shared my
> > rsync_bpc commands for both 'dump' and 'restore', which include the
> > '-D' flag (actually it's the default in the config.pl for both rsync
> > dump and restore)... and '-D' is *equivalent* to '--devices
> > --specials'
> >
> > And since I suspected some readers might miss that, I even noted in
> > the text that:
> >"Also, special files (--specials) should be included under the -D
> >flag that I use for both rsync dump and restore commands (see
> >below)"
> >
> > Hence, why I suggested this is a *BUG* vs. user error or lack of
> > knowledge :)
>
> You've mistaken my point -- sure, the -D flag is there, but it's
> behaving like it isn't.  Let's review:
>
> --devices
> This option causes rsync to transfer character and block  device
> files  to  the  remote  system  to recreate these devices.  This
> option has no effect if the receiving rsync is not  run  as  the
> super-user (see also the --super and --fake-super options).
>
> Naturally this begs the question as to whether you're running it as the
> super-user, and if you've seen the options as referred to in the man
> page, which I've quoted above.
>
___
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/

Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

[Michael Stowe]

On 2020-05-22 16:49, backu...@kosowsky.org wrote:

Michael Stowe wrote at about 22:18:50 + on Friday, May 22, 2020:
 > On 2020-05-22 11:42, backu...@kosowsky.org wrote:
 > > 1. Sockets are restored as regular files not special files --> 
BUG?

 >
 > Why would one back up a socket?
I am testing the fidelity of the backup/restore cycle..


 > If you really think this is sensible, you should be able to 
accomplish

 > it with "--devices --specials" as part of your rsync command lines.
 >  From the symptoms, you have this in backup but not restore.

Actually, in the original text (which you snipped), I shared my
rsync_bpc commands for both 'dump' and 'restore', which include the
'-D' flag (actually it's the default in the config.pl for both rsync
dump and restore)... and '-D' is *equivalent* to '--devices
--specials'

And since I suspected some readers might miss that, I even noted in
the text that:
   "Also, special files (--specials) should be included under the -D
   flag that I use for both rsync dump and restore commands (see
   below)"

Hence, why I suggested this is a *BUG* vs. user error or lack of
knowledge :)


You've mistaken my point -- sure, the -D flag is there, but it's 
behaving like it isn't.  Let's review:


--devices
   This option causes rsync to transfer character and block  device
   files  to  the  remote  system  to recreate these devices.  This
   option has no effect if the receiving rsync is not  run  as  the
   super-user (see also the --super and --fake-super options).

Naturally this begs the question as to whether you're running it as the 
super-user, and if you've seen the options as referred to in the man 
page, which I've quoted above.



___
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/

Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

Michael Stowe wrote at about 22:18:50 + on Friday, May 22, 2020:
 > On 2020-05-22 11:42, backu...@kosowsky.org wrote:
 > > 1. Sockets are restored as regular files not special files --> BUG?
 > 
 > Why would one back up a socket?
I am testing the fidelity of the backup/restore cycle..
> 
 > If you really think this is sensible, you should be able to accomplish 
 > it with "--devices --specials" as part of your rsync command lines.  
 >  From the symptoms, you have this in backup but not restore.

Actually, in the original text (which you snipped), I shared my
rsync_bpc commands for both 'dump' and 'restore', which include the
'-D' flag (actually it's the default in the config.pl for both rsync
dump and restore)... and '-D' is *equivalent* to '--devices
--specials'

And since I suspected some readers might miss that, I even noted in
the text that:
   "Also, special files (--specials) should be included under the -D
   flag that I use for both rsync dump and restore commands (see
   below)"

Hence, why I suggested this is a *BUG* vs. user error or lack of
knowledge :)


___
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/

Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

[backuppc]

"" 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 \
 > 

Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

[Michael Stowe]

On 2020-05-22 11:42, backu...@kosowsky.org wrote:

1. Sockets are restored as regular files not special files --> BUG?


Why would one back up a socket?

If you really think this is sensible, you should be able to accomplish 
it with "--devices --specials" as part of your rsync command lines.  
From the symptoms, you have this in backup but not restore.



___
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/

Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

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