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.gm...@gratch.parplies.de> > [2] <18749.12572.675749.745...@consult.pretender> > ------------------------------------------------------------------------------ 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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/