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
157 it is not nearly so practical since the tapes must be pre-mounted. This
158 requires some user interaction. Automatic labeling from templates does NOT
159 work with autochangers since Bacula will not access unknown slots. There
160 are several methods of labeling all volumes in an autochanger magazine.
161 For more information on this, please see the \ilink{
162 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 recycle 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 recycle 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=FileStorage hourly at 0:05
310 Run = Level=Full Pool=Recycle Storage=FileStorage hourly at 0:20
311 Run = Level=Full Pool=Recycle Storage=FileStorage hourly at 0:35
312 Run = Level=Full Pool=Recycle Storage=FileStorage 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. You will also want to
414 give each Device specification a different Media Type so that during
415 a restore, Bacula will be able to find the appropriate drive.
417 The situation is a bit more complicated if you want to treat two different
418 physical disk drives (or partitions) logically as a single drive, which
419 Bacula does not directly support. However, it is possible to back up your
420 data to multiple disks as if they were a single drive by linking the
421 Volumes from the first disk to the second disk.
423 For example, assume that you have two disks named {\bf /disk1} and {\bf
424 /disk2}. If you then create a standard Storage daemon Device resource for
425 backing up to the first disk, it will look like the following:
432 Archive Device = /disk1
435 AutomaticMount = yes;
442 Since there is no way to get the above Device resource to reference both {\bf
443 /disk1} and {\bf /disk2} we do it by pre-creating Volumes on /disk2 with the
448 ln -s /disk2/Disk2-vol001 /disk1/Disk2-vol001
449 ln -s /disk2/Disk2-vol002 /disk1/Disk2-vol002
450 ln -s /disk2/Disk2-vol003 /disk1/Disk2-vol003
455 At this point, you can label the Volumes as Volume {\bf Disk2-vol001}, {\bf
456 Disk2-vol002}, ... and Bacula will use them as if they were on /disk1 but
457 actually write the data to /disk2. The only minor inconvenience with this
458 method is that you must explicitly name the disks and cannot use automatic
459 labeling unless you arrange to have the labels exactly match the links you
462 An important thing to know is that Bacula treats disks like tape drives
463 as much as it can. This means that you can only have a single Volume
464 mounted at one time on a disk as defined in your Device resource in
465 the Storage daemon's conf file. You can have multiple concurrent
466 jobs running that all write to the one Volume that is being used, but
467 if you want to have multiple concurrent jobs that are writting to
468 separate disks drives (or partitions), you will need to define
469 separate Device resources for each one, exactly as you would do for
470 two different tape drives. There is one fundamental difference, however.
471 The Volumes that you creat on the two drives cannot be easily exchanged
472 as they can for a tape drive, because they are physically resident (already
473 mounted in a sense) on the particular drive. As a consequence, you will
474 probably want to give them different Media Types so that Bacula can
475 distinguish what Device resource to use during a restore.
476 An example would be the following:
483 Archive Device = /disk1
486 AutomaticMount = yes;
494 Archive Device = /disk2
497 AutomaticMount = yes;
504 With the above device definitions, you can run two concurrent
505 jobs each writing at the same time, one to {\bf /disk2} and the
506 other to {\bf /disk2}. The fact that you have given them different
507 Media Types will allow Bacula to quickly choose the correct
508 Storage resource in the Director when doing a restore.
510 \label{MultipleClients}
511 \subsection*{Considerations for Multiple Clients}
512 \index[general]{Clients!Considerations for Multiple }
513 \index[general]{Considerations for Multiple Clients }
514 \addcontentsline{toc}{subsection}{Considerations for Multiple Clients}
516 If we take the above example and add a second Client, here are a few
520 \item Although the second client can write to the same set of Volumes, you
521 will probably want to write to a different set.
522 \item You can write to a different set of Volumes by defining a second Pool,
523 which has a different name and a different {\bf LabelFormat}.
524 \item If you wish the Volumes for the second client to go into a different
525 directory (perhaps even on a different filesystem to spread the load), you
526 would do so by defining a second Device resource in the Storage daemon. The
527 {\bf Name} must be different, and the {\bf Archive Device} could be
528 different. To ensure that Volumes are never mixed from one pool to another,
529 you might also define a different MediaType (e.g. {\bf File1}).
532 In this example, we have two clients, each with a different Pool and a
533 different number of archive files retained. They also write to different
534 directories with different Volume labeling.
536 The Director's configuration file is as follows:
542 QueryFile = "~/bacula/bin/query.sql"
543 PidDirectory = "~/bacula/working"
544 WorkingDirectory = "~/bacula/working"
545 Password = dir_password
547 # Basic weekly schedule
549 Name = "WeeklySchedule"
550 Run = Level=Full fri at 1:30
551 Run = Level=Incremental sat-thu at 1:30
554 Name = "Example FileSet"
555 Include = compression=GZIP signature=SHA1 {
556 /home/kern/bacula/bin
560 Name = "Backup-client1"
564 FileSet= "Example FileSet"
568 Schedule = "WeeklySchedule"
571 Name = "Backup-client2"
575 FileSet= "Example FileSet"
579 Schedule = "WeeklySchedule"
585 Password = client1_password
592 Password = client2_password
594 # Two Storage definitions permits different directories
598 Password = local_storage_password
605 Password = local_storage_password
611 dbname = bacula; user = bacula; password = ""
617 # Two pools permits different cycling periods and Volume names
618 # Cycle through 15 Volumes (two weeks)
621 Use Volume Once = yes
623 LabelFormat = "Client1-"
625 VolumeRetention = 13d
629 # Cycle through 8 Volumes (1 week)
632 Use Volume Once = yes
634 LabelFormat = "Client2-"
643 and the Storage daemon's configuration file is:
649 WorkingDirectory = "~/bacula/working"
650 Pid Directory = "~/bacula/working"
651 MaximumConcurrentJobs = 10
655 Password = local_storage_password
657 # Archive directory for Client1
661 Archive Device = /home/bacula/client1
664 AutomaticMount = yes;
668 # Archive directory for Client2
672 Archive Device = /home/bacula/client2
675 AutomaticMount = yes;
681 director = my-dir = all