Since there's nothing of interest in the XferLOG file, I'd recommend
running BackupPC_dump from the command-line with the -v option. That
should copy all log messages to stdout so you should see them in real
time. First make sure there are no backups running on HOST (where HOST is
kestrel or localhost or whatever client you want to run) and then run this
as the BackupPC user:
su backuppc
BackupPC_dump -v -f HOST
If that doesn't show much useful information, the next step is re-run after
increasing the XferLogLevel (eg, to 5) and adding "-vv" or "-vvv" to
$Conf{RsyncArgs} (which increases the logging level from the remote
(client) rsync).
Craig
On Thu, Sep 20, 2018 at 10:10 PM G.W. Haywood via BackupPC-users <
backuppc-users@lists.sourceforge.net> wrote:
> Hi there,
>
> Thanks for your reply.
>
> On Thu, 20 Sep 2018, Craig Barratt wrote:
>
> > First, this error message looks like just a bug in the message text: it
> > shouldn't be concatenating those paths:
> >
> > > RmTreeQuietInner:
> > >
> /mnt/3TLV/backuppc/pc/kestrel/268//var/lib/backuppc/pc/kestrel/268/XXXXX
> > > isn't a directory (while removing
> > > /var/lib/backuppc/pc/kestrel/268/XXXXX/f.cache)
>
> That's good news, so I guess it doesn't hurt anything and it can be
> left with you to fix in due course.
>
> > Back to the original issue: the most likely reason backups are
> > taking longer that you expect is that your excludes are not correct.
>
> That's not the case here.
>
> > Are you sure you are excluding /proc and any other sparse
> > potentially large files (eg, /var/log/wtmp)?
>
> Yes I am. For the vast majority of machines (including the one for
> which rsync_bpc which was in an infinite loop), I'm only backing up
> /etc/ and /home/. Perhaps the share names don't make it obvious, but
> bear in mind that I've been backing up most of these machines using
> BackupPC V3 for nearly a decade.
>
> As you probably saw I've killed the errant rsync_bpc process (the one
> which had so far taken ten days to do an eight minute job) so the best
> I can offer at the moment is to say it looks like manually running a
> BackupPC_backupDelete job caused rsync_bpc to loop on the next backup.
>
> > For the backup that is taking a lot longer than expected, you should
> > look at its current XferLOG file.
>
> The backup which ran after I killed the one which was spinning took
> four hours 20 minutes to complete and it was a full backup. The one
> which is running now was started 24 hours later. It's still running
> after 19 hours and the XferLOG contains two bytes:
>
> tornado:/mnt/3TLV/backuppc/pc/localhost# >>> ls -l XferLOG.738.z
> -rw-r----- 1 backuppc backuppc 2 Sep 19 20:00 XferLOG.738.z
> tornado:/mnt/3TLV/backuppc/pc/localhost# >>> hexdump XferLOG.738.z
> 0000000 5e78
> 0000002
>
> Now this has your attention, would you offer your thoughts on my use
> of BackupPC_backupDelete in the way that I used it? Specifically, as
> a tool to remove unwanted parts of all backups for a given host? It
> seems to me to be a long felt want. In one particular case here, the
> unwanted directory was backed up because a directory whose name began
> with a dot also had a space in it. :(
>
> --
>
> 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/
>
_______________________________________________
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/
