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] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch

[Michael Stowe]

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

Michael Stowe wrote at about 23:46:54 + on Friday, May 22, 2020:
 > On 2020-05-22 16:19, backu...@kosowsky.org wrote:
 > > Michael Stowe wrote at about 22:24:13 + on Friday, May 22, 
2020:

 > >  > On 2020-05-22 09:15, backu...@kosowsky.org wrote:
 > >  > What it does is omit directories from the modification times 
that it
 > >  > sets.  In other words, you're telling it not to set the times 
on

 > >  > directories it copies.  The beginning of the epoch is pretty
 > > reasonable
 > >  > for directories which have no specific time set.
 > >  >
 > >
 > > Actually, at least the manpage is unclear.
 > > And *differs* from the default behavior of native rsync (at lesat 
on
 > > Ubuntu) that sets the dir time to the current time -- which is 
more

 > > reasonable than some arbitrary epoch = 0 time.
 > >
 > > That is what I would have expected and I believe should be the 
default

 > > behavior...
 > >
 > >  > This option has no implications for which directories are 
selected

 > > to be
 > >  > copied.
 >
 > Unset is unset, it's not the option to use if you want the directory
 > modification time set.

Regardless, behavior should be consistent with normal rsync...

If you can show me a standard *nix version of rsync that uses Epoch as
the default then I would retract my point... but otherwise Epoch is
totally arbitrary and illogical... while at least the current time has
a good rationale... Choosing 1/1/1970 not so much...


It's not that "epoch is the default" it's that that's what a timestamp 
of 0 is.  When you tell rsync not to set the timestamps, it doesn't.


If you want to touch the directories and update their timestamps to the 
current time, you can do that, but it's an odd thing to expect rsync to 
take care of for you when you explicitly tell it not to.



___
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] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch

[backuppc]

Michael Stowe wrote at about 23:46:54 + on Friday, May 22, 2020:
 > On 2020-05-22 16:19, backu...@kosowsky.org wrote:
 > > Michael Stowe wrote at about 22:24:13 + on Friday, May 22, 2020:
 > >  > On 2020-05-22 09:15, backu...@kosowsky.org wrote:
 > >  > What it does is omit directories from the modification times that it
 > >  > sets.  In other words, you're telling it not to set the times on
 > >  > directories it copies.  The beginning of the epoch is pretty 
 > > reasonable
 > >  > for directories which have no specific time set.
 > >  >
 > > 
 > > Actually, at least the manpage is unclear.
 > > And *differs* from the default behavior of native rsync (at lesat on
 > > Ubuntu) that sets the dir time to the current time -- which is more
 > > reasonable than some arbitrary epoch = 0 time.
 > > 
 > > That is what I would have expected and I believe should be the default
 > > behavior...
 > > 
 > >  > This option has no implications for which directories are selected 
 > > to be
 > >  > copied.
 > 
 > Unset is unset, it's not the option to use if you want the directory 
 > modification time set.

Regardless, behavior should be consistent with normal rsync...

If you can show me a standard *nix version of rsync that uses Epoch as
the default then I would retract my point... but otherwise Epoch is
totally arbitrary and illogical... while at least the current time has
a good rationale... Choosing 1/1/1970 not so much...


___
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] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch

[Michael Stowe]

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

Michael Stowe wrote at about 22:24:13 + on Friday, May 22, 2020:
 > On 2020-05-22 09:15, backu...@kosowsky.org wrote:
 > What it does is omit directories from the modification times that it
 > sets.  In other words, you're telling it not to set the times on
 > directories it copies.  The beginning of the epoch is pretty 
reasonable

 > for directories which have no specific time set.
 >

Actually, at least the manpage is unclear.
And *differs* from the default behavior of native rsync (at lesat on
Ubuntu) that sets the dir time to the current time -- which is more
reasonable than some arbitrary epoch = 0 time.

That is what I would have expected and I believe should be the default
behavior...

 > This option has no implications for which directories are selected 
to be

 > copied.


