Hello.

First of all thank you for your answer.

"Fahrer, Julian" <julian AT fahrer DOT net> writes:

> Hey,
>
> Afaik one storage device can't open 2 volumes from the same pool. So
> u can use the same device, but u need different pools for your
> normal and virtualfull backups.  You need that for a working
> virtulfull anyway. Have a look at how copy and migrate jobs work. A
> lot of stuff is explained in that part of the manual. Hope this
> helps u.

Hmm, testing in a virtual machine (still with 3.0.2) deadlocked when
trying to read and write from the same device using different pools.
Also, the "New Features in 3.0.0" section in the Concepts and Overview
Guide[1] explicitly states

,----
| Note, this means that usually the output from the Virtual Backup is
| written into a different pool from where your prior backups are
| saved. Doing it this way guarantees that you will not get a deadlock
| situation attempting to read and write to the same volume in the
| Storage daemon. If you then want to do subsequent backups, you may
| need to move the Virtual Full Volume back to your normal backup
| pool. Alternatively, you can set your Next Pool to point to the
| current pool. This will cause Bacula to read and write to Volumes in
| the current pool. In general, this will work, because Bacula will
| not allow reading and writing on the same Volume.
`----

so this led me to believe that you could do what it says and use the
same pool.  Especially as I set "Maximum Volume Jobs = 1".  It also
says that I need to move the VirtualFull into my regular pool if I
create it in another pool.  This would (I guess) be done either by a
migration job or by using the console's update volume command.  Both
of these have serious disadvantages in disk space usage as I see it:

 * Using a migration job would mean that I need double the space (one
   time in the VirtualFull pool which is read and one time in the
   regular pool which is written).

 * Using the update volume command would mean that every time I do a
   VirtuallFull new volumes will be created in the VirtualFull pool
   and moved into the regular pool which thus grows indefinitely.  I
   can also not figure out how to move volumes automatically
   (scripted).  I could intervene manually, of course, but would love
   to avoid doing this as it tends to be forgotten, is error-prone and
   highly annoying.

That is the reason I want to use the same pool.  I believe the
intention of the authors of the feature is that it is possible because
it is highly useful and convenient in this way.  Or is there another
way to automatically move volumes to other pools which doesn't use
more disk space as using the same pool for VirtualBackup?

Regards,
Tobias


[1]http://www.bacula.org/manuals/en/concepts/concepts/New_Features_in_3_0_0.html#SECTION00570000000000000000

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