4 \section*{Backup Strategies}
6 \index[general]{Strategies!Backup }
7 \index[general]{Backup Strategies }
8 \addcontentsline{toc}{section}{Backup Strategies}
10 Although Recycling and Backing Up to Disk Volume have been discussed in
11 previous chapters, this chapter is meant to give you an overall view of
12 possible backup strategies and to explain their advantages and disadvantages.
15 \subsection*{Simple One Tape Backup}
16 \index[general]{Backup!Simple One Tape }
17 \index[general]{Simple One Tape Backup }
18 \addcontentsline{toc}{subsection}{Simple One Tape Backup}
20 Probably the simplest strategy is to back everything up to a single tape and
21 insert a new (or recycled) tape when it fills and Bacula requests a new one.
23 \subsubsection*{Advantages}
24 \index[general]{Advantages }
25 \addcontentsline{toc}{subsubsection}{Advantages}
28 \item The operator intervenes only when a tape change is needed. (once a
30 \item There is little chance of operator error because the tape is not
32 \item A minimum number of tapes will be needed for a full restore. Typically
33 the best case will be one tape and worst two.
34 \item You can easily arrange for the Full backup to occur a different night
35 of the month for each system, thus load balancing and shortening the backup
39 \subsubsection*{Disadvantages}
40 \index[general]{Disadvantages }
41 \addcontentsline{toc}{subsubsection}{Disadvantages}
44 \item If your site burns down, you will lose your current backups, and in my
45 case about a month of data.
46 \item After a tape fills and you have put in a blank tape, the backup will
47 continue, and this will generally happen during working hours.
50 \subsubsection*{Practical Details}
51 \index[general]{Details!Practical }
52 \index[general]{Practical Details }
53 \addcontentsline{toc}{subsubsection}{Practical Details}
55 This system is very simple. When the tape fills and Bacula requests a new
56 tape, you {\bf unmount} the tape from the Console program, insert a new tape
57 and {\bf label} it. In most cases after the label, Bacula will automatically
58 mount the tape and resume the backup. Otherwise, you simply {\bf mount} the
61 Using this strategy, one typically does a Full backup once a week followed by
62 daily Incremental backups. To minimize the amount of data written to the tape,
63 one can do (as I do) a Full backup once a month on the first Sunday of the
64 month, a Differential backup on the 2nd-5th Sunday of the month, and
65 incremental backups the rest of the week.
68 \subsection*{Manually Changing Tapes}
69 \index[general]{Tapes!Manually Changing }
70 \index[general]{Manually Changing Tapes }
71 \addcontentsline{toc}{subsection}{Manually Changing Tapes}
73 If you use the strategy presented above, Bacula will ask you to change the
74 tape, and you will {\bf unmount} it and then remount it when you have inserted
77 If you do not wish to interact with Bacula to change each tape, there are
78 several ways to get Bacula to release the tape:
81 \item In your Storage daemon's Device resource, set
83 In this case, Bacula will release the tape after every job. If you run
84 several jobs, the tape will be rewound and repositioned to the end at the
85 beginning of every job. This is not very efficient, but does let you change
86 the tape whenever you want.
87 \item Use a {\bf RunAfterJob} statement to run a script after your last job.
88 This could also be an {\bf Admin} job that runs after all your backup jobs.
89 The script could be something like:
94 /full-path/console -c /full-path/console.conf <<END_OF_DATA
95 release storage=your-storage-name
101 In this example, you would have {\bf AlwaysOpen=yes}, but the {\bf release}
102 command would tell Bacula to rewind the tape and on the next job assume the
103 tape has changed. This strategy may not work on some systems, or on
104 autochangers because Bacula will still keep the drive open.
105 \item The final strategy is similar to the previous case except that you
106 would use the unmount command to force Bacula to release the drive. Then you
107 would eject the tape, and remount it as follows:
112 /full-path/console -c /full-path/console.conf <\<END_OF_DATA
113 unmount storage=your-storage-name
115 # the following is a shell command
117 /full-path/console -c /full-path/console.conf <<END_OF_DATA
118 mount storage=your-storage-name
128 \subsection*{Daily Tape Rotation}
129 \index[general]{Rotation!Daily Tape }
130 \index[general]{Daily Tape Rotation }
131 \addcontentsline{toc}{subsection}{Daily Tape Rotation}
133 This scheme is quite different from the one mentioned above in that a Full
134 backup is done to a different tape every day of the week. Generally, the
135 backup will cycle continuously through 5 or 6 tapes each week. Variations are
136 to use a different tape each Friday, and possibly at the beginning of the
137 month. Thus if backups are done Monday through Friday only, you need only 5
138 tapes, and by having two Friday tapes, you need a total of 6 tapes. Many sites
139 run this way, or using modifications of it based on two week cycles or longer.
142 \subsubsection*{Advantages}
143 \index[general]{Advantages }
144 \addcontentsline{toc}{subsubsection}{Advantages}
147 \item All the data is stored on a single tape, so recoveries are simple and
149 \item Assuming the previous day's tape is taken offsite each day, a maximum
150 of one days data will be lost if the site burns down.
153 \subsubsection*{Disadvantages}
154 \index[general]{Disadvantages }
155 \addcontentsline{toc}{subsubsection}{Disadvantages}
158 \item The tape must be changed every day requiring a lot of operator
160 \item More errors will occur because of human mistakes.
161 \item If the wrong tape is inadvertently mounted, the Backup for that day
162 will not occur exposing the system to data loss.
163 \item There is much more movement of the tape each day (rewinds) leading to
164 shorter tape drive life time.
165 \item Initial setup of Bacula to run in this mode is more complicated than
166 the Single tape system described above.
167 \item Depending on the number of systems you have and their data capacity, it
168 may not be possible to do a Full backup every night for time reasons or
169 reasons of tape capacity.
172 \subsubsection*{Practical Details}
173 \index[general]{Details!Practical }
174 \index[general]{Practical Details }
175 \addcontentsline{toc}{subsubsection}{Practical Details}
177 The simplest way to "force" Bacula to use a different tape each day is to
178 define a different Pool for each day of the the week a backup is done. In
179 addition, you will need to specify appropriate Job and File retention periods
180 so that Bacula will relabel and overwrite the tape each week rather than
181 appending to it. Nic Bellamy has supplied an actual working model of this
182 which we include here.
184 What is important is to create a different Pool for each day of the week, and
185 on the {\bf run} statement in the Schedule, to specify which Pool is to be
186 used. He has one Schedule that accomplishes this, and a second Schedule that
187 does the same thing for the Catalog backup run each day after the main backup
188 (Priorities were not available when this script was written). In addition, he
189 uses a {\bf Max Start Delay} of 22 hours so that if the wrong tape is
190 premounted by the operator, the job will be automatically canceled, and the
191 backup cycle will re-synchronize the next day. He has named his Friday Pool
192 {\bf WeeklyPool} because in that Pool, he wishes to have several tapes to be
193 able to restore to a time older than one week.
195 And finally, in his Storage daemon's Device resource, he has {\bf Automatic
196 Mount = yes} and {\bf Always Open = No}. This is necessary for the tape
197 ejection to work in his {\bf end\_of\_backup.sh} script below.
199 For example, his bacula-dir.conf file looks like the following:
204 # /etc/bacula/bacula-dir.conf
206 # Bacula Director Configuration file
211 QueryFile = "/etc/bacula/query.sql"
212 WorkingDirectory = "/var/lib/bacula"
213 PidDirectory = "/var/run"
214 SubSysDirectory = "/var/lock/subsys"
215 Maximum Concurrent Jobs = 1
216 Password = "console-pass"
220 # Define the main nightly save backup job
227 Schedule = "WeeklyCycle"
231 Write Bootstrap = "/var/lib/bacula/NightlySave.bsr"
232 Max Start Delay = 22h
234 # Backup the catalog database (after the nightly save)
236 Name = "BackupCatalog"
240 Schedule = "WeeklyCycleAfterBackup"
244 # This creates an ASCII copy of the catalog
245 RunBeforeJob = "/usr/lib/bacula/make_catalog_backup -u bacula"
246 # This deletes the copy of the catalog, and ejects the tape
247 RunAfterJob = "/etc/bacula/end_of_backup.sh"
248 Write Bootstrap = "/var/lib/bacula/BackupCatalog.bsr"
249 Max Start Delay = 22h
251 # Standard Restore template, changed by Console program
253 Name = "RestoreFiles"
260 Where = /tmp/bacula-restores
262 # List of files to be backed up
265 Include = signature=MD5 {
269 Exclude = { /proc /tmp /.journal }
272 # When to do the backups
276 Run = Level=Full Pool=MondayPool Monday at 8:00pm
277 Run = Level=Full Pool=TuesdayPool Tuesday at 8:00pm
278 Run = Level=Full Pool=WednesdayPool Wednesday at 8:00pm
279 Run = Level=Full Pool=ThursdayPool Thursday at 8:00pm
280 Run = Level=Full Pool=WeeklyPool Friday at 8:00pm
282 # This does the catalog. It starts after the WeeklyCycle
284 Name = "WeeklyCycleAfterBackup"
285 Run = Level=Full Pool=MondayPool Monday at 8:15pm
286 Run = Level=Full Pool=TuesdayPool Tuesday at 8:15pm
287 Run = Level=Full Pool=WednesdayPool Wednesday at 8:15pm
288 Run = Level=Full Pool=ThursdayPool Thursday at 8:15pm
289 Run = Level=Full Pool=WeeklyPool Friday at 8:15pm
291 # This is the backup of the catalog
294 Include = signature=MD5 {
295 /var/lib/bacula/bacula.sql
298 # Client (File Services) to backup
304 Password = "client-pass"
309 # Definition of file storage device
314 Password = "storage-pass"
318 # Generic catalog service
321 dbname = bacula; user = bacula; password = ""
323 # Reasonable message delivery -- send almost all to email address
327 mailcommand = "/usr/sbin/bsmtp -h localhost -f \"\(Bacula\) %r\"
328 -s \"Bacula: %t %e of %c %l\" %r"
329 operatorcommand = "/usr/sbin/bsmtp -h localhost -f \"\(Bacula\) %r\"
330 -s \"Bacula: Intervention needed for %j\" %r"
331 mail = root@localhost = all, !skipped
332 operator = root@localhost = mount
333 console = all, !skipped, !saved
334 append = "/var/lib/bacula/log" = all, !skipped
339 # Default Pool for jobs, but will hold no actual volumes
349 Volume Retention = 6d
350 Accept Any Volume = yes
351 Maximum Volume Jobs = 2
358 Volume Retention = 6d
359 Accept Any Volume = yes
360 Maximum Volume Jobs = 2
367 Volume Retention = 6d
368 Accept Any Volume = yes
369 Maximum Volume Jobs = 2
376 Volume Retention = 6d
377 Accept Any Volume = yes
378 Maximum Volume Jobs = 2
385 Volume Retention = 12d
386 Accept Any Volume = yes
387 Maximum Volume Jobs = 2
393 Note, the mailcommand and operatorcommand should be on a single line each.
394 They were split to preserve the proper page width. In order to get Bacula to
395 release the tape after the nightly backup, he uses a {\bf RunAfterJob} script
396 that deletes the ASCII copy of the database back and then rewinds and ejects
397 the tape. The following is a copy of {\bf end\_of\_backup.sh}
402 /usr/lib/bacula/delete_catalog_backup
409 Finally, if you list his Volumes, you get something like the following:
414 Using default Catalog name=MyCatalog DB=bacula
416 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
417 | MeId| VolumeName| MedTyp| VolStat| VolBytes | LastWritten | VolRet| Recyc|
418 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
419 | 5 | Friday_1 | MLR1 | Used | 2157171998| 2003-07-11 20:20| 103680| 1 |
420 | 6 | Friday_2 | MLR1 | Append | 0 | 0 | 103680| 1 |
421 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
423 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
424 | MeId| VolumeName| MedTyp| VolStat| VolBytes | LastWritten | VolRet| Recyc|
425 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
426 | 2 | Monday | MLR1 | Used | 2260942092| 2003-07-14 20:20| 518400| 1 |
427 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
429 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
430 | MeId| VolumeName| MedTyp| VolStat| VolBytes | LastWritten | VolRet| Recyc|
431 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
432 | 3 | Tuesday | MLR1 | Used | 2268180300| 2003-07-15 20:20| 518400| 1 |
433 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
435 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
436 | MeId| VolumeName| MedTyp| VolStat| VolBytes | LastWritten | VolRet| Recyc|
437 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
438 | 4 | Wednesday | MLR1 | Used | 2138871127| 2003-07-09 20:2 | 518400| 1 |
439 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
441 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
442 | MeId| VolumeName| MedTyp| VolStat| VolBytes | LastWritten | VolRet| Recyc|
443 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
444 | 1 | Thursday | MLR1 | Used | 2146276461| 2003-07-10 20:50| 518400| 1 |
445 +-----+-----------+-------+--------+-----------+-----------------+-------+------+
451 Note, I have truncated a number of the columns so that the information fits on