Unset is unset, it's not the option to use if you want the directory 
modification time set.



___
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] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch

[backuppc]

Michael Stowe wrote at about 22:24:13 + on Friday, May 22, 2020:
 > On 2020-05-22 09:15, backu...@kosowsky.org wrote:
 > > If I add '--omit-dir-times' to $Conf{RsyncArgsExtra}, then the backups
 > > set all the directory dates to the beginning of the Epoch.
 > > 
 > > For example
 > > drwxr-xr-x 3 backuppc www-data  1024 Dec 31  1969 pc/
 > > 
 > > (note this is 1/1/70 00:00:00 GMT)
 > > 
 > > This is inconsistent with normal rsync wich just uses --omit-dir-times
 > > to omit directories from --times when looking for *changes*
 > > 
 > > I was expecting and would have liked the normal behavior of
 > > --omit-dir-times to speed up backups...
 > > 
 > > Is this a bug???
 > 
 > No, it's expected behavior, you seem to have misunderstood what this 
 > rsync option does.
 > 
 > What it does is omit directories from the modification times that it 
 > sets.  In other words, you're telling it not to set the times on 
 > directories it copies.  The beginning of the epoch is pretty reasonable 
 > for directories which have no specific time set.
 > 

Actually, at least the manpage is unclear.
And *differs* from the default behavior of native rsync (at lesat on
Ubuntu) that sets the dir time to the current time -- which is more
reasonable than some arbitrary epoch = 0 time.

That is what I would have expected and I believe should be the default
behavior...

 > This option has no implications for which directories are selected to be 
 > copied.


___
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] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch

[Michael Stowe]

On 2020-05-22 09:15, backu...@kosowsky.org wrote:

If I add '--omit-dir-times' to $Conf{RsyncArgsExtra}, then the backups
set all the directory dates to the beginning of the Epoch.

For example
drwxr-xr-x 3 backuppc www-data  1024 Dec 31  1969 pc/

(note this is 1/1/70 00:00:00 GMT)

This is inconsistent with normal rsync wich just uses --omit-dir-times
to omit directories from --times when looking for *changes*

I was expecting and would have liked the normal behavior of
--omit-dir-times to speed up backups...

Is this a bug???


No, it's expected behavior, you seem to have misunderstood what this 
rsync option does.


What it does is omit directories from the modification times that it 
sets.  In other words, you're telling it not to set the times on 
directories it copies.  The beginning of the epoch is pretty reasonable 
for directories which have no specific time set.


This option has no implications for which directories are selected to be 
copied.



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

Re: [BackupPC-users] how to install SCGI , exactly??

[Doug Lytle]

>>> I am currently running BackupPC  version 4.3.2 on Ubuntu 18.04.4 LTS . 
>>> Everything seems to be working perfectly, except this pesky "2020-05-22 
>>> 10:02:30 scgi : BackupPC_Admin_SCGI: can't load perl SCGI module - install 
>>> via CPAN; exiting in 60 seconds" error

Mike, 

The only thing I have on my backuppc server is the same as yours

dpkg -l|grep -i scgi

ii  libapache2-mod-scgi   1.13-1.1amd64
Apache module implementing the SCGI protocol


How are you trying to access the admin page?

I don'g use sgi in my URL.  I use

http://192.168.145.99/backuppc

The description of the SGI admin is

# BackupPC_Admin_SCGI: An SCGI implementation of the BackupPC
#  admin interface.

Which is something I don't use, just the CGI version.

Doug


___
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] how to install SCGI , exactly??

[Greg Harris]

Or better yet, use CentOS 7 and that packaging. I can’t get to that RPM link at 
this moment. I’m sure someone else has that link available quickly. 

Thanks,

Greg Harris

> On May 22, 2020, at 12:33 PM, Doug Lytle  wrote:
> 
> 
>> 
 BackupPC is installed on an Ubuntu 18.04.4 system..
