Hello Kern,
thanks one more time for your work.
I am trying to contribute to this discussion, even if I am sure that my
knowledge is too weak.
In my opinion you should allow to set a Next Pool also in a Virtual Backup
pool (maybe also for Migration or Copy pool). This could be managed in a
number of ways, i.e. you could set the Next Pool of the third pool to the
second one, thus alternating the destination pools of the virtual backup.
After the backup virtualization the source pools could be purged to make
room for the next run.
Best regards,
--------------------------------------------------------------------------
Ferdinando Pasqualetti
G.T.Dati srl
Tel. 0557310862 - 3356172731 - Fax 055720143
bacula-users-bounces AT lists.sourceforge DOT net wrote on 03/09/2008 11.37.57:
> Hello,
>
> As many of you know Virtual Backup (consolidation, synthetic full, ...)
is a
> new feature that is implemented in the development trunk and scheduled
to be
> released later this year. It essentially copies what would be a "full
> current" restore to a new Volume thus creating an virtual backup that
can
> serve as a Full backup. This has a lot of advantages, particularly for
sites
> with full backups that run long times or for remote sites where the time
to
> transmit a full backup is excessive.
>
> The Virtual Backup feature works much like Migration and Copy. It reads
from
> the required Volumes and writes to a Volume specified in the pool as
"Next
> Pool". This ensures that the read and write Volumes are different.
>
> Everything seems to work fine with the Virtual Backup. However,
thinking
> about longer term operations, it has occurred to me that when you want
to
> make a second Virtual Backup things will become very complicated. First,
the
> Virtual backup will want to read the previous Virtual backup volume,and
then
> if that Volume is not full, it will want to write to the same Volume.
Even
> if the volume is full, you will be in a situation where the Job will
want to
> read and write to volumes in the same pool. In all those cases, there
is no
> guarantee that there will not be a deadlock situation (actually Bacula
> currently cancels any job attempting to read and write from the same
Storage
> device).
>
> I am not 100% sure what to do to resolve this issue. I suppose one
could run
> a Migration job to "move" the Virtual Backup back to the Pool from which
it
> originally came, then the next Virtual Backup would work fine (the same
as
> the first one), but that sounds a bit kludgie.
>
> If anyone has any suggestions, I would appreciate to hear them. However,
> suggestions that require implementing significant amounts of code or
complex
> new algorithms such as deadlock detection won't be very helpful since
there
> is no time left to do such implementations between now and release time.
In
> addition, deadlock detection won't help, what we really need is deadlock
> resolution, and that is an even more difficult subject.
>
> Best regards,
>
> Kern
>
>
>
-------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
