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 }
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 directorys 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
+maching. 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=FileStorage hourly at 0:05
- Run = Level=Full Pool=Recycle Storage=FileStorage hourly at 0:20
- Run = Level=Full Pool=Recycle Storage=FileStorage hourly at 0:35
- Run = Level=Full Pool=Recycle Storage=FileStorage 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).
\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 differen 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;