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.
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_id=7477&alloc_id=16492&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
