backup to disk Volumes rather than tape Volumes. This chapter is intended to
give you some of the options that are available to you so that you can manage
either disk or tape volumes.
-\label{Concepts}
+\label{Concepts}
\subsection*{Key Concepts and Resource Records}
\index[general]{Key Concepts and Resource Records }
\index[general]{Records!Key Concepts and Resource }
that unless you specify otherwise, Bacula will always write to the same volume
until you run out of disk space. This problem is addressed below.
+In addition, if you want to use concurrent jobs that write to several
+different volumes at the same time, you will need to understand a number
+of other details. An example of such a configuration is given
+at the end of this chapter under \ilink{Concurrent Disk
+Jobs}{ConcurrentDiskJobs}.
+
\subsubsection*{Pool Options to Limit the Volume Usage}
\index[general]{Usage!Pool Options to Limit the Volume }
\index[general]{Pool Options to Limit the Volume Usage }
\ilink{Python Scripting}{_ChapterStart60} chapter of this manual for more
details.
-Please note that automatic Volume labeling can also be used with tapes, but it is not
-nearly so practical since the tapes must be pre-mounted. This requires some
-user interaction. Automatic labeling from templates does NOT work with
-autochangers since Bacula will not access unknown slots. There are several
-methods of labeling all volumes in an autochanger magazine. For more
-information on this, please see the
-\ilink{ Autochanger}{_ChapterStart18} chapter of this manual.
+Please note that automatic Volume labeling can also be used with tapes, but
+it is not nearly so practical since the tapes must be pre-mounted. This
+requires some user interaction. Automatic labeling from templates does NOT
+work with autochangers since Bacula will not access unknown slots. There
+are several methods of labeling all volumes in an autochanger magazine.
+For more information on this, please see the \ilink{
+Autochanger}{_ChapterStart18} chapter of this manual.
Automatic Volume labeling is enabled by making a change to both the Pool
resource (Director) and to the Device resource (Storage daemon) shown above.
\item The
\ilink{ Recycle Oldest Volume = yes}{RecycleOldest} record in the
Pool resource tells Bacula to Prune the oldest volume in the Pool, and if all
- files were pruned to recyle this volume and use it.
+ files were pruned to recycle this volume and use it.
\item The
\ilink{ Recycle Current Volume = yes}{RecycleCurrent} record in
the Pool resource tells Bacula to Prune the currently mounted volume in the
- Pool, and if all files were pruned to recyle this volume and use it.
+ Pool, and if all files were pruned to recycle this volume and use it.
\item The
\ilink{ Purge Oldest Volume = yes}{PurgeOldest} record in the
Pool resource permits a forced recycling of the oldest Volume when a new one
Current Volume = yes}. In this case, when Bacula needs a new Volume, it will
prune the specified volume.
+\label{ConcurrentDiskJobs}
+\subsection*{Concurrent Disk Jobs}
+\index[general]{Concurrent Disk Jobs}
+\addcontentsline{toc}{subsection}{Concurrent Disk Jobs}
+Above, we discussed how you could have a single device named {\bf
+FileBackup} that writes to volumes in {\bf /home/bacula/backups}.
+You can, in fact, run multiple concurrent jobs using the
+Storage definition given with this example, and all the jobs will
+simultaneously write into the Volume that is being written.
+
+Now suppose you want to use multiple Pools, which means multiple
+Volumes, or suppose you want each client to have its own Volume
+and perhaps its own directory such as {\bf /home/bacula/client1}
+and {\bf /home/bacula/client2} ... With the single Storage and Device
+definition above, neither of these two is possible. Why? Because
+Bacula disk storage follows the same rules as tape devices. Only
+one Volume can be mounted on any Device at any time. If you want
+to simultaneously write multiple Volumes, you will need multiple
+Device resources in your bacula-sd.conf file, and thus multiple
+Storage resources in your bacula-dir.conf.
+
+OK, so now you should understand that you need multiple Device definitions
+in the case of different directories or different Pools, but you also
+need to know that the catalog data that Bacula keeps contains only
+the Media Type and not the specific storage device. This permits a tape
+for example to be re-read on any compatible tape drive. The compatibility
+being determined by the Media Type. The same applies to disk storage.
+Since a volume that is written by a Device in say directory {\bf
+/home/bacula/backups} cannot be read by a Device with an Archive Device
+definition of {\bf /home/bacula/client1}, you will not be able to
+restore all your files if you give both those devices
+{\bf Media Type = File}. During the restore, Bacula will simply choose
+the first available device, which may not be the correct one. If this
+is confusing, just remember that the Directory has only the Media Type
+and the Volume name. It does not know the {\bf Archive Device} (or the
+full path) that is specified in the Storage daemon. Thus you must
+explicitly tie your Volumes to the correct Device by using the Media Type.
+
+The example shown below shows a case where there are two clients, each
+using its own Pool and storing their Volumes in different directories.
+
+
\label{Example2}
\subsection*{An Example}
\index[general]{Example }
The following example is not very practical, but can be used to demonstrate
the proof of concept in a relatively short period of time. The example
-consists of a single client that is backed up to a set of 12 archive files
-(Volumes). Each Volume is used (written) only once, and there are four Full
-saves done every hour (so the whole thing cycles around after three hours).
+consists of a two clients that are backed up to a set of 12 archive files
+(Volumes) for each client into different directories on the Storage
+machine. Each Volume is used (written) only once, and there are four Full
+saves done every hour (so the whole thing cycles around after three hours).
+
+What is key here is that each physical device on the Storage daemon
+has a different Media Type. This allows the Director to choose the
+correct device for restores ...
The Director's configuration file is as follows:
}
Schedule {
Name = "FourPerHour"
- Run = Level=Full Pool=Recycle Storage=File hourly at 0:05
- Run = Level=Full Pool=Recycle Storage=File hourly at 0:20
- Run = Level=Full Pool=Recycle Storage=File hourly at 0:35
- Run = Level=Full Pool=Recycle Storage=File hourly at 0:50
+ Run = Level=Full hourly at 0:05
+ Run = Level=Full hourly at 0:20
+ Run = Level=Full hourly at 0:35
+ Run = Level=Full hourly at 0:50
}
Job {
Name = "RecycleExample"
Pool = Recycle
Schedule = FourPerHour
}
+
+Job {
+ Name = "RecycleExample2"
+ Type = Backup
+ Level = Full
+ Client = Roxie
+ FileSet= "Example FileSet"
+ Messages = Standard
+ Storage = FileStorage1
+ Pool = Recycle1
+ Schedule = FourPerHour
+}
+
FileSet {
Name = "Example FileSet"
Include = compression=GZIP signature=SHA1 {
Catalog = BackupDB
Password = client_password
}
+
+Client {
+ Name = Roxie
+ Address = roxie
+ Catalog = BackupDB
+ Password = client1_password
+}
+
Storage {
Name = FileStorage
Address = rufus
Device = RecycleDir
Media Type = File
}
+
+Storage {
+ Name = FileStorage1
+ Address = rufus
+ Password = local_storage_password
+ Device = RecycleDir1
+ Media Type = File1
+}
+
Catalog {
Name = BackupDB
dbname = bacula; user = bacula; password = ""
Name = Recycle
Use Volume Once = yes
Pool Type = Backup
- LabelFormat = "Vol"
+ LabelFormat = "Recycle-"
AutoPrune = yes
VolumeRetention = 2h
Maximum Volumes = 12
Recycle = yes
}
+
+Pool {
+ Name = Recycle1
+ Use Volume Once = yes
+ Pool Type = Backup
+ LabelFormat = "Recycle1-"
+ AutoPrune = yes
+ VolumeRetention = 2h
+ Maximum Volumes = 12
+ Recycle = yes
+}
+
\end{verbatim}
\normalsize
RemovableMedia = no;
AlwaysOpen = no;
}
+
+Device {
+ Name = RecycleDir1
+ Media Type = File1
+ Archive Device = /home/bacula/backups1
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+
Messages {
Name = Standard
director = my-dir = all
\end{verbatim}
\normalsize
-In this example, the Jobs will be backed up to directory {\bf
-/home/bacula/backups} with Volume names Vol0001, Vol0002, ... Vol0012. Every
-backup Job will write a new volume cycling through the volume numbers, and two
-hours after a job has started, the volume will be pruned {\bf Volume Retention
-= 2h}.
-
With a little bit of work, you can change the above example into a weekly or
monthly cycle (take care about the amount of archive disk space used).
Bacula can, of course, use multiple disks, but in general, each disk must be a
separate Device specification in the Storage daemon's conf file, and you must
-then select what clients to backup to each disk.
+then select what clients to backup to each disk. You will also want to
+give each Device specification a different Media Type so that during
+a restore, Bacula will be able to find the appropriate drive.
-The situation is a bit more complicated if you want to treat two disk drives
-logically as a single drive, which Bacula does not directly support. However,
-it is possible to back up your data to multiple disks as if they were a single
-drive by linking the Volumes from the first disk to the second disk.
+The situation is a bit more complicated if you want to treat two different
+physical disk drives (or partitions) logically as a single drive, which
+Bacula does not directly support. However, it is possible to back up your
+data to multiple disks as if they were a single drive by linking the
+Volumes from the first disk to the second disk.
For example, assume that you have two disks named {\bf /disk1} and {\bf
-/disk2>}. If you then create a standard Storage daemon Device resource for
+/disk2}. If you then create a standard Storage daemon Device resource for
backing up to the first disk, it will look like the following:
\footnotesize
method is that you must explicitly name the disks and cannot use automatic
labeling unless you arrange to have the labels exactly match the links you
have created.
-\label{MultipleClients}
+An important thing to know is that Bacula treats disks like tape drives
+as much as it can. This means that you can only have a single Volume
+mounted at one time on a disk as defined in your Device resource in
+the Storage daemon's conf file. You can have multiple concurrent
+jobs running that all write to the one Volume that is being used, but
+if you want to have multiple concurrent jobs that are writing to
+separate disks drives (or partitions), you will need to define
+separate Device resources for each one, exactly as you would do for
+two different tape drives. There is one fundamental difference, however.
+The Volumes that you create on the two drives cannot be easily exchanged
+as they can for a tape drive, because they are physically resident (already
+mounted in a sense) on the particular drive. As a consequence, you will
+probably want to give them different Media Types so that Bacula can
+distinguish what Device resource to use during a restore.
+An example would be the following:
+
+\footnotesize
+\begin{verbatim}
+Device {
+ Name = Disk1
+ Media Type = File1
+ Archive Device = /disk1
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+
+Device {
+ Name = Disk2
+ Media Type = File2
+ Archive Device = /disk2
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+\end{verbatim}
+\normalsize
+
+With the above device definitions, you can run two concurrent
+jobs each writing at the same time, one to {\bf /disk2} and the
+other to {\bf /disk2}. The fact that you have given them different
+Media Types will allow Bacula to quickly choose the correct
+Storage resource in the Director when doing a restore.
+
+\label{MultipleClients}
\subsection*{Considerations for Multiple Clients}
\index[general]{Clients!Considerations for Multiple }
-\index[general]{Considerations for Multiple Clients }
+\index[general]{Multiple Clients}
\addcontentsline{toc}{subsection}{Considerations for Multiple Clients}
If we take the above example and add a second Client, here are a few
Catalog = BackupDB
Password = client2_password
}
-# Two Storage definitions permits different directories
+# Two Storage definitions with different Media Types
+# permits different directories
Storage {
Name = File1
Address = rufus
Password = local_storage_password
Device = client1
- Media Type = File
+ Media Type = File1
}
Storage {
Name = File2
Address = rufus
Password = local_storage_password
Device = client2
- Media Type = File
+ Media Type = File2
}
Catalog {
Name = BackupDB
# Archive directory for Client1
Device {
Name = client1
- Media Type = File
+ Media Type = File1
Archive Device = /home/bacula/client1
LabelMedia = yes;
Random Access = Yes;
# Archive directory for Client2
Device {
Name = client2
- Media Type = File
+ Media Type = File2
Archive Device = /home/bacula/client2
LabelMedia = yes;
Random Access = Yes;
projects / bacula / docs / blobdiff