4 \section*{Basic Volume Management}
5 \label{_ChapterStart39}
6 \index[general]{Basic Volume Management}
7 \index[general]{Management!Basic Volume}
8 \index[general]{Disk Volumes}
9 \addcontentsline{toc}{section}{Basic Volume Management}
11 This chapter presents most all the features needed to do Volume management.
12 Most of the concepts apply equally well to both tape and disk Volumes.
13 However, the chapter was originally written to explain backing up to disk, so
14 you will see it is slanted in that direction, but all the directives
15 presented here apply equally well whether your volume is disk or tape.
17 If you have a lot of hard disk storage or you absolutely must have your
18 backups run within a small time window, you may want to direct Bacula to
19 backup to disk Volumes rather than tape Volumes. This chapter is intended to
20 give you some of the options that are available to you so that you can manage
21 either disk or tape volumes.
24 \subsection*{Key Concepts and Resource Records}
25 \index[general]{Key Concepts and Resource Records }
26 \index[general]{Records!Key Concepts and Resource }
27 \addcontentsline{toc}{subsection}{Key Concepts and Resource Records}
29 Getting Bacula to write to disk rather than tape in the simplest case is
30 rather easy. In the Storage daemon's configuration file, you simply define an
31 {\bf Archive Device} to be a directory. For example, if you want your disk
32 backups to go into the directory {\bf /home/bacula/backups}, you could use the
40 Archive Device = /home/bacula/backups
49 Assuming you have the appropriate {\bf Storage} resource in your Director's
50 configuration file that references the above Device resource,
64 Bacula will then write the archive to the file {\bf
65 /home/bacula/backups/\lt{}volume-name\gt{}} where \lt{}volume-name\gt{} is the
66 volume name of a Volume defined in the Pool. For example, if you have labeled
67 a Volume named {\bf Vol001}, Bacula will write to the file {\bf
68 /home/bacula/backups/Vol001}. Although you can later move the archive file to
69 another directory, you should not rename it or it will become unreadable by
70 Bacula. This is because each archive has the filename as part of the internal
71 label, and the internal label must agree with the system filename before
74 Although this is quite simple, there are a number of problems. The first is
75 that unless you specify otherwise, Bacula will always write to the same volume
76 until you run out of disk space. This problem is addressed below.
78 \subsubsection*{Pool Options to Limit the Volume Usage}
79 \index[general]{Usage!Pool Options to Limit the Volume }
80 \index[general]{Pool Options to Limit the Volume Usage }
81 \addcontentsline{toc}{subsubsection}{Pool Options to Limit the Volume Usage}
83 Some of the options you have, all of which are specified in the Pool record,
87 \item To write each Volume only once (i.e. one Job per Volume or file in this
90 {\bf UseVolumeOnce = yes}.
91 \item To write nnn Jobs to each Volume, use:
93 {\bf Maximum Volume Jobs = nnn}.
94 \item To limit the maximum size of each Volume, use:
96 {\bf Maximum Volume Bytes = mmmm}.
97 \item To limit the use time (i.e. write the Volume for a maximum of 5 days),
100 {\bf Volume Use Duration = ttt}.
103 Note that although you probably would not want to limit the number of bytes on
104 a tape as you would on a disk Volume, the other options can be very useful in
105 limiting the time Bacula will use a particular Volume (be it tape or disk).
106 For example, the above directives can allow you to ensure that you rotate
107 through a set of daily Volumes if you wish.
109 As mentioned above, each of those directives is specified in the Pool or
110 Pools that you use for your Volumes. In the case of {\bf Maximum Volume Job},
111 {\bf Maximum Volume Bytes}, and {\bf Volume Use Duration}, you can actually
112 specify the desired value on a Volume by Volume basis. The value specified in
113 the Pool record becomes the default when labeling new Volumes. Once a Volume
114 has been created, it gets its own copy of the Pool defaults, and subsequently
115 changing the Pool will have no effect on existing Volumes. You can either
116 manually change the Volume values, or refresh them from the Pool defaults using
117 the {\bf update volume} command in the Console. As an example
118 of the use of one of the above, suppose your Pool resource contains:
125 Volume Use Duration = 23h
130 then if you run a backup once a day (every 24 hours), Bacula will use a new
131 Volume for each backup, because each Volume it writes can only be used for 23 hours
132 after the first write. Note, setting the use duration to 23 hours is not a very
133 good solution for tapes unless you have someone on-site during the weekends,
134 because Bacula will want a new Volume and no one will be present to mount it,
135 so no weekend backups will be done until Monday morning.
137 \label{AutomaticLabeling}
138 \subsubsection*{Automatic Volume Labeling}
139 \index[general]{Automatic Volume Labeling }
140 \index[general]{Labeling!Automatic Volume }
141 \addcontentsline{toc}{subsubsection}{Automatic Volume Labeling}
143 Use of the above records brings up another problem -- that of labeling your
144 Volumes. For automated disk backup, you can either manually label each of your
145 Volumes, or you can have Bacula automatically label new Volumes when they are
146 needed. While, the automatic Volume labeling in version 1.30 and prior is a
147 bit simplistic, but it does allow for automation, the features added in
148 version 1.31 permit automatic creation of a wide variety of labels including
149 information from environment variables and special Bacula Counter variables.
150 In version 1.37 and later, it is probably much better to use Python scripting
151 and the NewVolume event since generating Volume labels in a Python script is
152 much easier than trying to figure out Counter variables. See the
153 \ilink{Python Scripting}{_ChapterStart60} chapter of this manual for more
156 Please note that automatic Volume labeling can also be used with tapes, but it is not
157 nearly so practical since the tapes must be pre-mounted. This requires some
158 user interaction. Automatic labeling from templates does NOT work with
159 autochangers since Bacula will not access unknown slots. There are several
160 methods of labeling all volumes in an autochanger magazine. For more
161 information on this, please see the
162 \ilink{ Autochanger}{_ChapterStart18} chapter of this manual.
164 Automatic Volume labeling is enabled by making a change to both the Pool
165 resource (Director) and to the Device resource (Storage daemon) shown above.
166 In the case of the Pool resource, you must provide Bacula with a label format
167 that it will use to create new names. In the simplest form, the label format
168 is simply the Volume name, to which Bacula will append a four digit number.
169 This number starts at 0001 and is incremented for each Volume the pool
170 contains. Thus if you modify your Pool resource to be:
177 Volume Use Duration = 23h
183 Bacula will create Volume names Vol0001, Vol0002, and so on when new Volumes
184 are needed. Much more complex and elaborate labels can be created using
185 variable expansion defined in the
186 \ilink{Variable Expansion}{_ChapterStart50} chapter of this manual.
188 The second change that is necessary to make automatic labeling work is to give
189 the Storage daemon permission to automatically label Volumes. Do so by adding
190 {\bf LabelMedia = yes} to the Device resource as follows:
197 Archive Device = /home/bacula/backups
199 AutomaticMount = yes;
207 You can find more details of the {\bf Label Format} Pool record in
208 \ilink{Label Format}{Label} description of the Pool resource
212 \subsubsection*{Restricting the Number of Volumes and Recycling}
213 \index[general]{Recycling!Restricting the Number of Volumes and }
214 \index[general]{Restricting the Number of Volumes and Recycling }
215 \addcontentsline{toc}{subsubsection}{Restricting the Number of Volumes and
218 Automatic labeling discussed above brings up the problem of Volume management.
219 With the above scheme, a new Volume will be created every day. If you have not
220 specified Retention periods, your Catalog will continue to fill keeping track
221 of all the files Bacula has backed up, and this procedure will create one new
222 archive file (Volume) every day.
224 The tools Bacula gives you to help automatically manage these problems are the
228 \item Catalog file record retention periods, the
229 \ilink{File Retention = ttt}{FileRetention} record in the Client
231 \item Catalog job record retention periods, the
232 \ilink{Job Retention = ttt}{JobRetention} record in the Client
235 \ilink{ AutoPrune = yes}{AutoPrune} record in the Client resource
236 to permit application of the above two retention periods.
238 \ilink{ Volume Retention = ttt}{VolRetention} record in the Pool
241 \ilink{ AutoPrune = yes}{PoolAutoPrune} record in the Pool
242 resource to permit application of the Volume retention period.
244 \ilink{ Recycle = yes}{PoolRecycle} record in the Pool resource
245 to permit automatic recycling of Volumes whose Volume retention period has
248 \ilink{ Recycle Oldest Volume = yes}{RecycleOldest} record in the
249 Pool resource tells Bacula to Prune the oldest volume in the Pool, and if all
250 files were pruned to recyle this volume and use it.
252 \ilink{ Recycle Current Volume = yes}{RecycleCurrent} record in
253 the Pool resource tells Bacula to Prune the currently mounted volume in the
254 Pool, and if all files were pruned to recyle this volume and use it.
256 \ilink{ Purge Oldest Volume = yes}{PurgeOldest} record in the
257 Pool resource permits a forced recycling of the oldest Volume when a new one
258 is needed. {\bf N.B. This record ignores retention periods! We highly
259 recommend not to use this record, but instead use Recycle Oldest Volume}
261 \ilink{ Maximum Volumes = nnn}{MaxVolumes} record in the Pool
262 resource to limit the number of Volumes that can be created.
265 The first three records (File Retention, Job Retention, and AutoPrune)
266 determine the amount of time that Job and File records will remain in your
267 Catalog, and they are discussed in detail in the
268 \ilink{Automatic Volume Recycling}{_ChapterStart22} chapter of
271 Volume Retention, AutoPrune, and Recycle determine how long Bacula will keep
272 your Volumes before reusing them, and they are also discussed in detail in the
273 \ilink{Automatic Volume Recycling}{_ChapterStart22} chapter of
276 The Maximum Volumes record can also be used in conjunction with the Volume
277 Retention period to limit the total number of archive Volumes (files) that
278 Bacula will create. By setting an appropriate Volume Retention period, a
279 Volume will be purged just before it is needed and thus Bacula can cycle
280 through a fixed set of Volumes. Cycling through a fixed set of Volumes can
281 also be done by setting {\bf Recycle Oldest Volume = yes} or {\bf Recycle
282 Current Volume = yes}. In this case, when Bacula needs a new Volume, it will
283 prune the specified volume.
286 \subsection*{An Example}
287 \index[general]{Example }
288 \addcontentsline{toc}{subsection}{Example}
290 The following example is not very practical, but can be used to demonstrate
291 the proof of concept in a relatively short period of time. The example
292 consists of a single client that is backed up to a set of 12 archive files
293 (Volumes). Each Volume is used (written) only once, and there are four Full
294 saves done every hour (so the whole thing cycles around after three hours).
296 The Director's configuration file is as follows:
302 QueryFile = "~/bacula/bin/query.sql"
303 PidDirectory = "~/bacula/working"
304 WorkingDirectory = "~/bacula/working"
305 Password = dir_password
309 Run = Level=Full Pool=Recycle Storage=File hourly at 0:05
310 Run = Level=Full Pool=Recycle Storage=File hourly at 0:20
311 Run = Level=Full Pool=Recycle Storage=File hourly at 0:35
312 Run = Level=Full Pool=Recycle Storage=File hourly at 0:50
315 Name = "RecycleExample"
319 FileSet= "Example FileSet"
321 Storage = FileStorage
323 Schedule = FourPerHour
326 Name = "Example FileSet"
327 Include = compression=GZIP signature=SHA1 {
328 /home/kern/bacula/bin
335 Password = client_password
340 Password = local_storage_password
346 dbname = bacula; user = bacula; password = ""
354 Use Volume Once = yes
365 and the Storage daemon's configuration file is:
371 WorkingDirectory = "~/bacula/working"
372 Pid Directory = "~/bacula/working"
373 MaximumConcurrentJobs = 10
377 Password = local_storage_password
382 Archive Device = /home/bacula/backups
385 AutomaticMount = yes;
391 director = my-dir = all
396 In this example, the Jobs will be backed up to directory {\bf
397 /home/bacula/backups} with Volume names Vol0001, Vol0002, ... Vol0012. Every
398 backup Job will write a new volume cycling through the volume numbers, and two
399 hours after a job has started, the volume will be pruned {\bf Volume Retention
402 With a little bit of work, you can change the above example into a weekly or
403 monthly cycle (take care about the amount of archive disk space used).
405 \label{MultipleDisks}
406 \subsection*{Backing up to Multiple Disks}
407 \index[general]{Disks!Backing up to Multiple }
408 \index[general]{Backing up to Multiple Disks }
409 \addcontentsline{toc}{subsection}{Backing up to Multiple Disks}
411 Bacula can, of course, use multiple disks, but in general, each disk must be a
412 separate Device specification in the Storage daemon's conf file, and you must
413 then select what clients to backup to each disk.
415 The situation is a bit more complicated if you want to treat two disk drives
416 logically as a single drive, which Bacula does not directly support. However,
417 it is possible to back up your data to multiple disks as if they were a single
418 drive by linking the Volumes from the first disk to the second disk.
420 For example, assume that you have two disks named {\bf /disk1} and {\bf
421 /disk2>}. If you then create a standard Storage daemon Device resource for
422 backing up to the first disk, it will look like the following:
429 Archive Device = /disk1
432 AutomaticMount = yes;
439 Since there is no way to get the above Device resource to reference both {\bf
440 /disk1} and {\bf /disk2} we do it by pre-creating Volumes on /disk2 with the
445 ln -s /disk2/Disk2-vol001 /disk1/Disk2-vol001
446 ln -s /disk2/Disk2-vol002 /disk1/Disk2-vol002
447 ln -s /disk2/Disk2-vol003 /disk1/Disk2-vol003
452 At this point, you can label the Volumes as Volume {\bf Disk2-vol001}, {\bf
453 Disk2-vol002}, ... and Bacula will use them as if they were on /disk1 but
454 actually write the data to /disk2. The only minor inconvenience with this
455 method is that you must explicitly name the disks and cannot use automatic
456 labeling unless you arrange to have the labels exactly match the links you
458 \label{MultipleClients}
460 \subsection*{Considerations for Multiple Clients}
461 \index[general]{Clients!Considerations for Multiple }
462 \index[general]{Considerations for Multiple Clients }
463 \addcontentsline{toc}{subsection}{Considerations for Multiple Clients}
465 If we take the above example and add a second Client, here are a few
469 \item Although the second client can write to the same set of Volumes, you
470 will probably want to write to a different set.
471 \item You can write to a different set of Volumes by defining a second Pool,
472 which has a different name and a different {\bf LabelFormat}.
473 \item If you wish the Volumes for the second client to go into a different
474 directory (perhaps even on a different filesystem to spread the load), you
475 would do so by defining a second Device resource in the Storage daemon. The
476 {\bf Name} must be different, and the {\bf Archive Device} could be
477 different. To ensure that Volumes are never mixed from one pool to another,
478 you might also define a different MediaType (e.g. {\bf File1}).
481 In this example, we have two clients, each with a different Pool and a
482 different number of archive files retained. They also write to different
483 directories with different Volume labeling.
485 The Director's configuration file is as follows:
491 QueryFile = "~/bacula/bin/query.sql"
492 PidDirectory = "~/bacula/working"
493 WorkingDirectory = "~/bacula/working"
494 Password = dir_password
496 # Basic weekly schedule
498 Name = "WeeklySchedule"
499 Run = Level=Full fri at 1:30
500 Run = Level=Incremental sat-thu at 1:30
503 Name = "Example FileSet"
504 Include = compression=GZIP signature=SHA1 {
505 /home/kern/bacula/bin
509 Name = "Backup-client1"
513 FileSet= "Example FileSet"
517 Schedule = "WeeklySchedule"
520 Name = "Backup-client2"
524 FileSet= "Example FileSet"
528 Schedule = "WeeklySchedule"
534 Password = client1_password
541 Password = client2_password
543 # Two Storage definitions permits different directories
547 Password = local_storage_password
554 Password = local_storage_password
560 dbname = bacula; user = bacula; password = ""
566 # Two pools permits different cycling periods and Volume names
567 # Cycle through 15 Volumes (two weeks)
570 Use Volume Once = yes
572 LabelFormat = "Client1-"
574 VolumeRetention = 13d
578 # Cycle through 8 Volumes (1 week)
581 Use Volume Once = yes
583 LabelFormat = "Client2-"
592 and the Storage daemon's configuration file is:
598 WorkingDirectory = "~/bacula/working"
599 Pid Directory = "~/bacula/working"
600 MaximumConcurrentJobs = 10
604 Password = local_storage_password
606 # Archive directory for Client1
610 Archive Device = /home/bacula/client1
613 AutomaticMount = yes;
617 # Archive directory for Client2
621 Archive Device = /home/bacula/client2
624 AutomaticMount = yes;
630 director = my-dir = all