All, a couple of things: There doesn't seem to be an official definition of GFS, but the most popular explanation to be found involves Full/0 backups on Friday and incremental/differentials on Monday through Thursday. That's great for 9-5 office environments, but what about data centers?
It's very hard to find explanations/examples that involve a 7-day cycle, and specifically how off-site tape rotation (and retention) policies integrates with GFS style backups cycles. 1) Can I get a testimony from someone who is actively using a GFS schedule with Bacula? Per the section "A Daily, Weekly, Monthly Tape Usage Example" in the manual? 1a) The standard GFS system could be modified to permit weekend backups ....performing a Full/0 backup on Sunday instead of Friday? Just add two tapes and find a data storage service that delivers on Weekends? 2) Generally speaking, off-site tape rotation occurs from "copies" of Level 0/Full backups? Off site storage can happen weekly, monthly, or quarterly. Quarterly and Monthly meant for non-recycled "permanent" off-site storage, and weekly meant for facility destruction contingency plans? But how is that commonly accomplished most frequently in practice? Weekly (Father) off-site copies simply a rotation through a 5 tape (for a 1-month retention policy) "Pool"? Or is it more common to leave the weekly/full tape at the facility and *duplicate* the Weekly/Full after it has finished running? How would that work with Monthly (Grandfather)? After all, a monthly (Grandfather) would simply be an "extra" or "second copy" of the Weekly Full/Level0 moved off-site with the regular copy, but only if it's the last Friday/Week of the month? Are there provisions in Bacula for "in-line" duplication of full tapes? Multiplexing? I.e., spool the data from the client once, write it twice, one to the weekly Full/Level 0 left on site, one to the off-site copy? (Would the Catalog have duplicate entries?) Or is this a process normally done manually using two tape drives? Using dd(1) perhaps? I see the docs btape/bscan. I assume this means that there is no way of telling Bacula about multiple copies of data on different tape members in different volumes. Thus it is the responsibility of the administrator to keep track of which tapes are on/off site for weekly replication/off site storage. A mapping must be kept between the volume IDs of the on/off-site copies. --------- Here's where it gets complicated with off-site storage / GFS integration. Duplication scenario: - At any given time, there are 4 of 5 tapes in my "Weekly" Pool off-site. - The on-site member tape sits in the changer and gets written/duplicated with the Full/level0. - The Full/Level0 backup occurs, gets multiplexed to both tapes *or* manually duplicated afterward. - I arrange/move of the duplicate to off-site storage immediately after it is written. - At the same time, the next tape from the weekly pool is delivered (It is 4 weeks old, it sits idle next to "current" Full/Level0) - With this method, I have a "current" Full/Level 0 tape copy off-site to recovery to a DR site with any time between then and the next full backup. - I also have the a copy of the "current" Full/Level 0 tape copy on-site for to recover from. - The worst case scenario is a disaster on the day before the next Full backup. If I have to recovery data to a DR site, the max age is 6-7 days old. Non-Duplication scenario: - At any given time, there are 4 of 5 tapes in my "weekly" Pool off-site. - The on-site tape sits in the changer and gets written/duplicated with the Full/Level0 job. - That tape must be kept-on site until the next Full/Level0 to permit for recovery from itself plus any incremental tape dependencies between the last Full/Level0. - Before the next Full/Level0 is written, the next member tape in the pool must be delivered and the exchanged with the current one. - With this method, there is no "current" off-site backup. Your "newest" or "most-current" off-site "Full/Level0" is at any given time at least 7 days old *plus* the number of days in incremental since (as many as 12/13 days old). ~lava
smime.p7s
Description: S/MIME cryptographic signature
