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-lists AT lihas DOT 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: lihas AT lihas DOT 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 AT lists.sourceforge DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
