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
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
