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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
