Kern Sibbald wrote: > Hello, > > I don't remember getting any feedback from you concerning my comments on this > proposal.
Hi Kern. I wrote back saying that I may have underestimated that Bacula was smart enough to avoid using the same volume. So I removed my hack to mark tapes as USED to see how things go. My request to override NextPool may not be necessary for the purposes that I was trying to use it for. I'm happy to have just one full pool, as long as when I do the next VirtualFull backup and it reads the last full backup that it wont fight for the same tape. However I could see that it would be handy for the times you may want to make multiple copies from a pool to separate destinations. > I have been thinking about it, and a second problem that you mentioned that I > did not address in my comments was that the Volume to be read must be marked > as Full or Used (if I remember right). I originally did this to ensure that > the same Volume could never be used for reading and writing, and also, quite > often I imagined Migrations being used to free up old Volumes, so naturally > in such a case one would not want to see the Volume immediately written again > after part or all of it was Migrated -- or at least not until it was > recycled. > > Perhaps it is time to relax the requirement that the Volume be marked Used or > Full before it will be Migrated. This might simplify the setup you have and > totally eliminate the need to have schedule nextpool overrides. > > What do you think? I'm not really familiar enough with the product to be able to comment on the above just yet. I've been fighting crashes with the storage daemon each weekend, which is making things hard for me to test. On a Friday night I try to have an Incremental, followed by a VirtualFull, followed by a Copy job. This can run for over a day, and for whatever reason the storage daemon doesn't seem to handle it. I've hacked up my configuration to use the two drives in my tape library individually because the Copy job refuses to use the same device for read and write. But in this case the device is a tape library with two drives, so it should be able to. I've looked at the code and comparing migrate.c to vbackup.c I can see that both had the same device check, but vbackup.c has it #ifdef'ed out with a comment saying that the pools should be checked instead of the device. I'm about to do the same trick for migrate.c and compile my own version and then redo my configuration to go back to treating things as a tape library again. I'm wondering if all the complication in my configuration is helping to crash the storage daemon or not. If it all goes well, I'll test some other scenarios and submit a patch for your consideration. > Regards, > > Kern Regards, ---------- Jim Barber DDI Health ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
