On Thu, Jan 06, 2011 at 05:24:07PM +0000, Mister IT Guru wrote:
> 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?
I don't know, but I think that your idea of combining them both into one job
is a far better solution.
------------------------------------------------------------------------------
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
|
