Hello, On Wed, 7 Apr 2010 08:20:46 +1000 "James Harper" <[email protected]> wrote:
> > > > 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). In PostgreSQL, toast objects (like blob) larger than 1024bytes are compressed by the engine in toast area. (MySQL should do the same thing) > 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. Yes, and the tape could also be offsite like in a vault when the autochanger is full. I think that crash recovery backups should always be stored on disk, you can't wait 20 mins to get your tape online in emergency cases. Bye > 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 -- Eric Bollengier <[email protected]> ------------------------------------------------------------------------------ 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
