Bacula-users

[Bacula-users] Virtual backup

2008-09-03 05:39:13
Subject: [Bacula-users] Virtual backup
From: Kern Sibbald <kern AT sibbald DOT com>
To: "bacula-devel" <bacula-devel AT lists.sourceforge DOT net>
Date: Wed, 3 Sep 2008 11:37:57 +0200
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