Hi Kern,

can't you use something like data spooling for this?

First step: Make a virtFull to a temp spool file on disk
Second step: Spool this to the destination

regards
Michael


Kern Sibbald wrote:
> 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