On 2018-09-17 12:15, G.W. Haywood via BackupPC-users wrote:
Hello again all,
[Replying to myself here to try to get the thread back on topic.]
Thank you!
On Mon, 17 Sep 2018, G.W. Haywood wrote:
... I suspect that this is a fault in BackupPC_backupDelete ...
8<----------------------------------------------------------------------
BackupPC_backupDelete debug output: userid is redacted, NO OTHER
CHANGES.
The pool is on a 3TB LUKS encrypted volume which is mounted on
/mnt/3TLV
and /var/lib/backuppc is a symlink to /mnt/3TLV/backuppc. The
function
RmTreeQuietInner seems to be seeing some sort of bowdlerization of
these.
8<----------------------------------------------------------------------
tornado:/var/lib/backuppc/pc/kestrel# >>>
/usr/share/backuppc/bin/BackupPC_backupDelete -h kestrel -n 268 -l -s
Homes XXXXX/.cache 'XXXXX/.moonchild productions'
__bpc_pidStart__ 13276
BackupPC_backupDelete: $fullDelPath=[/Homes/XXXXX/.cache];
$delPathM=[/XXXXX/f.cache]
BackupPC_backupDelete: removing #268/Homes/XXXXX/.cache
__bpc_progress_state__ merge #268/Homes/XXXXX/.cache ->
#267/Homes/XXXXX/.cache
BackupPC_backupDelete: Merge into backup 267/Homes/XXXXX/.cache
bpc_attrib_backwardCompat: WriteOldStyleAttribFile = 0,
KeepOldAttribFiles = 0
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_backupDelete: $fullDelPath=[/Homes/XXXXX/.moonchild
productions]; $delPathM=[/XXXXX/f.moonchild productions]
BackupPC_backupDelete: removing #268/Homes/XXXXX/.moonchild
productions
__bpc_progress_state__ merge #268/Homes/XXXXX/.moonchild productions
-> #267/Homes/XXXXX/.moonchild productions
BackupPC_backupDelete: Merge into backup 267/Homes/XXXXX/.moonchild
productions
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.moonchild productions)
bpc_attrib_dirWrite: old attrib has same digest; no changes to ref
counts
__bpc_pidStart__ 13279
BackupPC_refCountUpdate: computing totals for host kestrel
__bpc_progress_state__ sumUpdate 0/128
bpc_attrib_backwardCompat: WriteOldStyleAttribFile = 0,
KeepOldAttribFiles = 0
__bpc_progress_state__ sumUpdate 8/128
__bpc_progress_state__ sumUpdate 16/128
__bpc_progress_state__ sumUpdate 24/128
__bpc_progress_state__ sumUpdate 32/128
__bpc_progress_state__ sumUpdate 40/128
__bpc_progress_state__ sumUpdate 48/128
__bpc_progress_state__ sumUpdate 56/128
__bpc_progress_state__ sumUpdate 64/128
__bpc_progress_state__ sumUpdate 72/128
__bpc_progress_state__ sumUpdate 80/128
__bpc_progress_state__ sumUpdate 88/128
__bpc_progress_state__ sumUpdate 96/128
__bpc_progress_state__ sumUpdate 104/128
__bpc_progress_state__ sumUpdate 112/128
__bpc_progress_state__ sumUpdate 120/128
__bpc_progress_state__ rename total
BackupPC_refCountUpdate: host kestrel got 0 errors (took 8 secs)
BackupPC_refCountUpdate total errors: 0
__bpc_pidEnd__ 13279
BackupPC_backupDelete: got 0 errors
__bpc_pidEnd__ 13276
8<----------------------------------------------------------------------
It looks very much to me as if a directory path was built incorrectly.
Observations anyone? For the avoidance of unfairly cast doubt, the
command line that I've given is verbatim except as noted carefully in
my intro. In other words nothing has been changed which would make
the slightest difference to someone who wanted to establish that the
command I used was correct - or otherwise. If it was incorrect, I'd
love to know in what way. If the tool is not to be used in this way
to do what the documentation says it does, please explain why. The
documentation says "You don't need to manually run these utilities."
which is a long way from "You must not manually run these utilities."
and in fact it goes on later to discuss manual use of some of them.
(And one of them can, apparently, _only_ be run manually.)
What is indicating to you that a directory path is built incorrectly?
Is [the correct way to reduce the storage used by V4] documented?
Pointers would still be most welcome. I'd like to delete some junk
from the pool. Yes, it would have been nice if it hadn't got in there
in the first place. But it's there now and I'd like to get rid of it.
From your description of symptoms, it seems like something else is going
on that might be interfering with what you're attempting to do. Does it
make sense to focus on rsync first?
... BackupPC appears to think that it has now used 5TB of a 3TB
disc and the claimed usage is growing. ...
... and growing. It's now claiming 8.5TB used by the pool. Pretty
soon the claimed pool usage will exceed the total storage used by all
the hosts that are being backed up. Real partition usage is ~80%, of
course it's is using nothing like the storage it claims to be using.
This can be a side effect of running the BackupPC_delete tool, since I
don't believe it bothers updating pool usage at the same time. This
should catch up eventually... or possibly indicate something else going
on.
...the incremental backup which was started on 8th September
completed in just under 8 minutes, but the one started on 9th
September is still running a week later...
...now, more than a week. What's it doing?
Let's find out!
Can you trace the rsync processes on each side to see what they're
doing?
_______________________________________________
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/
