This repository has been archived by the owner on Mar 19, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 16
/
storedconf.tex
1430 lines (1222 loc) · 63.5 KB
/
storedconf.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
%%
%%
\chapter{Storage Daemon Configuration}
\label{StoredConfChapter}
\index[general]{Storage Daemon Configuration}
\index[general]{Configuration!Storage Daemon}
The Storage Daemon configuration file has relatively few resource definitions.
However, due to the great variation in backup media and system capabilities,
the storage daemon must be highly configurable. As a consequence, there are
quite a large number of directives in the Device Resource definition that
allow you to define all the characteristics of your Storage device (normally a
tape drive). Fortunately, with modern storage devices, the defaults are
sufficient, and very few directives are actually needed.
For a general discussion of configuration file and resources including the
data types recognized by {\bf Bareos}, please see the
\ilink{Configuration}{ConfigureChapter} chapter of this manual. The
following Storage Resource definitions must be defined:
\begin{itemize}
\item
\ilink{Storage}{StorageResource} -- to define the name of the
Storage daemon.
\item
\ilink{Director}{DirectorResource1} -- to define the Director's
name and his access password.
\item
\ilink{Device}{DeviceResource} -- to define the
characteristics of your storage device (tape drive).
\item
\ilink{Messages}{MessagesChapter} -- to define where error and
information messages are to be sent.
\end{itemize}
Following resources are optional:
\begin{itemize}
\item
\ilink{AutoChanger}{AutochangerRes} -- to define Autochanger devices.
\item
\ilink{NDMP}{NDMPResource} -- to define the NDMP authentication
context.
\end{itemize}
\section{Storage Resource}
\label{StorageResource}
\index[general]{Resource!Storage}
\index[general]{Storage Resource}
In general, the properties specified under the Storage resource define global
properties of the Storage daemon. Each Storage daemon configuration file must
have one and only one Storage resource definition.
\begin{description}
\xdirective{dir}{}{Name}{name}{required}{}{}{%
Specifies the Name of the Storage daemon.
}
\xdirective{dir}{}{Working Directory}{directory}{required}{{\it platform specific}}{}{%
This directive specifies a directory in which the Storage daemon may put
its status files. This directory should be used only by {\bf Bareos},
but may be shared by other Bareos daemons provided the names given to each
daemon are unique.
}
\xdirective{dir}{}{Pid Directory}{directory}{required}{{\it platform specific}}{}{%
This directive specifies a directory in which the Storage Daemon may put its
process Id file files. The process Id file is used to shutdown Bareos and to
prevent multiple copies of Bareos from running simultaneously.
Standard shell expansion of the {\bf directory} is done when the
configuration file is read so that values such as {\bf \$HOME} will be
properly expanded.
}
% \item [Subsys Directory = {\textless}Directory{\textgreater}] \hfill \\
% \index[sd]{Subsys Directory}
% \index[sd]{Directive!Subsys Directory}
% This directive is currently unused.
\xdirective{dir}{}{Plugin Directory}{directory}{required}{{\it platform specific}}{}{%
This directive specifies a directory in which the Storage Daemon searches for
plugins with the name {\bf {\textless}pluginname{\textgreater}-sd.so} which it will load at startup.
}
%\directive{sd}{Scripts Directory}{directory}{required}{{\it platform specific}}{}
%This directive is currently unused.
\xdirective{dir}{}{Heartbeat Interval}{time-interval}{required}{0}{}{%
\index[general]{Broken pipe}%
This directive defines an interval of time in seconds. When
the Storage daemon is waiting for the operator to mount a
tape, each time interval, it will send a heartbeat signal to
the File daemon. The default interval is zero which disables
the heartbeat. This feature is particularly useful if you
have a router that does not follow Internet
standards and times out an valid connection after a short
duration despite the fact that keepalive is set. This usually
results in a broken pipe error message.
}
\xdirective{dir}{}{Client Connect Wait}{time-interval}{required}{30 minutes}{}{%
This directive defines an interval of time in seconds that
the Storage daemon will wait for a Client (the File daemon)
to connect. Be aware that the
longer the Storage daemon waits for a Client, the more
resources will be tied up.
}
\xdirective{dir}{}{Maximum Concurrent Jobs}{number}{required}{10}{}{%
where {\textless}number{\textgreater} is the maximum number of Jobs that may run
concurrently. The default is set to 10, but you may set it to a larger
number. Each contact from the Director (e.g. status request, job start
request) is considered as a Job, so if you want to be able to do a {\bf
status} request in the console at the same time as a Job is running, you
will need to set this value greater than 1. To run simultaneous Jobs,
you will need to set a number of other directives in the Director's
configuration file. Which ones you set depend on what you want, but you
will almost certainly need to set the {\bf Maximum Concurrent Jobs} in
the Storage resource in the Director's configuration file and possibly
those in the Job and Client resources.
}
\xdirective{dir}{}{SD Address}{IP-address}{}{}{}{%
This directive is optional, and if it is specified, it will cause the
Storage daemon server (for Director and File daemon connections) to bind
to the specified {\bf IP-Address}, which is either a domain name or an
IP address specified as a dotted quadruple. If this directive is not
specified, the Storage daemon will bind to any available address (the
default).
}
% failed to use xdirective here, because of verbatim including {}
\directive{sd}{SD Addresses}{IP-address-specification}{}{}{}%
Specify the ports and addresses on which the Storage daemon will listen
for Director connections. Normally, the default is sufficient and you
do not need to specify this directive. Probably the simplest way to
explain how this directive works is to show an example:
\begin{bconfig}{SD Addresses}
SDAddresses = { ip = {
addr = 1.2.3.4; port = 1205; }
ipv4 = {
addr = 1.2.3.4; port = http; }
ipv6 = {
addr = 1.2.3.4;
port = 1205;
}
ip = {
addr = 1.2.3.4
port = 1205
}
ip = {
addr = 1.2.3.4
}
ip = {
addr = 201:220:222::2
}
ip = {
addr = bluedot.thun.net
}
}
\end{bconfig}
where ip, ip4, ip6, addr, and port are all keywords. Note, that the address
can be specified as either a dotted quadruple, or IPv6 colon notation, or as
a symbolic name (only in the ip specification). Also, port can be specified
as a number or as the mnemonic value from the /etc/services file. If a port
is not specified, the default will be used. If an ip section is specified,
the resolution can be made either by IPv4 or IPv6. If ip4 is specified, then
only IPv4 resolutions will be permitted, and likewise with ip6.
Using this directive, you can replace both the SDPort and SDAddress
directives shown below.
\xdirective{dir}{}{SD Port}{port-number}{required}{9103}{}{%
Specifies port number on which the Storage daemon listens for Director
connections.
}
\xdirective{dir}{}{Compatible}{yes{\textbar}no}{required}{yes}{}{%
This directive enables the compatible mode of the storage daemon. In
this mode the storage daemon will try to write the storage data in a
compatible way with Bareos of which Bareos is a fork. This only works
for the data streams both share and not for any new datastreams which
are Bareos specific. Which may be read when used by a Bareos storage
daemon but might not be understood by any of the Bareos components
(dir/sd/fd).
}
\xdirective{dir}{}{NDMP Enable}{yes{\textbar}no}{}{}{}{%
This directive enables the Native NDMP Tape Agent.
}
\xdirective{dir}{}{NDMP Snooping}{yes{\textbar}no}{}{}{}{%
This directive enables the Snooping and pretty printing of NDMP protocol
information in debugging mode.
}
\xdirective{dir}{}{NDMP Loglevel}{level}{}{}{}{%
This directive sets the loglevel for the NDMP protocol library.
}
\xdirective{dir}{}{NDMP Address}{IP-address}{}{}{}{%
This directive is optional, and if it is specified, it will cause the
Storage daemon server (for NDMP Tape Server connections) to bind
to the specified {\bf IP-Address}, which is either a domain name or an
IP address specified as a dotted quadruple. If this directive is not
specified, the Storage daemon will bind to any available address (the
default).
}
\xdirective{dir}{}{NDMP Addresses}{IP-address-specification}{}{}{}{%
Specify the ports and addresses on which the Storage daemon will listen
for NDMP Tape Server connections. Normally, the default is sufficient and you
do not need to specify this directive.
}
\xdirective{dir}{}{NDMP Port}{port-specification}{}{10000}{}{%
Specifies port number on which the Storage daemon listens for NDMP Tape Server
connections.
}
\xdirective{dir}{}{AutoXflateOnReplication}{yes{\textbar}no}{required}{yes}{13.4.0}{%
\label{storage-storage-autoxflateonreplication}%
This directive controls the \ilink{autoxflate-sd plugin}{plugin-autoxflate-sd}
plugin when replicating data inside one or
between two storage daemons (Migration/Copy Jobs). Normally the storage daemon will
use the autoinflate/autodeflate setting of the device when reading and writing
data to it which could mean that while reading it inflates the compressed data
and the while writing the other deflates it again. If you just want the data to
be exactly the same e.g. don't perform any on the fly uncompression and compression
while doing the replication of data you can set this option to no and it will
override any setting on the device for doing auto inflation/deflation when doing
data replication. This will not have any impact on any normal backup or restore jobs.}
\end{description}
The following is a typical Storage daemon storage resource definition.
\begin{bconfig}{Storage daemon storage definition}
#
# "Global" Storage daemon configuration specifications appear
# under the Storage resource.
#
Storage {
Name = "Storage daemon"
Address = localhost
}
\end{bconfig}
\section{Director Resource}
\label{DirectorResource1}
\index[general]{Director Resource}
\index[general]{Resource!Director}
The Director resource specifies the Name of the Director which is permitted
to use the services of the Storage daemon. There may be multiple Director
resources. The Director Name and Password must match the corresponding
values in the Director's configuration file.
\begin{description}
\item [Name = {\textless}Director-Name{\textgreater}] \hfill \\
\index[sd]{Name}
\index[sd]{Directive!Name}
Specifies the Name of the Director allowed to connect to the Storage daemon.
This directive is required.
\item [Password = {\textless}Director-password{\textgreater}] \hfill \\
\index[sd]{Password}
\index[sd]{Directive!Password}
Specifies the password that must be supplied by the above named Director.
This directive is required.
\item [Monitor = {\textless}yes{\textbar}no{\textgreater}] \hfill \\
\index[sd]{Monitor}
\index[sd]{Directive!Monitor}
If Monitor is set to {\bf no} (default), this director will have full
access to this Storage daemon. If Monitor is set to {\bf yes}, this
director will only be able to fetch the current status of this Storage
daemon.
Please note that if this director is being used by a Monitor, we highly
recommend to set this directive to {\bf yes} to avoid serious security
problems.
\item [Key Encryption Key = {\textless}KeyEncryptionKey{\textgreater}] \hfill \\
\index[sd]{Key Encryption Key}
\index[sd]{Directive!Key Encryption Key}
This key is used to encrypt the Security Key that is exchanged between
the Director and the Storage Daemon for supporting Application Managed
Encryption (AME). For security reasons each Director should have a
different Key Encryption Key.
\end{description}
The following is an example of a valid Director resource definition:
\footnotesize
\begin{verbatim}
Director {
Name = MainDirector
Password = my_secret_password
}
\end{verbatim}
\normalsize
\section{NDMP Resource}
\label{NDMPResource}
\index[general]{Resource!NDMP}
\index[general]{NDMP Resource}
The NDMP Resource specifies the authentication details of each NDMP client.
There may be multiple NDMP resources for a single Storage daemon. In general,
the properties specified within the NDMP resource are specific to one client.
\begin{description}
\item [Name = {\textless}Client-Name{\textgreater}] \hfill \\
\index[sd]{Name}
\index[sd]{Directive!Name}
Specifies the name of the NDMP Client allowed to connect to the Storage daemon.
This directive is required.
\item [Username = {\textless}Client-Username{\textgreater}] \hfill \\
\index[sd]{Username}
\index[sd]{Directive!Username}
Specifies the username that must be supplied by the above named NDMP Client.
This directive is required.
\item [Password = {\textless}Client-password{\textgreater}] \hfill \\
\index[sd]{Password}
\index[sd]{Directive!Password}
Specifies the password that must be supplied by the above named NDMP Client.
This directive is required.
\item [Authtype = {\textless}Client-Authtype{\textgreater}] \hfill \\
\index[sd]{Authtype}
\index[sd]{Directive!Authtype}
Specifies the authentication type that must be supplied by the above named NDMP Client.
This directive is required.
The following values are allowed:
\begin{enumerate}
\item None - Use no password
\item Clear - Use clear text password
\item MD5 - Use MD5 hashing
\end{enumerate}
\item [Loglevel = {\textless}NDMP-Loglevel{\textgreater}] \hfill \\
\index[sd]{Loglevel}
\index[sd]{Directive!Loglevel}
Specifies the NDMP Loglevel which overrides the global NDMP loglevel for this client.
\end{description}
\label{DeviceResource}
\section{Device Resource}
\index[general]{Resource!Device}
\index[general]{Device Resource}
The Device Resource specifies the details of each device (normally a tape
drive) that can be used by the Storage daemon. There may be multiple
Device resources for a single Storage daemon. In general, the properties
specified within the Device resource are specific to the Device.
\begin{description}
\directive{sd}{Name}{name}{required}{}{}
Specifies the Name that the Director will use when asking to backup or
restore to or from to this device. This is the logical Device name, and may
be any string up to 127 characters in length. It is generally a good idea to
make it correspond to the English name of the backup device. The physical
name of the device is specified on the {\bf Archive Device} directive
described below. The name you specify here is also used in your Director's
conf file on the
\nameref{DirectorResourceStorage} in its Storage
resource.
\directive{sd}{Archive Device}{device {\textbar} directory {\textbar} fifo {\textbar} GlusterFS storage {\textbar} Ceph object store}{required}{}{}
Specifies where to read and write the backup data.
The type of the Archive Device can be specified by the {\bf Device Type} directive.
If Device Type is not specified, Bareos tries to guess the Device Type
accordingly to the type of the specified Archive Device file type.
There are three different types that are supported:
\begin{description}
\item[device] Usually the device file
name of a removable storage device (tape drive), for example \path|/dev/nst0|
or \path|/dev/rmt/0mbn|, preferably in the "non-rewind" variant.
In addition, on systems such as Sun, which have multiple tape
access methods, you must be sure to specify to use Berkeley I/O
conventions with the device. The {\bf b} in the Solaris (Sun) archive
specification \path|/dev/rmt/0mbn| is what is needed in this case.
Bareos does not support SysV tape drive behavior.
\item[directory] If a directory is specified, it is used as file storage.
The directory must be existing and be specified as absolute path.
Bareos will write to file storage in the specified
directory and the filename used will be the Volume name as specified in the
Catalog. If you want to write into more than one directory (i.e. to spread
the load to different disk drives), you will need to define two Device
resources, each containing an Archive Device with a different directory.
\item[fifo] \label{SetupFifo}
A FIFO is a special kind of file that connects two programs
via kernel memory. If a FIFO device is specified for a backup operation, you
must have a program that reads what Bareos writes into the FIFO. When the
Storage daemon starts the job, it will wait for {\bf MaximumOpenWait} seconds
for the read program to start reading, and then time it out and terminate
the job. As a consequence, it is best to start the read program at the
beginning of the job perhaps with the {\bf RunBeforeJob} directive. For this
kind of device, you never want to specify {\bf AlwaysOpen}, because you want
the Storage daemon to open it only when a job starts, so you must explicitly
set it to {\bf No}. Since a FIFO is a one way device, Bareos will not attempt
to read a label of a FIFO device, but will simply write on it. To create a
FIFO Volume in the catalog, use the {\bf add} command rather than the {\bf
label} command to avoid attempting to write a label.
\begin{bconfig}{Fifo device}
Device {
Name = FifoStorage
Media Type = Fifo
Device Type = Fifo
Archive Device = /tmp/fifo
LabelMedia = yes
Random Access = no
AutomaticMount = no
RemovableMedia = no
MaximumOpenWait = 60
AlwaysOpen = no
}
\end{bconfig}
During a restore operation, if the Archive Device is a FIFO, Bareos will
attempt to read from the FIFO, so you must have an external program that
writes into the FIFO. Bareos will wait {\bf MaximumOpenWait} seconds for the
program to begin writing and will then time it out and terminate the job. As
noted above, you may use the {\bf RunBeforeJob} to start the writer program
at the beginning of the job.
A FIFO device can also be used to test your configuration, see the \ilink{Howto section}{TestUsingFifoDevice}.
\item[GlusterFS Storage] \label{GlusterArchiveType}
A GlusterFS Storage can be used as Storage backend of Bareos.
Prerequistes are a working GlusterFS storage system and the package \package{bareos-storage-glusterfs}.
See \url{//http://www.gluster.org/} for more information regarding GlusterFS installation and configuration.
You can use following snippet to configure it as storage device:
\begin{bconfig}{GlusterFS device}
Device {
Name = GlusterStorage
Archive Device = gluster://server.example.com/volumename/bareos
Device Type = gfapi
Media Type = GlusterFile
Label Media = yes
Random Access = yes
Automatic Mount = yes
Removable Media = no
Always Open = no
}
\end{bconfig}
Adapt server and volume name to your environment.
\sinceVersion{sd}{GlusterFS Storage}{14.2.2}
\item[Ceph Object Store] \label{CephArchiveType}
Here you configure the Ceph object store, which is accessed by the SD using the Rados library. Prerequistes are a
working Ceph object store and the package \package{bareos-storage-ceph}. See \url{http://ceph.com} for more information regarding Ceph installation and configuration.
Assuming that you have an object store with name \file{your_bareos_store}
and your Ceph access is configured in \file{/etc/ceph/ceph.conf}, you can use following snippet to configure it as storage device:
\begin{bconfig}{Ceph Object Store Device}
Device {
Name = RadosStorage
Device Type = rados
Media Type = RadosFile
Archive Device = /etc/ceph/ceph.conf:your_bareos_store
LabelMedia = yes
Random Access = yes
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
}
\end{bconfig}
\sinceVersion{sd}{Ceph Storage}{14.2.2}
\end{description}
\directive{sd}{Device Type}{tape {\textbar} file {\textbar} fifo {\textbar} gfapi {\textbar} rados}{}{}{}
The Device Type specification allows you to explicitly tell Bareos
what kind of device you are defining. It the {\bf type-specification}
may be one of the following:
\begin{description}
\item [Tape]
The device is a tape device and thus is sequential access. Tape devices
are controlled using ioctl() calls.
\item [File]
Tells Bareos that the device is a file. It may either be a
file defined on fixed medium or a removable filesystem such as
USB. All files must be random access devices.
\item [Fifo]
The device is a first-in-first-out sequential access read-only
or write-only device.
\item [gfapi]
The gfapi device is used to access a GlusterFS storeage.
\sinceVersion{sd}{GlusterFS (gfapi)}{14.2.2}
\item [Rados]
The Rados device is used to access a Ceph object store.
\sinceVersion{sd}{Ceph (Rados)}{14.2.2}
\end{description}
The Device Type directive is not required, and if not specified, Bareos
will attempt to guess what kind of device has been specified using the
Archive Device specification supplied. There are several advantages to
explicitly specifying the Device Type. First, on some systems, block and
character devices have the same type.
Secondly, if you explicitly specify the Device Type, the mount point
need not be defined until the device is opened. This is the case with
most removable devices such as USB.
If the Device Type is not explicitly specified, then the mount point
must exist when the Storage daemon starts.
\item [Media Type = {\textless}name-string{\textgreater}] \hfill \\
\index[sd]{Media Type}
\index[sd]{Directive!Media Type}
The specified {\bf name-string} names the type of media supported by this
device, for example, "DLT7000". Media type names are arbitrary in that you
set them to anything you want, but they must be known to the volume
database to keep track of which storage daemons can read which volumes. In
general, each different storage type should have a unique Media Type
associated with it. The same {\bf name-string} must appear in the
appropriate Storage resource definition in the Director's configuration
file.
Even though the names you assign are arbitrary (i.e. you choose the name
you want), you should take care in specifying them because the Media Type
is used to determine which storage device Bareos will select during
restore. Thus you should probably use the same Media Type specification
for all drives where the Media can be freely interchanged. This is not
generally an issue if you have a single Storage daemon, but it is with
multiple Storage daemons, especially if they have incompatible media.
For example, if you specify a Media Type of "DDS-4" then during the
restore, Bareos will be able to choose any Storage Daemon that handles
"DDS-4". If you have an autochanger, you might want to name the Media Type
in a way that is unique to the autochanger, unless you wish to possibly use
the Volumes in other drives. You should also ensure to have unique Media
Type names if the Media is not compatible between drives. This
specification is required for all devices.
In addition, if you are using disk storage, each Device resource will
generally have a different mount point or directory. In order for
Bareos to select the correct Device resource, each one must have a
unique Media Type.
\label{Autochanger}
\item [Autochanger = {\textless}yes{\textbar}no{\textgreater}] \hfill \\
\index[sd]{Autochanger}
\index[sd]{Directive!Autochanger}
If {\bf Yes}, this device belongs to an automatic tape changer, and you
must specify an {\bf Autochanger} resource that points to the {\bf
Device} resources. You must also specify a
{\bf Changer Device}. If the Autochanger directive is set to {\bf
No} (default), the volume must be manually changed. You should also
have an identical directive to the
\ilink{Storage resource}{Autochanger1} in the Director's
configuration file so that when labeling tapes you are prompted for the slot.
\item [Changer Device = {\textless}name-string{\textgreater}] \hfill \\
\index[sd]{Changer Device}
\index[sd]{Directive!Changer Device}
The specified {\bf name-string} must be the {\bf generic SCSI} device
name of the autochanger that corresponds to the normal read/write
{\bf Archive Device} specified in the Device resource. This
generic SCSI device name should be specified if you have an autochanger
or if you have a standard tape drive and want to use the
{\bf Alert Command} (see below). For example, on Linux systems, for
an Archive Device name of {\bf /dev/nst0}, you would specify {\bf
/dev/sg0} for the Changer Device name. Depending on your exact
configuration, and the number of autochangers or the type of
autochanger, what you specify here can vary. This directive is
optional. See the \ilink{ Using Autochangers}{AutochangersChapter} chapter
of this manual for more details of using this and the following
autochanger directives.
\item [Changer Command = {\textless}name-string{\textgreater}] \hfill \\
\index[sd]{Changer Command}
\index[sd]{Directive!Changer Command}
The {\bf name-string} specifies an external program to be called that will
automatically change volumes as required by {\bf Bareos}. Normally,
this directive will be specified only in the {\bf AutoChanger} resource,
which is then used for all devices. However, you may also specify
the different {\bf Changer Command} in each Device resource.
Most frequently,
you will specify the Bareos supplied {\bf mtx-changer} script as follows:
\footnotesize
\begin{verbatim}
Changer Command = "/usr/lib/bareos/scripts/mtx-changer %c %o %S %a %d"
\end{verbatim}
\normalsize
and you will install the {\bf mtx} on your system.
An example of this command is in the default \file|bareos-sd.conf| file.
For more details on the substitution characters that may be specified to
configure your autochanger please see the
\ilink{Autochangers}{AutochangersChapter} chapter of this manual.
\item [Alert Command = {\textless}name-string{\textgreater}] \hfill \\
\index[sd]{Alert Command}
The {\bf name-string} specifies an external program to be called at the
completion of each Job after the device is released. The purpose of this
command is to check for Tape Alerts, which are present when something is
wrong with your tape drive (at least for most modern tape drives). The same
substitution characters that may be specified in the Changer Command may
also be used in this string. For more information, please see the
\ilink{Autochangers}{AutochangersChapter} chapter of this manual.
Note, it is not necessary to have an autochanger to use this command. The
example below uses the {\bf tapeinfo} program that comes with the {\bf mtx}
package, but it can be used on any tape drive. However, you will need to
specify a {\bf Changer Device} directive in your Device resource (see above)
so that the generic SCSI device name can be edited into the command (with
the \%c).
An example of the use of this command to print Tape Alerts in the Job report
is:
\footnotesize
\begin{verbatim}
Alert Command = "sh -c 'tapeinfo -f %c | grep TapeAlert'"
\end{verbatim}
\normalsize
and an example output when there is a problem could be:
\footnotesize
\begin{verbatim}
bareos-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface
between tape drive and initiator.
\end{verbatim}
\normalsize
\item [Drive Index = {\textless}number{\textgreater}] \hfill \\
\index[sd]{Drive Index}
\index[sd]{Directive!Drive Index}
The {\bf Drive Index} that you specify is passed to the {\bf
mtx-changer} script and is thus passed to the {\bf mtx} program. By
default, the Drive Index is zero, so if you have only one drive in your
autochanger, everything will work normally. However, if you have
multiple drives, you must specify multiple Bareos Device resources (one
for each drive). The first Device should have the Drive Index set to 0,
and the second Device Resource should contain a Drive Index set to 1,
and so on. This will then permit you to use two or more drives in your
autochanger.
\item [Autoselect = {\textless}yes{\textbar}no{\textgreater}] \hfill \\
\index[sd]{Autoselect}
\index[sd]{Directive!Autoselect}
If this directive is set to {\bf yes} (default), and the Device
belongs to an autochanger, then when the Autochanger is referenced
by the Director, this device can automatically be selected. If this
directive is set to {\bf no}, then the Device can only be referenced
by directly using the Device name in the Director. This is useful
for reserving a drive for something special such as a high priority
backup or restore operations.
\directive{sd}{Maximum Concurrent Jobs}{number}{}{}{}
{\bf Maximum Concurrent Jobs} is a directive that permits setting the maximum
number of Jobs that can run concurrently on a specified Device. Using this
directive, it is possible to have different Jobs using multiple drives, because
when the Maximum Concurrent Jobs limit is reached, the Storage Daemon will
start new Jobs on any other available compatible drive. This facilitates
writing to multiple drives with multiple Jobs that all use the same Pool.
\item [Maximum Changer Wait = {\textless}time{\textgreater}] \hfill \\
\index[sd]{Maximum Changer Wait}
\index[sd]{Directive!Maximum Changer Wait}
This directive specifies the maximum time in seconds for Bareos to wait
for an autochanger to change the volume. If this time is exceeded,
Bareos will invalidate the Volume slot number stored in the catalog and
try again. If no additional changer volumes exist, Bareos will ask the
operator to intervene. The default is 5 minutes.
% TODO: if this is the format, then maybe "5 minutes" should be in
% TODO: quotes? define style. see others.
\item [Maximum Rewind Wait = {\textless}time{\textgreater}] \hfill \\
\index[sd]{Maximum Rewind Wait}
\index[sd]{Directive!Maximum Rewind Wait}
This directive specifies the maximum time in seconds for Bareos to wait
for a rewind before timing out. If this time is exceeded,
Bareos will cancel the job. The default is 5 minutes.
\item [Maximum Open Wait = {\textless}time{\textgreater}] \hfill \\
\index[sd]{Maximum Open Wait}
\index[sd]{Directive!Maximum Open Wait}
This directive specifies the maximum time in seconds for Bareos to wait
for a open before timing out. If this time is exceeded,
Bareos will cancel the job. The default is 5 minutes.
\directive{sd}{Always Open}{yes{\textbar}no}{}{no}{}
If {\bf Yes}, Bareos will always keep the device open unless
specifically {\bf unmounted} by the Console program. This permits
Bareos to ensure that the tape drive is always available, and properly
positioned. If you set
{\bf AlwaysOpen} to {\bf no} {\bf Bareos} will only open the
drive when necessary, and at the end of the Job if no other Jobs are
using the drive, it will be freed. The next time Bareos wants to append
to a tape on a drive that was freed, Bareos will rewind the tape and
position it to the end. To avoid unnecessary tape positioning and to
minimize unnecessary operator intervention, it is highly recommended
that {\bf Always Open = yes}. This also ensures that the drive is
available when Bareos needs it.
If you have {\bf Always Open = yes} (recommended) and you want to use the
drive for something else, simply use the {\bf unmount} command in the
Console program to release the drive. However, don't forget to remount the
drive with {\bf mount} when the drive is available or the next Bareos job
will block.
For File storage, this directive is ignored. For a FIFO storage device, you
must set this to {\bf No}.
Please note that if you set this directive to {\bf No} Bareos will release
the tape drive between each job, and thus the next job will rewind the tape
and position it to the end of the data. This can be a very time consuming
operation. In addition, with this directive set to no, certain multiple
drive autochanger operations will fail. We strongly recommend to keep
{\bf Always Open} set to {\bf Yes}
\xdirective{dir}{}{Volume Poll Interval}{time-interval}{}{300}{}{%
If the time specified on this directive is non-zero,
%after asking the operator to mount a new volume
Bareos will periodically poll (or read) the
drive at the specified interval to see if a new volume has been mounted. If
the time interval is zero, no polling will occur. This
directive can be useful if you want to avoid operator intervention via the
console. Instead, the operator can simply remove the old volume and insert
the requested one, and Bareos on the next poll will recognize the new tape
and continue.
Please be aware that if you set this interval too small, you
may excessively wear your tape drive if the old tape remains in the drive,
since Bareos will read it on each poll.
% This can be avoided by ejecting the
% tape using the {\bf Offline On Unmount} and the {\bf Close on Poll}
% directives.
% However, if you are using a Linux 2.6 kernel or other OSes
% such as FreeBSD or Solaris, the Offline On Unmount will leave the drive
% with no tape, and Bareos will not be able to properly open the drive and
% may fail the job.
%\TODO{reference is missing: For more information on this problem, please see the
%\ilink{description of Offline On Unmount}{NoTapeInDrive} in the Tape
%Testing chapter.}
}
\item [Close on Poll= {\textless}yes{\textbar}no{\textgreater}] \hfill \\
\index[sd]{Close on Poll}
\index[sd]{Directive!Close on Poll}
If {\bf Yes}, Bareos close the device (equivalent to an unmount except no
mount is required) and reopen it at each poll. Normally this is not too
useful unless you have the {\bf Offline on Unmount} directive set, in which
case the drive will be taken offline preventing wear on the tape during any
future polling. Once the operator inserts a new tape, Bareos will recognize
the drive on the next poll and automatically continue with the backup.
Please see above for more details.
\item [Maximum Open Wait = {\textless}time{\textgreater}] \hfill \\
\index[sd]{Maximum Open Wait}
\index[sd]{Directive!Maximum Open Wait}
This directive specifies the maximum amount of time in seconds that
Bareos will wait for a device that is busy. The default is 5 minutes.
If the device cannot be obtained, the current Job will be terminated in
error. Bareos will re-attempt to open the drive the next time a Job
starts that needs the the drive.
\label{removablemedia}
\item [Removable media = {\textless}yes{\textbar}no{\textgreater}] \hfill \\
\index[sd]{Removable media}
\index[sd]{Directive!Removable media}
If {\bf Yes}, this device supports removable media (for example, tapes
or CDs). If {\bf No}, media cannot be removed (for example, an
intermediate backup area on a hard disk). If {\bf Removable media} is
enabled on a File device (as opposed to a tape) the Storage daemon will
assume that device may be something like a USB device that can be
removed or a simply a removable harddisk. When attempting to open
such a device, if the Volume is not found (for File devices, the Volume
name is the same as the Filename), then the Storage daemon will search
the entire device looking for likely Volume names, and for each one
found, it will ask the Director if the Volume can be used. If so,
the Storage daemon will use the first such Volume found. Thus it
acts somewhat like a tape drive -- if the correct Volume is not found,
it looks at what actually is found, and if it is an appendable Volume,
it will use it.
If the removable medium is not automatically mounted (e.g. udev), then
you might consider using additional Storage daemon device directives
such as {\bf Requires Mount}, {\bf Mount Point}, {\bf Mount Command},
and {\bf Unmount Command}, all of which can be used in conjunction with
{\bf Removable Media}.
\item [Random access = {\textless}yes{\textbar}no{\textgreater}] \hfill \\
\index[sd]{Random access}
\index[sd]{Directive!Random access}
If {\bf Yes}, the archive device is assumed to be a random access medium
which supports the {\bf lseek} (or {\bf lseek64} if Largefile is enabled
during configuration) facility. This should be set to {\bf Yes} for all
file systems such as USB, and fixed files. It should be set to
{\bf No} for non-random access devices such as tapes and named pipes.
\item [Requires Mount = {\textless}yes{\textbar}no{\textgreater}] \hfill \\
\index[sd]{Requires Mount}
When this directive is enabled, the Storage daemon will submit
a {\bf Mount Command} before attempting to open the device.
You must set this directive to {\bf yes} for removable
file systems such as USB devices that are not automatically mounted
by the operating system when plugged in or opened by Bareos.
It should be set to {\bf no} for
all other devices such as tapes and fixed filesystems. It should also
be set to {\bf no} for any removable device that is automatically
mounted by the operating system when opened (e.g. USB devices mounted
by udev or hotplug). This directive
indicates if the device requires to be mounted using the {\bf Mount
Command}. To be able to write devices need a mount, the following
directives must also be defined: {\bf Mount Point}, {\bf Mount Command},
and {\bf Unmount Command}.
\item [Mount Point = {\textless}directory{\textgreater}] \hfill \\
\index[sd]{Mount Point}
Directory where the device can be mounted.
This directive is used only
for devices that have {\bf Requires Mount} enabled such as
USB file devices.
\item [Mount Command = {\textless}name-string{\textgreater}] \hfill \\
\index[sd]{Mount Command}
This directive specifies the command that must be executed to mount
devices such as many USB devices. Before the command is
executed, \%a is replaced with the Archive Device, and \%m with the Mount
Point.
See the \ilink {Edit Codes}{mountcodes} section below for more details of
the editing codes that can be used in this directive.
If you need to specify multiple commands, create a shell script.
\item [Unmount Command = {\textless}name-string{\textgreater}] \hfill \\
\index[sd]{Unmount Command}
This directive specifies the command that must be executed to unmount
devices such as many USB devices. Before the command is
executed, \%a is replaced with the Archive Device, and \%m with the Mount
Point.
Most frequently, you will define it as follows:
\footnotesize
\begin{verbatim}
Unmount Command = "/bin/umount %m"
\end{verbatim}
\normalsize
See the \ilink {Edit Codes}{mountcodes} section below for more details of
the editing codes that can be used in this directive.
If you need to specify multiple commands, create a shell script.
\item [Label Media = {\textless}yes{\textbar}no{\textgreater}] \hfill \\
\index[general]{Label Media}
\index[sd]{Label Media}
\index[sd]{Directive!Label Media}
If {\bf Yes}, permits this device to automatically label blank media
without an explicit operator command. It does so by using an internal
algorithm as defined on the \linkResourceDirective{Dir}{Pool}{Label Format} record in each
Pool resource. If this is {\bf No} as by default, Bareos will label
tapes only by specific operator command ({\bf label} in the Console) or
when the tape has been recycled. The automatic labeling feature is most
useful when writing to disk rather than tape volumes.
\xdirective{Sd}{Device}{Label Type}{ANSI{\textbar}IBM{\textbar}Bareos}{}{}{}{%
Defines the label type to use, see section \nameref{AnsiLabelsChapter}.
This directive is implemented in the Director Pool resource (\linkResourceDirective{Dir}{Pool}{Label Type})
and in the SD Device resource. If it is specified in the the SD Device resource, it will take
precedence over the value passed from the Director to the SD.
If it is set to a non-default value, make sure to also enable \linkResourceDirective{Sd}{Device}{Check Label}.
}
\xdirective{Sd}{Device}{Check Label}{yes{\textbar}no}{}{no}{}{%
If you intend to read ANSI or IBM labels, this \textbf{must} be set.
Even if the volume is not ANSI labeled, you can set this to yes, and Bareos will check the
label type. Without this directive set to yes, Bareos will assume that
labels are of Bareos type and will not check for ANSI or IBM labels.
In other words, if there is a possibility of Bareos encountering an
ANSI/IBM label, you must set this to yes.
}
\item [Automatic Mount = {\textless}yes{\textbar}no{\textgreater}] \hfill \\
\index[sd]{Automatic mount}
\index[sd]{Directive!Automatic mount}
If {\bf Yes} (the default), permits the daemon to examine the device to
determine if it contains a Bareos labeled volume. This is done
initially when the daemon is started, and then at the beginning of each
job. This directive is particularly important if you have set
{\bf Always Open = no} because it permits Bareos to attempt to read the
device before asking the system operator to mount a tape. However,
please note that the tape must be mounted before the job begins.
\directive{sd}{Block Checksum}{\dtYesNo}{}{yes}{}
You may turn off the Block Checksum (CRC32) code that Bareos uses when
writing blocks to a Volume. Doing so can reduce the Storage daemon CPU usage
slightly. It will also permit Bareos to read a Volume that has corrupted
data.
\textbf{We do not recommend to turn this off} particularly on older tape
drives or for disk Volumes where doing so may allow corrupted data to go
undetected.
% xdirective? no bconfig in xdirective
\directive{sd}{Minimum Block Size}{\dtSize}{}{0}{}%
\label{storage-device-minimumblocksize}%
This statement applies only to non-random access devices (e.g.
tape drives). Blocks written by the storage daemon to a non-random
archive device will never be smaller than the given size.
The Storage daemon will attempt to efficiently fill blocks with data
received from active sessions but will, if necessary, add padding to a
block to achieve the required minimum size.
To force the block size to be fixed, as is the case for some non-random
access devices (tape drives), set the {\bf Minimum block size} and the
{\bf Maximum block size} to the same value. The default
is that both the minimum and maximum block size are zero and the default
block size is 64,512 bytes.
For example, suppose you want a fixed block size of 100K bytes, then you
would specify:
\begin{bconfig}{Fixed Block Size}
Minimum block size = 100K
Maximum block size = 100K
\end{bconfig}
Please note that if you specify a fixed block size as shown above, the tape
drive must either be in variable block size mode, or if it is in fixed block
size mode, the block size (generally defined by \command{mt}) {\bf must} be
identical to the size specified in Bareos -- otherwise when you attempt to
re-read your Volumes, you will get an error.
If you want the block size to be variable but with a 63K minimum and 200K
maximum (and default as well), you would specify:
\begin{bconfig}{Variable Block Size}
Minimum block size = 63K
Maximum block size = 200K
\end{bconfig}
\xdirective{dir}{}{Maximum block size}{\dtSize}{}{64512}{}{
\label{storage-device-maximumblocksize}%
The Storage daemon will always attempt to
write blocks of the specified size (in-bytes) to the archive device.
As a consequence, this statement specifies both the default block size
and the maximum block size. The size written never exceed the given
size. If adding data to a block would cause it to exceed
the given maximum size, the block will be written to the archive device,
and the new data will begin a new block.
If no value is specified or zero is specified, the Storage daemon will
use a default block size of 64,512 bytes (126 * 512).
\warning{If your are using LTO drives, changing the block size after labeling the tape will result into unreadable tapes.}
Please read chapter \nameref{Tapespeed and blocksizes},
to see how to tune this value in a safe manner.
}
\xdirective{dir}{}{Label block size}{\dtSize}{}{64512}{14.2.0}{
The storage daemon will write the label blocks with the size configured here.
Usually, you will not need to change this directive.
For more information on this directive, please see \nameref{Tapespeed and blocksizes}.
}
\directive{sd}{Hardware End of Medium}{yes{\textbar}no}{}{yes}{}
All modern (after 1998) tape drives should support this
feature. In doubt, use the {\bf btape} program to test your drive to see whether or not it
supports this function.
If the archive device does not support the end of medium
ioctl request {\tt MTEOM}, set this parameter to {\bf No}.
The storage daemon will then use the forward space file
function to find the end of the recorded data.
In addition, your SCSI driver must