[Box Backup] Backup with far more space used than source

Kristopher Zentner boxbackup@fluffy.co.uk
Fri, 02 Sep 2005 10:34:01 -0700

Quoting Ben Summers <ben@fluffy.co.uk>:
> On 2 Sep 2005, at 17:25, Kristopher Zentner wrote:
>>> It depends, because old versions of files are kept until the soft
>>> limit on the account is exceeded. You haven't given sufficient
>>> information for any meaningful answer.
>>> * How often do the files change on the clients?
>>> * What are the individual limits and usage for the two accounts? (use
>>> bbstoreaccounts to get this)
>>> For example, if files on the 7G client changed daily and you had a
>>> 100G limit on the corresponding server account, your server could be
>>> acting as expected.
>>> Ben
>> I realize that incremental/differential updates will fill the drive  
>> after time.
>> However this is after only *one* snapshot session, my first one as  
>> I said...
> You didn't say that the 7G account only had one session, and you gave 
>  the total for both accounts. I just wanted to eliminate the obvious.
>>> Granted I'm not backing up the entire drive, only about 135G worth
>>> and this is afer only one snapshot session,
>> There hasn't been a chance for differential or incrementals to be  
>> made so how
>> often the files change is irrelevant since changes have not been  stored,
>> although there have been no changes on the drive in the time i've used
>> boxbackup. The limits I've set on that account are 250G soft limit,  
>> 259G hard.
>> Account 1 has only been backed up a few days, however, the du  command I
>> displayed showed the space used only by the account in question  
>> (account 2):
>>> (#:/backups/backup)- du -h -d 0 00000002
>>> 242G    00000002
>> account 1 by contrast is still pretty sane and i've run more than  
>> one snapshot
>> backup on it
>> (#:/backups/backup)- du -h -d 0 00000001
>> 7.1G    00000001
>> Is it possible it has something to do with using a lot of already  
>> compressed
>> media? I really have no idea why it'd be using this much.
> It does seem to be a bit high. The files are being run through a  
> compression algorithm, but it specifically states in the docs that it 
>  should only inflate by a 5 bytes per 16k or so. So that's not going  
> to be it.
> Can you do a bbstoreacounts info on the offending account to see how  
> much space it thinks it's used? The old and delete counts might be  
> interesting. You could also log in with bbackupquery to see if there  
> are any odd happenings.

Looks like there's a little old stuff in account 2 since it ran again last
night, but not much has changed...

Just for reference here's df -h on the client in question:
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             185G  142G   44G  77% /

(#:/backups/backup)- bbstoreaccounts info 2
                  Account ID: 00000002
              Last object ID: 39196
                 Blocks used: 126440279 (246953.67Mb)
    Blocks used by old files: 2282 (4.46Mb)
Blocks used by deleted files: 0 (0.00Mb)
  Blocks used by directories: 5454 (10.65Mb)
            Block soft limit: 131072000 (256000.00Mb)
            Block hard limit: 135790592 (265216.00Mb)
         Client store marker: 1125602161000000

Usage  with bbackupquery gives fairly predictable results:

query > usage
          Used   246953.7Mb  93% *************************************
     Old files        4.5Mb   0%
Deleted files        0.0Mb   0%
   Directories       10.7Mb   0%
    Soft limit   256000.0Mb  96% **************************************
    Hard limit   265216.0Mb 100% ****************************************

Also did a quick compare which actually yielded some errors. Could this 
be part
of the problem?
query > compare -a -q
WARNING: Quick compare used -- file attributes are not checked.
Local file '/home/mythtv/.xsession-errors' has different contents to 
store file
ERROR: (4/11) during file fetch and comparsion for 
'/home/mythtv/Movies/Love Act
ERROR: (7/42) during file fetch and comparsion for 

... (this error is repeated for 16 other files)

Exception: Connection Protocol_ObjTooBig (7/42)