>>>>> On Tue, 28 Jun 2005 15:44:17 +0200, Kern Sibbald <[EMAIL PROTECTED]> said:
Kern> On Tuesday 28 June 2005 12:57, Martin Simmons wrote: Kern> ... >> >> >> it Arno> does not keep track of deletions. >> Arno> The latter would require a complete compare of all directory >> >> >> entries to Arno> be backed up with what bacula has in its catalog and >> >> thus would be very Arno> resource intensive. >> Kern> One day in the near future, I will do exactly this. I've now >> finally figured Kern> out a simple way to do this -- but darn, I forgot to >> write it down. Oh well, Kern> it will come to me again :-) >> >> >> Done correctly, it should be possible to do all the work in restore >> >> for filesystems that work properly. Backup just has to record the >> >> inode number for each changed file. >> Kern> The problem is that inode is a machine specific concept. Though it >> can be Kern> simulated, it doesn't exist on Win32 or Mac (well perhaps on >> OS X). Though Kern> this would work nicely as you say, I always like to do >> things in machine Kern> independent ways. >> >> Good luck remembering it -- I don't see how you can do it without the inode >> number to detect which files are the same! >> Kern> To track deletions, you don't need the inode, just the full path and filename. Kern> If it is no longer there, it is no longer there. If it is there and has been Kern> re-created with a different inode, it will be backed up because of the time Kern> change, so there is no problem. Kern> My "trick" for keeping track of deletions is the following. Assuming the user Kern> turns on this option, after all the files have been backed up, but before the Kern> job has terminated, the FD will make a pass through all the files and send Kern> their names to the DIR (*exactly* the same as what a Verify job currently Kern> does). This will probably be done at the same time the files are being sent Kern> to the SD avoiding a second pass. The DIR will then compare that to what is Kern> stored in the catalog. Any files in the catalog but not in what the FD sent Kern> will receive a catalog File entry that indicates that at that point in time Kern> the file was deleted. Kern> During a restore, any file initially picked up by some backup (Full, ...) then Kern> subsequently having a File entry marked "delete" will be removed from the Kern> tree, so will not be restored. If a file with the same name is later OK it Kern> will be inserted in the tree -- this already happens. All will be consistent Kern> except for possible changes during the running of the FD. Ok, that should cover the basics. There are few issues though: - Restore will depend on the catalog. I think it is better to include the extra data in the backup as well, so it can be seen by bscan and bextract. - I'm not sure if it will preserve multiple hard links to the same inode. Or maybe adding or removing links will cause the data to be dumped again? - I'm not sure if it will handle renamed directories. Possibly it will work by dumping the whole tree under a renamed directory? - It remains to be seen how the backup performance of the DIR's will be affected when comparing the catalog for a large filesystem. __Martin ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
