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 > [EMAIL PROTECTED] > 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
