From: Tino S. <bac...@ti...> - 2011-03-02 14:11:19
|
Hi Craig, thanks for the information. I've got some questions, though... On Wed, Mar 02, 2011 at 12:33:13AM -0800, Craig Barratt wrote: > The next topic is the attribute file format and how backups > are stored. > > In 4.x the only information that appears in a backup tree > (ie: a single backup stored below $TOPDIR/pc/HOST/NNN) are > the attribute files, one per directory. The downside of this is that I cannot easily peek into a backup on command line any more. :-( It's been very helpful to quickly figure out which files have bee backed up (e.g. to determine unneccessarily backed up stuff). Now I'll lose that capability and have to resort to web page clicking... or us that FUSE FS part of the release? > In contrast, a filled backup in 3.x includes a complete set > of files using hardlinks, in addition to the attribute file. > Also in 3.x a full directory tree had to be created even > for incremental backups. > > In 4.x it is no longer necessary for a complete backup tree of > directories to be created. Only sufficient directories to store > the attribute files necessary for the reverse time deltas are > needed. Ok, so how do you implement orphan deletion - how are files detected which are not needed in pool any more? > In 4.x a new attribute file format is used. A new magic number > identifies the new format. For each file in the directory, > the 4.x attributes additionally stores: > > - the file's digest (ie: MD5 full file digest, with possible > extension for collisions) > > - an inode number (inode) > > - an inode link count (nlinks) > > - extended attributes (xattr) > > The inode number is generated locally during the backup process > (ie: it is not related to the inode number on the client). Note that this will blow up if somebody is using ReiserFS since that does not have real inode numbers, but invents them on access. It might be impossible to implement a sanity check to detect that case... > Inodes attributes (for client hardlinks) are stored in an additional > tree of directories below each backup directory. The attribute hash key > is the inode number. 128 directories are used to store up to 128 attrib > files. The lower 14 bits of the inode number are used to determine the > directory (bits 13 to 7) and the file name within that directory > (bits 0-6). These two 7 bit values are encoded in hex (XX and YY): > > $TOPDIR/pc/HOST/NNN/inode/XX/attribYY. > > where NNN is the backup number. Oh, or do you mean: The inode number is made up by BackupPC? Then please don't call it inode number, but rather hardlink-ID or so. Thanks, Tino, happy BackupPC user since 3.0.0. -- "What we nourish flourishes." - "Was wir nähren erblüht." www.tisc.de |