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) Back to the original issue: the most likely reason backups are taking longer that you expect is that your excludes are not correct. Are you sure you are excluding /proc and any other sparse potentially large files (eg, /var/log/wtmp)? For the backup that is taking a lot longer than expected, you should look at its current XferLOG file. It won't be complete (the most recent portion won't be yet written to disk), but using BackupPC_zcat should allow you see what it is has been doing at least up until recently. If you really want to see what it happening in real time, you could run strace on rsync_bpc as Michael suggested, or an easier option would be to run BackupPC_dump from the command line with the -v option. That should write all output to stdout. Hopefully that shows what unexpected things are being backed up. Craig On Thu, Sep 20, 2018 at 12:11 AM Michael Stowe < michael.st...@member.mensa.org> wrote: > On 2018-09-19 03:52, G.W. Haywood via BackupPC-users wrote: > > Hello again all, > > > > On Tue, 18 Sep 2018, Michael Stowe wrote: > >> On Mon, 17 Sep 2018, G.W. Haywood wrote: > >> > >>> I suspect that this is a fault in BackupPC_backupDelete ... > >>> RmTreeQuietInner seems to be seeing some sort of bowdlerization > >>> ... > >>> 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) > >>> ... > >> > >> What is indicating to you that a directory path is built incorrectly? > > > > The part that says: > > > > 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) > > > > BackupPC has somehow concatenated the mount path and the symlink path > > and come up with balderdash. I've started on tracking it down by > > means of log statements, but what with all these alligators time has > > been a bit short. > > This is curious, as it would potentially represent a problem for anybody > whose repository is sym-linked. It's possible that the delete process > is leaving unexpected debris, and this is reponsible for the unexpected > space that BackupPC is consuming. > > We've all got alligators; if nobody gets to it first, I'll pursue this. > > >> Does it make sense to focus on rsync first? > > > > Well it's rsync_bpc not rsync, and I have no idea, but vide infra. > > Fair enough -- though presumably it's rsync_bpc on one side and rsync on > the other. If you've already killed the process and it doesn't get > stuck again, it may not be much to worry about. If it hangs again, it's > probably worth tracing both sides to see what it's up to. > > >>> Is [the correct way to reduce the storage used by V4] documented? > > > > I guess I'll just leave this hanging and hope for the hive to come up > > with something. > > > > On Tue, 18 Sep 2018, Guillermo Rozas wrote: > >> On Mon, 17 Sep 2018, G.W. Haywood wrote: > >> > >>>>> ... BackupPC appears to think that it has now used 5TB of a 3TB > >>>>> disc and the claimed usage is growing. ... > >>> > >>> ... and growing. ... > >> > >> Regarding this point: have you tried reducing the parameter > >> PoolSizeNightlyUpdatePeriod? ... forcing it to check the size in a > >> single night ... for a couple of days solved it. > > > > Oh, dammit, thank you! I remember seeing that when I trawled through > > the new configuration options and then forgot all about it. I set it > > to 1 last night, before the nightly backup run, then stopped BackupPC, > > killed the ten-day-old rsync_bpc, restarted BackupPC and hit the sack. > > This morning normality seems to be restored, at least the crazy usage > > figures have disappeared and the V4 pool size looks sane again: > > > > 8<---------------------------------------------------------------------- > > Pool is 940.29+987.81GiB comprising 1757074+1459146 files and > > 16512+4369 directories (as of 2018-09-19 01:29), > > Pool hashing gives 1678+1909 repeated files with longest chain 7+4, > > Nightly cleanup removed 6436+10275 files of size 135.04+0.26GiB > > (around 2018-09-19 01:29), > > Pool file system was recently at 75% (2018-09-19 08:49), today's max > > is 80% (2018-09-19 01:00) and yesterday's max was 80%. > > 8<---------------------------------------------------------------------- > > > > There were log messages for over 17,000 missing pool files but I'm > > guessing that this is probably the result of my manually running > > BackupPC_backupDelete. I haven't had a chance to investigate that > > but I will do later. > > > > Thanks again! > > > _______________________________________________ > 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/
