Hello James,

On Friday 05 June 2009 20:58:18 James Harper wrote:
> I've had a bit more of a think about the virtual full backup problem I
> posted about previously. Basically, the problem (for me) is that the
> current implementation is designed to create a new full backup out of
> previous full+diff+inc backups, and assumes that the new backup will
> remain accessible. 

Yes, that is exactly what it is designed to do.

> What I (and several others) want to do is keep the 
> new virtual backup offsite. It doesn't work that way though - the first
> virtual backup is okay, but the next one wants to use the most recent
> full backup as the source, which is now offsite.

What you are doing is trying to force this feature to do something it is not 
meant to do.  A Virtual Full is supposed to be *identical* to a normal backup.  
If you think of it that way, things will work much better.

We already have a solution for what you want.  I've mentioned it before.  
Please try it.  It is called a Copy job and the purpose is to make a copy for 
offsite or archival purposes.  Until you have tried Copy and made appropriate 
comments on it, I don't even want to consider changes to Virtual Full (at least 
not of the kind mentioned in this email).  

Since Copy is on its first cut, we have plenty of room for making improvements 
and changes in it.

>
> So in my setup I have a pool per client, and a pool for tapes. Each
> client pool has the 'tape' pool set as the 'next pool'. I do a full
> backup at 9pm on Saturdays, and Incremental backups at 12pm, 3pm, and
> 9pm every day (except at 9pm on Saturday). Each night at 9pm virtual
> full backup is done to tape (but scheduled so that it doesn't start
> until the incrementals are finished) so that I have a single offsite
> full backup for disaster recovery purposes in the event of a total loss
> of the server room, but can still restore with fairly fine granularity
> any time for the last three weeks, and then even further back from the
> offsite tapes.
>
> The patch I have come up with says "when doing a virtual full backup,
> only consider backups _not_ in the 'next pool' as possible sources".

I don't think this is what most people will want.  In any case, until you have 
tried Copy jobs, I prefer to put this on hold.

> This works great for me, but I understand that it will break the
> previous behaviour which other users may be relying on (although I don't
> quite understand how the existing behaviour doesn't result in a
> deadlock).

It doesn't result in a deadlock because I did some clever programming in the SD 
:-)

>
> I understand that the 'next pool' thing is a bit of a hack, and will
> ultimately probably go away and be replaced by a more flexible solution,
> but in the meantime I'd like to come up with a solution that could go
> into the main tree. My current idea is to create a new backup level of
> 'synthetic' (or maybe 'syntheticfull'), which uses my 'next pool
> exclusion' patch but is otherwise identical to the current 'virtualfull'
> backup level. 'L_VIRTUAL_FULL' occurs on 12 lines in the bacula sources
> so it wouldn't be too invasive as a patch.

Yes, I am not too happy with Next Pool.  It seems to complicate things, so if 
you have any ideas.  Bacula is starting to get too complicated so I really 
would like to avoid things such as Synthetic Full having a very subtle 
difference from Virtual Full -- especially because Synthetic Full means the 
same thing as Virtual Full in other products.

>
> Comments?

Explain why Copy does not do the job ...

Kern
>
> Thanks
>
> James
>
> ---------------------------------------------------------------------------
>--- OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization. Go to:
> http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Bacula-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bacula-devel


------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to