Re: [BackupPC-users] Problems with latest rsync-bpc 3.1.3 - zlib??

2020-05-24 Thread Craig Barratt via BackupPC-users
Thanks for the updates.  Yes, rsync's included zlib isn't compatible with
system zlib.  However, since you are not using the -z option, I don't think
that's the issue.

Can you try rsync-bpc 3.1.2.1?  It has more testing than 3.1.3.beta0.

Craig

On Sun, May 24, 2020 at 7:43 PM  wrote:

> Upgrading to the latest rsync-bpc 3.1.3 fixed the problem with
> specials.
> And restores all seemed to work last night, until I tried dumps today.
>
> Now all my scheduled backups fail with error message:
> rsync error: error in rsync protocol data stream (code 12) at
> io.c(226) [Receiver=3.1.3.beta0]
>
> Also, when I run BackupPC_dump, it hangs at the beginning:
>   Running: /usr/bin/rsync_bpc --bpc-top-dir /var/lib/backuppc
> --bpc-host-name testmachine --bpc-share-name /usr/local/bin --bpc-bkup-num
> 0 --bpc-bkup-comp 3 --bpc-bkup-prevnum -1 --bpc-bkup-prevcomp -1
> --bpc-bkup-inode0 2 --bpc-attrib-new --bpc-log-level 6 -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 --checksum --acls --xattrs
> --timeout=72000 myhost:/usr/local/bin/ /
>   full backup started for directory /usr/local/bin
>   started full dump, share=/usr/local/bin
>   Xfer PIDs are now 7793
>   xferPids 7793
>   This is the rsync child about to exec /usr/bin/rsync_bpc
>   cmdExecOrEval: about to exec /usr/bin/rsync_bpc --bpc-top-dir
> /var/lib/backuppc --bpc-host-name testmachine --bpc-share-name
> /usr/local/bin --bpc-bkup-num 0 --bpc-bkup-comp 3 --bpc-bkup-prevnum -1
> --bpc-bkup-prevcomp -1 --bpc-bkup-inode0 2 --bpc-attrib-new --bpc-log-level
> 6 -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 --checksum --acls
> --xattrs --timeout=72000 myhost:/usr/local/bin/ /
> bpc_path_create(/var/lib/backuppc/pc/testmachine/0)
>   bpc_attrib_backwardCompat: WriteOldStyleAttribFile = 0,
>   KeepOldAttribFiles = 0
>
> This problem resolves when I downgrade back to rsync-bpc 3.0.9.
>
> Googling suggest this might have something to do with internal
> vs. external zlib.h
>
> I tried configuring with --with-included-zlib=yes (default) and =no.
> But both had the same error.
>
> Note that when =yes, in order to compile, I had to change:
>  #include  --> #include "zlib/zlib.h"
> in token.c (and also changed for consistency in batch.c and options.c)
> since the symbol Z_INSERT_ONLY was not defined in my /usr/include/zlib.h
>
> Any thoughts on what I need to do to make this work?
>
>
> ___
> 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] Problems with latest rsync-bpc 3.1.3 - zlib??

2020-05-24 Thread backuppc
Upgrading to the latest rsync-bpc 3.1.3 fixed the problem with
specials.
And restores all seemed to work last night, until I tried dumps today.

Now all my scheduled backups fail with error message:
rsync error: error in rsync protocol data stream (code 12) at io.c(226) 
[Receiver=3.1.3.beta0]

Also, when I run BackupPC_dump, it hangs at the beginning:
  Running: /usr/bin/rsync_bpc --bpc-top-dir /var/lib/backuppc 
--bpc-host-name testmachine --bpc-share-name /usr/local/bin --bpc-bkup-num 0 
--bpc-bkup-comp 3 --bpc-bkup-prevnum -1 --bpc-bkup-prevcomp -1 
--bpc-bkup-inode0 2 --bpc-attrib-new --bpc-log-level 6 -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 --checksum --acls --xattrs --timeout=72000 
myhost:/usr/local/bin/ /
  full backup started for directory /usr/local/bin
  started full dump, share=/usr/local/bin
  Xfer PIDs are now 7793
  xferPids 7793
  This is the rsync child about to exec /usr/bin/rsync_bpc
  cmdExecOrEval: about to exec /usr/bin/rsync_bpc --bpc-top-dir 
