Mgr. Martin Fabuš wrote: > >> You could probably do this with 4 pools. Each drive would contain >> volumes in two pools, one for full backups and one for incremental >> backups. For each client there would be two jobs, one backing up to >> drive 1 using pools "full1" and "incremental1" and another backing up to >> drive 2 using pools "full2" and "incremental2". The two jobs for each >> client would use two different schedules so that the jobs run on >> opposite weeks. A schedule for odd weeks of the month might use >> something like Run = Level=Incremental 1st,3rd,5th sun-sat at 21:00. >> Only schedule the daily incrementals, and then run the yearly full >> backups manually. >> > Good idea, that's exactly what I was looking for. I have implemented > it as You have suggested. I will see if it will work. > I have created only 2 pools - full and increments are going to a one pool. > EvenPool & OddPool
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. > > >> A year sounds like a long time between full backups. With 180 odd >> incrementals for each client you'll likely run out of disk space on a >> USB drive and defeat the purpose. With differential backups run every >> now and then, you could delete the no longer needed incrementals and >> consolidate space. >> > The disks are real 3,5" 0,5 TB, so it won't get full so easy. The USB > is used only for connecting the HDDs to a SD server. > > As long as I have 2 equal HDDs, I think the increments are at safe > place - Data are on 3 places (original, even backup and odd backup). > > M > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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