"Craig O'Brien" <email@example.com>
wrote on 10/31/2013 08:49:15 AM:
> The du -hs /backup/pool /backup/cpool /backup/pc/* has finished.
> Basically I had 1 host that was taking up 6.9 TB of data with 2.8
> in the cpool directory and most of the other hosts averaging a GB
Well, there's your problem.
> The 1 host was our file server (which I happen
to know has a 2 TB
> volume (1.3 TB currently used) that is our main fileshare. >
> I looked through the error log for this pc on backups with the most
> errors and found thousands of these:
Just out of curiosity, why hadn't you already done
> Unable to read 8388608 bytes from /var/lib/BackupPC//pc/
> myfileserver/new//ffileshare/RStmp got=0, seekPosn=1501757440 (0,
Interesting. I'd make sure that the filesystem
is OK before I went much farther... Stop BackupPC, unmount /backup
and fsck /dev/<whatever>
> du -hs /backup/pool /backup/cpool /backup/pc/myfileserver/* >
> to see which backups are doing the most damage. I'll report back
> once that finishes.
With that, you should be able to find the bakup number(s)
that are not linked. You can delete them and free up space.
The big question is, though, why they aren't linking.
I'd really start at the bottom of the stack (the physical drives)
and work your way up. Check dmesg for any hardware errors. fsck
the filesystem. Did I read correctly that this is connected vis NFSv4?
I sure hope not... (I'm willing to admit it's a phobia, but
there's no *WAY* I would trust my backup to work across NFS...)