> > I think you've answered a slightly different question. > Right now, what > > goes on the tape is block-for-block identical to what is > reported by > > the FD during the scope of that run, however flawed. If I want do > > parallel copies of those tapes at the same time for redundancy or > > offsiting, etc, then the data that goes on the copies of > the primary > > tape needs to be the same blocks as what went on the > primary tape for each job. > > Making an exact copy of a tape is not always possible, > because each tape has a slightly different length and may > also have a different number of bad spots that are > automatically handled by the drive. As a consequence, the > end of every tape, will be different (and hence all of the > next tape), unless you force Bacula to stop writing the tape > before the end of the tape. > > So, in all cases, I would program for two identical copies > being different.
OK, I think we're converging, just in slightly different ways. If I can attempt to summarize: If I understand correctly, the ultimate solution will take the blocks incoming from the FD during a single job and write them to multiple volumes. The blocks that come from the FD will be written to different positions on the different volumes, but will be the have the same content for each copy written. If one of the copies is somehow unavailable, a restore will reference one of the other copies automagically, mounting the appropriate volume if needed. If that's it, then we agree entirely...8-) I don't really care if the tapes are absolutely bit-for-bit identical (dd is an effective way to accomplish that w/o a lot of work), but that the identical data is written on more than one volume at the same time, and that Bacula is aware of that happening and can fall back to another copy without human intervention. > By the way, I am really unhappy that Bacula cannot at least > to some extent handle autochangers with two drives with > different Media Types. Could you identify for me what the > most important combinations are: Well, in my opinion.... > i.e. a drive that > reads/writes two media types; Very, very rare, to the point of being almost non-existant in the open systems world. Occurs occasionally in the mainframe world with 3480/3490 media (same physical tape cartridge, but R/W density, format and compression controlled by commands to the tape transport). > a drive that reads two media > types but writes only one; Very common (in fact, I'd say it's the most common configuration). Usually the drive automagically switches, so you are not aware of the multiple-format read capabilities. I'd also say that this is likely to be more than 2 read formats (example: DLT8000 drives can read DLT2000,4000,7000, and 8000 media, but typically write only 8000 or (maybe) 7000 media). > a drive that writes two media > types but reads only one; I don't know of any devices that fit this category. In every case I know of, if a device can write a format, it can read it. > or two drives in a changer that > have different media types, but read/write only one or the other? I think this would be the other very common case. It's not too unusual to have a enterprise tape library unit that has different types of drives installed (my STK unit has both 3480/3490 and 3590 drives in the same library, formats are not compatible between the physical drives). > For example, with a trivial amount of work, I could modify > Bacula to handle an autochanger with several Media Types, but > each drive would have only one Media Type that it would > read/write. Any of the other combinations would be more work. I think the optimum general case would be to specify multiple read formats and one write format per drive. That way, any eligible drive in an autochanger could be used for restores, and updates would be done only on devices that could reliably write the desired format. In the case of multiple drives that can read or write only one format, then the read format list would contain only 1 format, and the write format list would contain only one format. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
