I am in the process of doing exactly this same thing but for a different reason.
If only a single job can access your storage at a time, then you should look for a "Maximum Concurrent Jobs" directive in your configuration files. You can find this in a number of different resources. So just grep for it and track down any resources that might be limiting the number of jobs writing concurrently to the same storage/device. Also be sure to check the manual on Maximum Concurrent Jobs directive for each resource. Even if you're not setting this anywhere, they have default values and there is at least one of these that is '1' by default. From your description, I would check specifically for a Maximum Concurrent Jobs directive set to '1' in the device resource of the storage daemon and/or in the storage resource of the storage daemon. I also thought about the different methods of migrating the data, but decided it wasn't worth doing. I have vchanger auto-create the new volumes with initmag. I then use Bacula's 'label barcodes' command to bulk label the empty volumes vchanger created. I tell the existing Bacula job to start using the new autochanger device but I keep the old volumes on disk until their files and jobs expire. When they do expire, I then remove the old volumes from disk and use 'delete volume' in Bacula. Once you've done that for all old volumes, you're completely migrated to vchanger. The reason I chose this method is that the data in these volumes can remain available for restores until their original job and file retention periods expire. Since you use the same job resource regardless of the storage device, you still get the same file and job retentions automatically applied to the files and jobs stored in the older volumes. This continues to clean your database and allows your backups to continue in the way you want. And of course, you only have minimal work to clean up the old volumes and files. If you have a retention period of a year or less and are not moving large amounts of changed data per night, this is probably a good option for you. If your backups have retention periods in the years and are moving large amounts of changed data per night, this will still work for you, but may not be the best option. Eric On Sun, Aug 7, 2011 at 1:51 AM, Adrian Reyer <bacula-li...@lihas.de> wrote: > Hi, > > my VirtualFull backups keep failing on me as I have many of them. They > run from 2 different File Pools and target 1 autochanger Tape library. > No matter how many concurrent jobs I declare and despite I activate > Spool Data and it actually does the spooling, only a single job can > access a singel File storage at a time. So now one job waits for the > autochanger while the other waits for the File and so they are in a > deadlock. > The idea is now to just use the vchanger and provide multiple File > drives to bacula to get rid of the issue. Obviously the File-Volumes are > already written and labeled and the naming is incompatibe to the > vchanger-names. > - Is there a different way to solve this deadlock situation permanently, > even if the jobs have to wait some time after being scheduled because of > other jobs blocking the devices? > - Is there an easy way to make the current File volumes known to the > vchanger and Bacula? > The current approach would be to stop bacula, move and rename the > files and update the occurances of the File names in Job and Media > tables. > > Regards, > Adrian > -- > LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart > Fon: +49 (7 11) 78 28 50 90 - Fax: +49 (7 11) 78 28 50 91 > Mail: li...@lihas.de - Web: http://lihas.de > Linux, Netzwerke, Consulting & Support - USt-ID: DE 227 816 626 Stuttgart > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users