Peter Walter wrote:
> 
>>
>> But because of the nature of the problem, rsync and cp can't do a small 
>> piece at a time - and their views of the inodes in question are only 
>> valid as long as none change before the run completes.  A tool that 
>> relinks individual files can plug away at it for as long as it takes - 
>> although I suppose it has to be aware of the nightly run. You probably 
>> have the whole blackout window with not much else to do anyway.
>>   
> Les,
> 
> Perhaps I should rephrase my issue in the context of how backuppc 
> already works. My understanding is that, if it were not for the 
> hardlinks, that rsync transfers to another server would be more 
> feasible; that processing the hardlinks requires significant cpu 
> resources, memory resources, and that access times are very slow, 
> compared to processing ordinary files. Is my understanding correct? If 
> so, then what I would think of doing is (a) shutting down backuppc (b) 
> creating a "dump" file containing the hardlink metadata (c) backing up 
> the pooled files and the dump file using rsync (d) restarting backuppc. 
> I really don't need a live, working copy of the backuppc file system - 
> just a way to recreate it from a backup if necessary, using an "undump" 
> program that recreated the hardlinks from the dump file. Is this 
> approach feasible?

First, consider the simple way that does work: unmount the partition 
holding the archive and  do an image copy like dd'ing the partition (or 
if there is only one partition on the drive, the whole raw disk) to 
something with enough space to hold it.  If the disk is mostly empty, it 
might be worth figuring out what clonezilla uses to copy images saving 
only the used space - probably partimage.  This will run about as fast 
as your disks (and network if you use it) will go, since it's one pass 
across the drive to do it.  The down side is that the partition has to 
be unmounted or at least unchanging during the copy, and you have to 
restore to a same-size partition to use it although resizing afterwards 
is possible if the new location has more space.

If you really have to go the file-by-file route, rysnc or cp have to do 
the entire thing at once because they must have access to the entire 
filename list and corresponding inode numbers to identify the matches 
that are linked.  If you don't have RAM to hold that (and you haven't 
mentioned the scale of your setup yet - it might help to know if you 
have an enormous archive or are just short on memory...) you might try 
the BackupPC_tarPCCopy approach. Basically you copy the pool without any 
links, then generate something resembling that dumpfile of hardlink 
metatadata you wanted in a form that GNU tar will understand. Some info 
here: http://backuppc.wiki.sourceforge.net/move_backup_data+.

But if your archive is huge, expect that to take a day or a few to 
complete when you try restore it - the disk head will be bouncing all 
over the place.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com



------------------------------------------------------------------------------
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/