/var/lib/backuppc --bpc-host-name testmachine --bpc-share-name /usr/local/bin 
--bpc-bkup-num 0 --bpc-bkup-comp 3 --bpc-bkup-prevnum -1 --bpc-bkup-prevcomp -1 
--bpc-bkup-inode0 2 --bpc-attrib-new --bpc-log-level 6 -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 --checksum --acls --xattrs --timeout=72000 
myhost:/usr/local/bin/ / bpc_path_create(/var/lib/backuppc/pc/testmachine/0)
  bpc_attrib_backwardCompat: WriteOldStyleAttribFile = 0,
  KeepOldAttribFiles = 0

This problem resolves when I downgrade back to rsync-bpc 3.0.9.

Googling suggest this might have something to do with internal
vs. external zlib.h

I tried configuring with --with-included-zlib=yes (default) and =no.
But both had the same error.

Note that when =yes, in order to compile, I had to change:
 #include  --> #include "zlib/zlib.h"
in token.c (and also changed for consistency in batch.c and options.c)
since the symbol Z_INSERT_ONLY was not defined in my /usr/include/zlib.h

Any thoughts on what I need to do to make this work?


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

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

2020-05-24 Thread Michael Stowe

On 2020-05-23 23:47, backu...@kosowsky.org wrote:

Regarding your comment:

 However, I don't think it makes sense to
"fix" it, since a backup shouldn't add metadata that changes each time 
you

backup some data that hasn't changed.


Actually, the whole point of --ignore-dir-times is that the dir mod
time is not changed each time you rsync.

Behavior is as follows:
1. When created, the mod time is set to 'rsync' run time
2. This mod time is *not* changed on subsequent 'rsyncs' unless a
   change to the directory contents occurs in which case the
   directory timestamp is updated to the *current* time

Indeed, one reason to use --ignore-dir-times is to avoid changing the
mod time every time the directory mod time changes.

This is different from the absence of --times that changes the mod time 
of

files/links/devices to the current time on every rsync since the files
show up as changed (unless you also use --ignore-times)

This behavior can be verified by using rsync.
Also, it can be gleaned from the following pulled from the man pages:


--ignore-dir-times and --omit-dir-times are two different options


___
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

2020-05-24 Thread backuppc
Regarding your comment:
>  However, I don't think it makes sense to
> "fix" it, since a backup shouldn't add metadata that changes each time you
> backup some data that hasn't changed.

Actually, the whole point of --ignore-dir-times is that the dir mod
time is not changed each time you rsync.

Behavior is as follows:
1. When created, the mod time is set to 'rsync' run time
2. This mod time is *not* changed on subsequent 'rsyncs' unless a
   change to the directory contents occurs in which case the
   directory timestamp is updated to the *current* time

Indeed, one reason to use --ignore-dir-times is to avoid changing the
mod time every time the directory mod time changes. 

This is different from the absence of --times that changes the mod time of
files/links/devices to the current time on every rsync since the files
show up as changed (unless you also use --ignore-times)

This behavior can be verified by using rsync.
Also, it can be gleaned from the following pulled from the man pages:

o A t means the modification time is different and is being
  updated to the sender’s value (requires --times).  An
  alternate value of T means that the modification time will
  be set to the transfer time, which happens when a
  file/symlink/device is updated without --times and when a
  symlink is changed and the receiver can’t set its time.
  (Note: when using an rsync 3.0.0 client, you might see the
  s flag combined with t instead of the proper T flag for
  this time-setting failure.)

Craig Barratt wrote at about 18:34:54 -0700 on Saturday, May 23, 2020:
 > I wasn't previously familiar with the --omit-dir-times option.  As you
 > discovered, the low-level parts of rsync_bpc don't 100% faithfully mimic
 > the native linux system calls.  In particular, the mkdir() in rsync_bpc
 > doesn't set the mtime, since rsync updates it later (assuming
 > --omit-dir-times is not specified).
 > 
 > It would be a one-line change to set the mtime to the current time in
 > bpc_mkdir() in bpc_sysCalls.c.  However, I don't think it makes sense to
 > "fix" it, since a backup shouldn't add metadata that changes each time you
 > backup some data that hasn't changed.
 > 
 > Craig
 > 
 > On Fri, May 22, 2020 at 8:17 PM Michael Stowe <
 > michael.st...@member.mensa.org> wrote:
 > 
 > > 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/
 > >


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: