Holger Parplies <firstname.lastname@example.org> wrote on 10/30/2013
> as I understand it, the backups from before the change from smb to
> linked into the pool. Since the change, some or all are not. Whether
> change of XferMethod has anything to do with the problem or whether
> coincidentally happened at about the same point in time remains to
> I still suspect the link to $topDir as cause, and BackupPC_link is
> of the XferMethod used (so a change in XferMethod shouldn't have any
To add my anecdote, I use a symbolic link for all
of my BackupPC hosts: a couple dozen? And they all work fine.
It's been my standard procedure for almost as long as I've been using
I understand phobias from earlier problems (see my
earlier e-mail about my thoughts on NFS and backups...) but I do not think
this one is an issue.
> If the log files show nothing, we're back to finding the problem,
but I doubt
> that. You can't "break pooling" by copying, as was suggested.
Yes, you get
> independent copies of files, and they might stay independent, but
> files should get pooled again, and your file system usage wouldn't
> growing in such a way as it seems to be. If pooling is currently "broken",
> there's a reason for that, and there should be log messages indicating
You are 100% correct; but it depends on how
you define "break". Making a copy of a backup will absolutely
break pooling--for the copy you just made! :)
It won't prevent *future* copies from pooling, certainly.
But it sure can fill up a drive: even if pooling *is* working
correctly for new copies, they can still fill up the drive *and* BackupPC_nightly
won't do a thing about it.