On 06/01/2011 17:16, Graham Keeling wrote:
> On Thu, Jan 06, 2011 at 05:02:47PM +0000, Mister IT Guru wrote:
>> I've been trying to get my head around virtual full backups.
>>
>> Now, from my understanding, (i'm 80% through my work day, shut down 20
>> tickets, and had to deal with too many user incidents for my liking, so
>> please bare with me if I say something stupid!), virtual fulls can be
>> run on the same pool as a real 'recent' full has been run on, and it
>> will create a new full based on all the latest files still in the pool.
>> It then takes these files, and only take the latest changed files, from
>> the client to create a new usable full backup, which should pretty much
>> take the same time as between and incremental and a differential.
>>
>> If this is the case, then I can slash my backup times, from 5 hours per
>> host, to around 20 minutes, which is something I think would be pretty
>> frikkin' awesome! Feel free to comment, and suggest :)
> No, it doesn't take the latest files from the client.
>
> It would solve a couple of problems that I have if that is what it did though.
>
> A VirtualFull combines previous backups into a single backup that is
> equivalent to a Full.
>
> So, if you have a schedule like this:
>
> Monday:    Incremental
> Tuesday:   Incremental
> Wednesday: Incremental
> Thursday:  Incremental
> Friday:    Incremental
> Saturday:  Incremental
> Sunday:    Incremental
>
> You can't, say, just do this:
>
> Monday:    Incremental
> Tuesday:   Incremental
> Wednesday: Incremental
> Thursday:  VirtualFull
> Friday:    Incremental
> Saturday:  Incremental
> Sunday:    Incremental
>
> You actually have to do this, otherwise you don't get a backup for that day:
>
> Monday:    Incremental
> Tuesday:   Incremental
> Wednesday: Incremental
> Thursday:  VirtualFull plus seperate Incremental
> Friday:    Incremental
> Saturday:  Incremental
> Sunday:    Incremental
>
> And that means that you get into problems with the VirtualFull and Incremental
> overlapping and getting in each other's way.
>
> With my configuration, a VirtualFull sometimes prevents an Incremental from
> running, because the VirtualFull took too long (or vice versa). I have not 
> been
> able to solve this, because every idea that I've come up with either doesn't
> work or makes something else happen that is worse.
>
> So, I would be very pleased if a VirtualFull also grabbed new files from the
> client.
>
Thank you for pointing this out! So it doesn't grab new files from the 
client first? Well, that's not the smartest! Hmm, I wonder - How would 
you get a job to run run after another job, rather than have bacula 
decide via priorities?

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users