Hi Dave,

On Sun, 9 Jun 2019, David Wynn wrote:

... I have attached a picture ...

Sorry, I don't genrally see attachments.  I'm looking at the digest
mailing list (I rarely subscribe to anything other than digest mailing
lists), and most mailing list managers prune attachments.  I went back
to your OP and that prompted me to grab the version of BackupPC that
you're using - or at least try to.  I grabbed BackupPC-4.3.0 from link

https://github.com/backuppc/backuppc/releases/download/4.3.0/BackupPC-4.3.0.tar.gz

near the bottom of

https://github.com/backuppc/backuppc/releases/tag/4.3.0

and also I downloaded 'backuppc-master.zip' from

https://github.com/backuppc/backuppc.

Then I extracted the two archives into a scratch directory and did a
recursive diff between the two trees.  It left me rather confused but
there are mentions of paths in there that you might find interesting.

On Sat, 8 Jun 2019 G.W. Haywood wrote
> ...
> You need the full pathname for $Conf{RsyncClientPath}, not just the
> name of the executable.
> ...
I changed the V4 override to be the /usr/sbin/rsync field and ...
SAME result

Well, back to debugging.  You asked about putting 'print' statements
in the code and compiling etc.  Much of the BackupPC code is in the
form of Perl scripts.  Perl is interpreted, so no compilation is
required when you make changes to these scripts - at most you might
need to restart something so that the process re-reads and executes
your new code.  I've had to do this a few times with BackupPC to try
to figure out what's been going on.

I'd be looking in the debug logs for the incorrect commands, then
if there wasn't enough information to figure out why the commands
were incorrect I'd be looking into the code to see where those log
messages are generated, and at those points adding more, and more
informative, text to those messages - or adding new messages.  And
of course keeping safe the originals of the scripts so I can return
the system to what it was after I find what's going on and fix it.

How comfortable are you with coding in Perl?  Places you might look in
the 4.3.0 directory tree for things relevant to the rsync commands are

BackupPC-4.3.0/bin/BackupPC
BackupPC-4.3.0/lib/BackupPC/Xfer.pm
BackupPC-4.3.0/lib/BackupPC/Xfer/Rsync.pm
BackupPC-4.3.0/conf/config.pl
and the working version of same in
/etc/BackupPC/
or wherever it is and the per-PC configuration files which are most
likely under that same directory.

One other thing that springs to mind is your version of rsync_bpc.
Do you have a reasonably recent version?  Mine is from the tarball
rsync-bpc-3.0.9.12.tar.gz and I believe it's required for BackupPC
versions later than V4.  Remembering where I came into the thread I
had the impression that there might be more than one version of at
least some bits of BackupPC on your system so it might be an issue.

tornado:# >>> ls -l `which rsync_bpc`
-rwxr-xr-x 1 root staff 1982456 Aug 28  2018 /usr/local/bin/rsync_bpc

This file is an ELF executable, not a Perl script.

At this point I seem to have two options --- either keep my old
system up and running since RSYNC works fine there ...

I went through the same soul-searching when I moved from V3 to V4.  In
fact I went through it twice, in two frenzied periods separated by
about a year - and gave up the first time.  I'm still not convinced it
was worth all the pain but at least the code I'm running now has some
claim to being maintained.  I've seen people say things like "Why run
old code when you can have this shiny new code?".  Some of the code I
use now I wrote forty years ago, you can imagine my response to that.

or change all my backups for the NETSTORE back to SMB and run the
new system.

I'm not sure I'd want to go the SMB route myself but others here might
have different opinions.  I've used it in the past for larger business
networks but it's always seemed like using the proverbial sledgehammer
to crack a nut, with a lot more ways of hitting your foot to boot.

I would have thought that this would have been an easy thing for the
developers to determine the cause of but it seems they don't follow
this forum.

'The developers' is more or less one Craig Barratt.  He does read these
messages, and he does respond, but his effort seems to be pretty thinly
spread and as you can imagine being just one person with the popularity
of BackupPC he can't always respond immediately.

HTH

--

73,
Ged.


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

Reply via email to