On 6/28/05, Kern Sibbald <[EMAIL PROTECTED]> wrote:
> On Tuesday 28 June 2005 12:57, Martin Simmons wrote:
> ...
> >
> > >> 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!
> >
>
> To track deletions, you don't need the inode, just the full path and filename.
> If it is no longer there, it is no longer there. If it is there and has been
> re-created with a different inode, it will be backed up because of the time
> change, so there is no problem.
>
> My "trick" for keeping track of deletions is the following. Assuming the user
> turns on this option, after all the files have been backed up, but before the
> job has terminated, the FD will make a pass through all the files and send
> their names to the DIR (*exactly* the same as what a Verify job currently
> does). This will probably be done at the same time the files are being sent
> to the SD avoiding a second pass. The DIR will then compare that to what is
> stored in the catalog. Any files in the catalog but not in what the FD sent
> will receive a catalog File entry that indicates that at that point in time
> the file was deleted.
>
> During a restore, any file initially picked up by some backup (Full, ...) then
> subsequently having a File entry marked "delete" will be removed from the
> tree, so will not be restored. If a file with the same name is later OK it
> will be inserted in the tree -- this already happens. All will be consistent
> except for possible changes during the running of the FD.
>
> Since I'm on the subject, some of you may be wondering what the utility of the
> in memory tree is if you are going to restore everything (at least it comes
> up from time to time on the list). Well, it is still *very* useful because
> it allows only the last item found for a particular filename (full path) to
> be entered into the tree, and thus if a file is backed up 10 times, only the
> last copy will be restored. I recently (last Friday) restored a complete
> directory, and the Full and all the Differential and Incremental backups
> spanned 3 Volumes. The first Volume was not even mounted because all the
> files had been updated and hence backed up since the Full backup was made.
> In this case, the tree saved me a *lot* of time.
>
Thanks a million Kern for the wonderful details :-)
I really appreciate it :-)
Good luck on implementation and hope Debian people will soon make a
Package as soon as it is released :-)
Till then I need to find a temporary solution!
thanks a lot again
kind regards
Siju
> However, if you have a quadrillion files and building the tree takes 24 hours,
> you could certainly question the utility of building the tree.
>
> One more little item: over the weekend, a user complained that bscan didn't
> rebuild his catalog correctly. My answer is: not true. It worked with what
> it had. However, if you feed it only one tape per bscan and your backup(s)
> span two Volumes, bscan will hiccup as it did at some point and your catalog
> will not be correct (Bacula's records span volumes and bscan hiccups then
> ignores partial records). Moral of the story:
>
> 1. Back up your catalog in a separate job each night.
>
> 2. Make a bootstrap file for your catalog and write it to another computer,
> then you won't need to use bscan to get your catalog back.
>
> 3. If you *really* need to use bscan, be sure to feed it *all* the appropriate
> volumes in a *single* bscan execution (not one for each tape) with the
> volumes specified in the right order. This was clearly and correctly
> documented, IMO, but I've added more to this effect ...
>
> --
> Best regards,
>
> Kern
>
> (">
> /\
> V_V
>
-------------------------------------------------------
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_idt77&alloc_id492&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
