Re: tarsnap warnings/errors what do they mean

[Colin Percival <cperciva@tarsnap.com>]

On 07/15/11 19:02, Harry Putnam wrote:
> Colin Percival <cperciva@tarsnap.com> writes:
>> On 07/14/11 12:50, Harry Putnam wrote:
>>> tarsnap: Couldn't list extended attributesCouldn't list extended
>>> attributesCouldn't list extended attributes: No such file or directory
>>
>> What OS are you running?  Do you have any files which are being deleted
>> at the same time as tarsnap is running?  I've never seen these errors
>> before.
> 
> Gentoo linux kernel 2.6.39
> 
> Some deletions would have occurred on Sunday but none the day of the
> problem run. There are some symlinks, but tar does the right thing
> with those.  
> 
> Further this directory is an encrypted (encfs) directory, but when it
> is mounted, acts like any other directory.  I've backed it up once
> before the same way on tarsnap, but saw no such problems.

Weird.  Let me know if you ever see this happen again, I guess...

>                                        Total size  Compressed size
>   All archives                          47030209524      36001424803
>     (unique data)                       34296164508      27775819442
>   This archive                              3314305          1364006
>   New data                                   562817            44112
> 
> I don't quite understand this output.  The part that says:
> `New data      562817'   would indicate something like .5 megabyte has
> been added.. right?

562817 bytes of new data was uploaded yes.  But due to compression, only
44112 bytes were actually uploaded.

> If that is what it means then I don't understand what is going on.
> 
> Every thing that happens in that directory is done manually only by
> me, except for a junk.tar.gz backup taken on Sundays thru a script run
> by cron.
> 
> The most that would have been added since the last backup would be 1
> or 2 tiny txt files with no more than 25-30 characters in them.  And in
> fact there were probably some backup files (some.txt~ type files) that
> were removed since the original backup.

Given the high (12:1) compression ratio, I suspect almost all of the 562817
bytes of "new" data is tar headers; because tarsnap groups these together
before sending them through the deduplication, any change -- adding a new
file or deleting an old file -- can result in a new ~64kB "chunk" of tar
headers being created.

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid