> > I've decide to put the metadata in the catalog, which really disgusts me, > > but > > I see no other choice to have a general solution that will work with both > > disk and tape Volumes (as well as future devices such as the cloud). > > > > Won't that make for a really huge catalog?
While each backup might have up to 500KB of XML metadata, it is just plain text and XML text at that so it compresses remarkably well - down to a 25KB .zip file (or a 15KB .7z file). I did some rough calculations and that seems to correlate to around 5% of the space that the files in the system state would take up in the File table in the catalogue (I don't think I counted indexes). That figure would probably drop down to less than 1% in a full backup. > What if it were placed in the > catalog temporarily, then a secondary job was triggered by the end of > the backup job that wrote the catalog record(s) to a volume and on > success deleted the catalog record(s)? The secondary job would have to > somehow be associated with the backup job, though, so that a restore > first restored the catalog record(s) and then proceeded with the restore. The problem has always been that on restore you need the metadata before you start restoring any files. The metadata is how you tell VSS what you are restoring - it includes the state of the backup (success/failure per component etc). If you wrote it to the backup media then the restore needs to read from the end of the backup first (which is possibly on another tape) and then go back to the start. This isn't such a problem for disk based media when everything is on a single disk, but if it was on multiple disks or tapes it adds a significant amount of mucking around changing tapes etc. James ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
