Mgr. Martin Fabuš wrote: > >> I don't think that will do what you want. The reason for 4 pools is to >> keep the incrementals on drive 1 relative to the fulls on drive 1, and >> the incrementals on drive 2 relative to the fulls on drive 2. If you >> have only 2 pools, then the incrementals will be relative to the last >> full backup, regardless of which drive the last full backup was written >> to. Similarly, the reason for 2 jobs for each client is because one job >> writes only to disk 1 and the other only to disk 2. That way a restore >> will only require 1 drive. >> > > I have created: > > * 2 jobs > o odd weeks > o even weeks > * 2 pools > o odd weeks - HDD 1 > o even weeks - HDD 2 > * 2 schedules > o odd weeks > o even weeks > > > in the schedules I'm specifieing which pool to use. > > All the rules are quiete strict, so even after reading your email I > think this should work correctly, i.e.: > The increments collected on odd weeks will always go only to the > odd pool HDD1 and (because of the 2 different jobs) should relate > correctly to the odd full backup. (similiarly with the even ones) > > Am I right? > > M
I think you are right. Volumes on HDD 1 will be in one pool and volumes on HDD 2 in another. For each client, there will be a full backup in both pools created by manually running level=full jobs. The schedules will automatically run daily backups, odd weeks storing into volumes in one pool and even weeks into the other pool. Normally, I would probably use 4 pools, divided into fulls on HDD 1, incrementals on HDD 1, fulls on HDD 2, and incrementals on HDD 2. This would be primarily to have different retention times for the incrementals and fulls. In your case, though, the incrementals need to be retained as long as the fulls. I don't think with your setup you will even make use of automatic recycling. To re-use a drive you will just manually delete all of it's volumes and start over with new manually run full backups. Right? ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
