On Tuesday 04 October 2005 16:45, Arthur Emerson III wrote: > Kern Sibbald <[EMAIL PROTECTED]> wrote: > > The only part of this implementation that I have not worked out > > in my head is how to deal with the catalog. If there are two > > identical backups of a Job on two different Volumes, the Director > > is not currently aware of it. There needs to be some way of > > flagging two copies as being identical, then using only one of > > those copies for any given restore. Also, there needs to be a > > bit more work in implementing some better user interface for > > "archiving" i.e. taking Volumes (possible identical copies) out > > of the Volume pool, and then later re-introducing them. > > Forgive my ignorance if this is a stupid post, because I'm > not a developer and don't even have the software rolled out > in a production environment yet. > > Every time that I have read a list post about this type of > feature, the word "exported" keeps popping into my mind. > Is the holy grail of this whole process simply to define > a status of "exported" in the catalog to these second media > copies and not using them in any full/diff/incremental backup > decisions? > > In my particular case (and I suspect it's the same for others > as well), I need to send disaster recovery tapes to an off-site > location. Getting those tapes back can take 2-3 days, hence > calling them "exported" and needing to keep a local copy for > non-disaster use. As far as the catalog goes, it is more > important that those "exported" tapes be off-site than it is to > have a nice list of their contents locally, although having > both would be nice even though the "exported" copies should > never be used in a restore operation decision either unless it > was as a last resort. The only time that those tapes would ever > really be used would be in the event of a smouldering crater where > our server farm used to be, so scanning a tape to re-populate the > catalog would probably be happening anyway...on new hardware. :-) > > Here's an idea that I came up with the other day that may > be a Q&D solution. Is it possible to add either an internal > or external "bexport" function to Bacula that uses the existing > Bacula backup/restore code in a pipeline? What I was thinking > was to run a normal backup, and then have "bexport" use the > restore code in Bacula to read the catalogged media as if it > were doing a restore, massage the restored files in a pipe, > and then re-write them onto another volume/device as if it > were a new backup. It would be generating a new backup > volume by doing this, and differing media sizes between the > two devices wouldn't be an issue because it's essentially > writing a new backup. In the case of disk-based backups, it > might be extremely useful to perform a virtual full restore onto > the exported tapes, letting "bexport" make one volume for > export that is essentially a "full" backup generated from > the different full/diff/incrementals on disk. If adding an > "exported" tape status is too much, the Q&D solution using > existing code might be as simple as adding a second system > definition to the config file to use as a target for this > "exported" backup (copy), which might in itself solve many of > the other problems trying to keep multiple pools of a single > system's backup. > > My goal is to cut tape copies of our nightly disk backups once > per week for exporting to an off-site location, and building > these backups during the business day from overnight backups > isn't a problem. If a "bexport" utility could be developed that > would combine all of the full/diff/incremental backups in the > catalog onto one pseudo "full" backup tape volume by using > the restore code, one could even get away with running *real* > full backups only a few times per year. > > Anyway, I hope that this is a useful suggestion, and that I'm > not beating a dead horse that's already been ruled out or has > some serious logic flaw...
You are not beating a dead horse, but the essense of what you write is planned as "Migrate" (move data from one volume to another) and "Copy" (duplicate data from one volume to another). See "projects" in the main source directory. > > -Arthur > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Best regards, Kern ("> /\ V_V ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
