Holger Parplies wrote at about 01:50:13 +0200 on Wednesday, June 3, 2009:
 > Hi,
 > 
 > Jeffrey J. Kosowsky wrote on 2009-06-02 17:40:23 -0400 [Re: [BackupPC-users] 
 > Backing up a BackupPC server]:
 > > [...]
 > > Backing up the BackupPC data would then be as simple as the following:
 > > 1. Shutdown BackupPC
 > > 2. Copy the pool to the new destination (no hard links)
 > > 3. Recurse through the pc directories as follows:
 > >            - Copy directory entries to the new destination (i.e. recreate
 > >      directories using something like mkdir)
 > >    - Copy regular files with nlinks=1 to the new destination
 > >    - For hard-linked files, use the header (or footer) to find the
 > >      cpool pathname (reconstructed from the hash and the chain
 > >      number). Then create the corresponding link on the new
 > >      destination.
 > > 4. Restart BackupPC
 > > 
 > > If you don't add the pool hash information to the cpool file
 > > header/footer, then you could still do a similar process by adding an
 > > intermediate step (say 2.5) of creating a lookup table by recursing
 > > through the pool and associating inodes with cpool entries. Then in
 > > step 3 you would use the inode number of each hard-linked file in the
 > > pc directory to look up the corresponding link that needs to be
 > > created. This would require some cleverness to make the lookup fast
 > > for large pools where the entire table might not fit into memory. My
 > > only concern is that this may require O(n^2) or O(nlogn) operations
 > > vs. the O(n) for the first method.
 > 
 > you do, of course, realize that I've implemented most of that (after all, I
 > wrote so [1] in a reply to one of your messages [2]) - far enough to use it
 > myself for a local pool copy of an admittedly rather small pool (103 GB, 10
 > million directory entries, 4 million inodes). Nobody seemed to care. I've had
 > more important things to do, so I didn't continue my work on that subject.
 > 

My apologies. I had forgotten (early alzheimers?) that you had done
that work. I do need to find the time to look at your code more
closely so I don't forget it in the future. And I do care because I
think it is an important utility both practically and also from the
theoretical perspective of "playing" with the structure.

As a partial excuse for my forgetfulness, I was more focused on the
advantages of having the full file md5sum prepended/appended to the
pool file which should significantly speed up the algorithm. The step
2.5 paragraph was added more as an afterthought...


 > Hope that helps.
 > 
 > Regards,
 > Holger
 > 
 > [1] <20081209031017.GM883 AT gratch.parplies DOT de>
 > [2] <[email protected]>
 > 

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/