> 
> You won't want to be using BackupPC from Ubuntu 18.04's PPA, it's only 
> version 3.3.1.  BackupPC is currently at 4.3.2
> 
> My suggestion would be to install it from tarball.  I've found the below 
> instructions
> 
> https://github.com/backuppc/backuppc/wiki/Installing-BackupPC-4-from-tarball-or-git-on-Ubuntu
> 
> I could not find a PPA for BackupPC 4.3.2
> 
> Doug
> 
> 
> ___
> 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] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch

If I add '--omit-dir-times' to $Conf{RsyncArgsExtra}, then the backups
set all the directory dates to the beginning of the Epoch.

For example
drwxr-xr-x 3 backuppc www-data  1024 Dec 31  1969 pc/

(note this is 1/1/70 00:00:00 GMT)

This is inconsistent with normal rsync wich just uses --omit-dir-times
to omit directories from --times when looking for *changes*

I was expecting and would have liked the normal behavior of
--omit-dir-times to speed up backups...

Is this a bug???


___
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] how to install SCGI , exactly??

[Doug Lytle]

>>> BackupPC is installed on an Ubuntu 18.04.4 system..

You won't want to be using BackupPC from Ubuntu 18.04's PPA, it's only version 
3.3.1.  BackupPC is currently at 4.3.2

My suggestion would be to install it from tarball.  I've found the below 
instructions

https://github.com/backuppc/backuppc/wiki/Installing-BackupPC-4-from-tarball-or-git-on-Ubuntu

I could not find a PPA for BackupPC 4.3.2

Doug


___
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] how to install SCGI , exactly??

[Michael Walker - Rotech Motor Ltd .]

Thanks for the hint!
BackupPC is installed on an Ubuntu 18.04.4 system...
I am trying to get this machine to backup up our Debian 10 file server, since 
our cloud backup service doesn't support  Debian but does support Ubuntu.
I haven't used Perl in 20 years, and the last five years been working on CentOS 
exclusively, so also a little fuzzy on installing Perl modules on Ubuntu.
I do have libapache2-mod-scgi installed...
And I have found a site 
(https://www.server-world.info/en/note?os=Ubuntu_18.04=httpd=2) which 
recommended "a2enmod scgi"... but when I run that it says "Module scgi already 
enabled "... Now I'm going to try its configuration directions and see if I'm 
on the right track!


-- Original Message --
From: "Doug Lytle" mailto:supp...@drdos.info>>
To: 
"backuppc-users@lists.sourceforge.net"
 
mailto:backuppc-users@lists.sourceforge.net>>
Sent: 5/22/2020 1:00:20 AM
Subject: Re: [BackupPC-users] how to install SCGI , exactly??

On 5/21/20 7:54 PM, Michael Walker - Rotech Motor Ltd. wrote:
I cannot find any details on how to do this... cpanm is installed and
seems to be working.. but WHAT  must I ask it to get, precisely??


Mike,

What Linux Distro are you running BackupPC on?  I'm running mine on
Debian 10 (Buster)

You probably can get away with using it's package management system to
install the Perl module instead of using CPAN.

Doug





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

Re: [BackupPC-users] how to install SCGI , exactly??

[Doug Lytle]

On 5/21/20 7:54 PM, Michael Walker - Rotech Motor Ltd. wrote:
I cannot find any details on how to do this... cpanm is installed and 
seems to be working.. but WHAT  must I ask it to get, precisely??




Mike,

What Linux Distro are you running BackupPC on?  I'm running mine on 
Debian 10 (Buster)


You probably can get away with using it's package management system to 
install the Perl module instead of using CPAN.


Doug





___
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... [private version]

[Craig Barratt via BackupPC-users]

Jeff,

The tar XferMethod doesn't capture acls and xattrs during backup.

Direct Restore in the CGI interface uses the XferMethod setting.

Craig

On Thu, May 21, 2020 at 10:05 PM  wrote:

> 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  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 ; tar --acls --selinux --xattrs -cf - mac ) | tar
> xf -
>  > >b] Similarly, raw rsync copies all the files faithfully
>  > >rsync -navcxXAOH --delete  .
>  > >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/