Storage resource

Configuration directives for the Storage resource. Every directive is listed; value types and defaults are noted where the source provides them.

Address

Address = <address>

Where the address is a host name, a , or an IP address. Please note that the <address> as specified here will be transmitted to the File daemon who will then use it to contact the Storage daemon. Hence, it is not, a good idea to use localhost as the name but rather a fully qualified machine name or an IP address. This directive is required.

AllowCompression

AllowCompression = <yes|no>

This directive is optional, and if you specify no (the default is yes), it will cause backups jobs running on this storage resource to run without client File Daemon compression. This effectively overrides compression options in FileSets used by jobs which use this storage resource.

Autochanger

Autochanger = <yes|no>

If you specify yes for this command (the default is no), when you use the label command or the add command to create a new Volume, NGBackup will also request the Autochanger Slot number. This simplifies creating database entries for Volumes in an autochanger. If you forget to specify the Slot, the autochanger will not be used. However, you may modify the Slot associated with a Volume at any time by using the update volume or update slots command in the console program. When Autochanger is enabled, the algorithm used by NGBackup to search for available volumes will be modified to consider only Volumes that are known to be in the autochanger’s magazine. If no in changer volume is found, NGBackup will attempt recycling, pruning, …, and if still no volume is found, NGBackup will search for any volume whether or not in the magazine. By privileging in changer volumes, this procedure minimizes operator intervention. The default is no. For the autochanger to be used, you must also specify Autochanger = yes in the Device Resource in the Storage daemon’s configuration file as well as other important Storage daemon configuration information. Please consult the Using Autochangers manual of this chapter for the details of using autochangers. You can modify any additional Storage resources that correspond to devices that are part of the Autochanger device. Instead of the previous Autochanger = yes directive, the configuration should be modified to be Autochanger = xxx where xxx is the name of the Autochanger.

Client Connect Wait

Client Connect Wait = <time-interval>

This directive defines an interval of time in seconds that the Storage daemon will wait for a Client (the File daemon) to connect. The default is 30 minutes. Be aware that the longer the Storage daemon waits for a Client, the more resources will be tied up.

CommCompression

CommCompression = <yes|no>

If the two NGBackup components (DIR, FD, SD, backup-console) have the comm line compression enabled, the line compression will be enabled. The default value is yes.

In many cases, the volume of data transmitted across the communications line can be reduced by a factor of three when this directive is enabled. In the case that the compression is not effective, NGBackup turns it off on a record by record basis.

If you are backing up data that is already compressed the comm line compression will not be effective, and you are likely to end up with an average compression ratio that is very small. In this case, NGBackup reports None in the Job report.

Dedup Directory

Dedup Directory = <Directory>

This directive is mandatory when using Global Endpoint Deduplication feature, and specifies a directory in which the Storage daemon may put data block files for all devices of the type dedup. The Dedup Directory can be very large after some point, we advise you to use a logical volume manager to be able to extend the filesystem when needed with new disks.

Standard shell expansion of the Directory is done when the configuration file is read so that values such as $HOME will be properly expanded.

Dedup Index Directory

Dedup Index Directory = <Directory>

This directive is optional and specifies a directory in which the Storage daemon may put its index files for all devices of the type dedup. Standard shell expansion of the Directory is done when the configuration file is read so that values such as $HOME will be properly expanded. The default value is set to DedupDirectory when set.

Device

Device = <device-name>

This directive specifies the Storage daemon’s name of the device resource to be used for the storage. If you are using an Autochanger, the name specified here should be the name of the Storage daemon’s Autochanger resource rather than the name of an individual device. This name is not the physical device name, but the logical device name as defined on the Name directive contained in the Device or the Autochanger resource definition of the Storage daemon configuration file. You can specify any name you would like (even the device name if you prefer) up to a maximum of 127 characters in length. The physical device name associated with this device is specified in the Storage daemon configuration file (as Archive Device). Please take care not to define two different Storage resource directives in the Director that point to the same Device in the Storage daemon. Doing so may cause the Storage daemon to block (or hang) attempting to open the same device that is already open. This directive is required.

Enabled

Enabled = <yes|no>

This directive allows you to enable or disable a Storage resource. When the resource is disabled, the storage device will not be used. To reuse it you must re-enable the Storage resource.

FD Storage Address

FD Storage Address = <address>

Where the <address> is a host name, a , or an IP address. The <address> specified here will be transmitted to the File daemon instead of the IP address that the Director uses to contact the Storage daemon. This FDStorageAddress will then be used by the File daemon to contact the Storage daemon. This directive particularly useful if the File daemon is in a different network domain than the Director or Storage daemon. It is also useful in NAT or firewal environments. Backup over WAN using FD Storage Address

Heartbeat Interval

Heartbeat Interval = <time-interval>

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 300s. This feature is particularly useful if you have a router such as 3Com 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.

Maximum Concurrent Jobs

Maximum Concurrent Jobs = <number>

where <number> is the maximum number of Jobs that may run concurrently. The default is set to 20, 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 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 Maximum Concurrent Jobs in the Storage resource in the Director’s configuration file and possibly those in the Job and Client resources.

Maximum Concurrent Read Jobs

Maximum Concurrent Read Jobs = <number>

The main purpose is to limit the number of concurrent Copy, Migration, and VirtualFull jobs so that they don’t monopolize all the Storage drives causing a deadlock situation where all the drives are allocated for reading but none remain for writing. This deadlock situation can occur when running multiple simultaneous Copy, Migration, and VirtualFull jobs.

The default value is set to 0 (zero), which means there is no limit on the number of read jobs. Note, limiting the read jobs does not apply to Restore jobs, which are normally started by hand. A reasonable value for this directive is one half the number of drives that the Storage resource has rounded down. Doing so, will leave the same number of drives for writing and will generally avoid over committing drives and a deadlock.

Media Type

Media Type = <MediaType>

This directive specifies the Media Type to be used to store the data. This is an arbitrary string of characters up to 127 maximum that you define. It can be anything you want. However, it is best to make it descriptive of the storage media (e.g. “File”, “DAT”, “HP DLT8000”, “8mm”, …). In addition, it is essential that you make the Media Type specification unique for each storage media type. If you have two DDS-4 drives that have incompatible formats, or if you have a DDS-4 drive and a DDS-4 autochanger, you almost certainly should specify different Media Types. During a restore, assuming a DDS-4 Media Type is associated with the Job, NGBackup can decide to use any Storage daemon that supports Media Type DDS-4 and on any drive that supports it. If you are writing to disk Volumes, you must make doubly sure that each Device resource defined in the Storage daemon (and hence in the Director’s conf file) has a unique media type. Otherwise for NGBackup versions 1.38 and older, your restores may not work because NGBackup will assume that you can mount any Media Type with the same name on any Device associated with that Media Type. This is possible with tape drives, but with disk drives, unless you are very clever you cannot mount a Volume in any directory - this can be done by creating an appropriate soft link.

Currently NGBackup permits only a single Media Type per Storage and Device definition. Consequently, if you have a drive that supports more than one Media Type, you can give a unique string to Volumes with different intrinsic Media Type (Media Type = DDS-3-4 for DDS-3 and DDS-4 types), but then those volumes will only be mounted on drives indicated with the dual type (DDS-3-4).

If you want to tie NGBackup to using a single Storage daemon or drive, you must specify a unique Media Type for that drive. This is an important point that should be carefully understood. Note, this applies equally to Disk Volumes. If you define more than one disk Device resource in your Storage daemon’s conf file, the Volumes on those two devices are in fact incompatible because one can not be mounted on the other device since they are found in different directories. For this reason, you probably should use two different Media Types for your two disk Devices (even though you might think of them as both being File types). You can find more on this subject in the Basic Volume Management chapter of this manual.

The MediaType specified in the Director’s Storage resource, must correspond to the Media Type specified in the Device resource of the Storage daemon configuration file. This directive is required, and it is used by the Director and the Storage daemon to ensure that a Volume automatically selected from the Pool corresponds to the physical device. If a Storage daemon handles multiple devices (e.g. will write to various file Volumes on different partitions), this directive allows you to specify exactly which device.

As mentioned above, the value specified in the Director’s Storage resource must agree with the value specified in the Device resource in the Storage daemon’s configuration file. It is also an additional check so that you don’t try to write data for a DLT onto an 8mm device.

Name

Name = <name>

The Storage name used to identify the Director in the list of monitored daemons. It is not required to be the same as the one defined in the Storage’s configuration file. This record is required.

Password

Password = <password>

This is the password to be used when establishing a connection with the Storage services. This same password also must appear in the Director resource of the Storage daemon’s configuration file. This directive is required. If you have either /dev/random or bc on your machine, NGBackup will generate a random password during the configuration process, otherwise it will be left blank. The password is plain text. It is not generated through any special process, but it is preferable for security reasons to use random text.

Pid Directory

Pid Directory = <Directory>

This directive is mandatory and specifies a directory in which the Storage daemon may put its process Id file files. The process Id file is used to shutdown NGBackup and to prevent multiple copies of NGBackup from running simultaneously. This directive is required. Standard shell expansion of the Directory is done when the configuration file is read so that values such as $HOME will be properly expanded. Typically on Linux systems, you will set this to: /var/run. If you are not installing NGBackup in the system directories, you can use the Working Directory as defined above.

Port

Port = <port>

Where port is the port to use to contact the storage daemon for information and to start jobs. This same port number must appear in the Storage resource of the Storage daemon’s configuration file. The default is 9103.

SD Port

SD Port = <port>

Where port is the port to use to contact the storage daemon for information and to start jobs. This same port number must appear in the Storage resource of the Storage daemon’s configuration file. The default is 9103.

SDAddress

SDAddress = <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 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).

SDAddresses

SDAddresses = <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:

`

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 } }

`

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.

SDPort

SDPort = <port-number>

Specifies port number on which the Storage daemon listens for Director connections. The default is 9103.

Storage

Start of the Storage resources. At least one storage resource must be specified.

TLS Allowed CN

TLS Allowed CN = <string list>

Common name attribute of allowed peer certificates. This directive is valid for a server and in a client context. If this directive is specified, the peer certificate will be verified against this list. In the case this directive is configured on a server side, the allowed CN list will not be checked if TLS Verify Peer is set to no (TLS Verify Peer is yes by default). This can be used to ensure that only the CN-approved component may connect. This directive may be specified more than once. In the case this directive is configured in a server side, the allowed CN list will only be checked if TLS Verify Peer = yes (default). For example, in backup-fd.conf, Director resource definition:

`

Director { Name = backup-dir Password = “password” Address = director.example.com

TLS configuration directives

TLS Enable = yes TLS Require = yes

if TLS Verify Peer = no, then TLS Allowed CN will not be checked.

TLS Verify Peer = yes TLS Allowed CN = director.example.com TLS CA Certificate File = /opt/backup/ssl/certs/root_cert.pem TLS Certificate = /opt/backup/ssl/certs/client1_cert.pem TLS Key = /opt/backup/ssl/keys/client1_key.pem }

`

In the case this directive is configured in a client side, the allowed CN list will always be checked.

`

Client { Name = client1-fd Address = client1.example.com FDPort = 9102 Catalog = MyCatalog Password = “password” …

TLS configuration directives

TLS Enable = yes TLS Require = yes

the Allowed CN will be checked for this client by director

the client’s certificate Common Name must match any of

the values of the Allowed CN list

TLS Allowed CN = client1.example.com TLS CA Certificate File = /opt/backup/ssl/certs/ca_client1_cert.pem TLS Certificate = /opt/backup/ssl/certs/director_cert.pem TLS Key = /opt/backup/ssl/keys/director_key.pem }

`

If the client doesn’t provide a certificate with a Common Name that meets any value in the TLS Allowed CN list, an error message will be issued:

`

16-Nov 17:30 backup-dir JobId 0: Fatal error: bnet.c:273 TLS certificate verification failed. Peer certificate did not match a required commonName 16-Nov 17:30 backup-dir JobId 0: Fatal error: TLS negotiation failed with FD at “192.168.100.2:9102”.

`

TLS Authenticate

TLS Authenticate = <yes|no>

When TLS Authenticate is enabled, after doing the CRAM-MD5 authentication, NGBackup will also do TLS authentication, then TLS encryption will be turned off, and the rest of the communication between the two NGBackup components will be done without encryption. If TLS-PSK is used instead of the regular TLS, the encryption is turned off after the TLS-PSK authentication step. If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.

TLS CA Certificate Dir

TLS CA Certificate Dir = <Directory>

Full path to TLS CA certificate directory. In the current implementation, certificates must be stored PEM encoded with OpenSSL-compatible hashes, which is the subject name’s hash and an extension of .0. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer is set to no, and are always required in a client context.

TLS CA Certificate File

TLS CA Certificate File = <Filename>

The full path and filename specifying a PEM encoded TLS CA certificate(s). Multiple certificates are permitted in the file. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer (see above) is set to no, and are always required in a client context.

TLS Certificate

TLS Certificate = <Filename>

The full path and filename of a PEM encoded TLS certificate. It will be used as either a client or server certificate, depending on the connection direction. PEM stands for Privacy Enhanced Mail, but in this context refers to how the certificates are encoded. This format is used because PEM files are base64 encoded and hence ASCII text based rather than binary. They may also contain encrypted information. This directive is required in a server context, but it may not be specified in a client context if TLS Verify Peer is set to no in the corresponding server context.

Example:

File Daemon configuration file (backup-fd.conf), Director resource configuration has TLS Verify Peer = no:

`

Director { Name = backup-dir Password = “password” Address = director.example.com

TLS configuration directives

TLS Enable = yes TLS Require = yes TLS Verify Peer = no TLS CA Certificate File = /opt/backup/ssl/certs/root_cert.pem TLS Certificate = /opt/backup/ssl/certs/client1_cert.pem TLS Key = /opt/backup/ssl/keys/client1_key.pem }

`

Having TLS Verify Peer = no, means the File Daemon, server context, will not check Director’s public certificate, client context. There is no need to specify TLS Certificate File neither TLS Key directives in the Client resource, director configuration file. We can have the below client configuration in backup-dir.conf:

`

Client { Name = client1-fd Address = client1.example.com FDPort = 9102 Catalog = MyCatalog Password = “password” …

TLS configuration directives

TLS Enable = yes TLS Require = yes TLS CA Certificate File = /opt/backup/ssl/certs/ca_client1_cert.pem }

`

TLS DH File

TLS DH File = <Directory>

Path to PEM encoded Diffie-Hellman parameter file. If this directive is specified, DH key exchange will be used for the ephemeral keying, allowing for forward secrecy of communications. DH key exchange adds an additional level of security because the key used for encryption/decryption by the server and the client is computed on each end and thus is never passed over the network if Diffie-Hellman key exchange is used. Even if DH key exchange is not used, the encryption/decryption key is always passed encrypted. This directive is only valid within a server context. To generate the parameter file, you may use openssl:

`

openssl dhparam -out dh4096.pem -5 4096

`

TLS Enable

TLS Enable = <yes|no>

Enable TLS support. If TLS is not enabled, none of the other TLS directives have any effect. In other words, even if you set TLS Require = yes you need to have TLS enabled or TLS will not be used.

TLS Key

TLS Key = <Filename>

The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.

TLS PSK Enable

TLS PSK Enable = <yes|no>

Enable or Disable automatic TLS PSK support. TLS PSK is enabled by default between all NGBackup components. The Pre-Shared Key used between the programs is the NGBackup password. If both TLS Enable and TLS PSK Enable are enabled, the system will use TLS certificates.

TLS Require

TLS Require = <yes|no>

Require TLS or TLS-PSK encryption. This directive is ignored unless one of TLS Enable or TLS PSK Enable is set to yes. If TLS is not required while TLS or TLS-PSK are enabled, then the NGBackup component will connect with other components either with or without TLS or TLS-PSK

If TLS or TLS-PSK is enabled and TLS is required, then the NGBackup component will refuse any connection request that does not use TLS.

TLS Verify Peer

TLS Verify Peer = <yes|no>

Verify peer certificate. Instructs server to request and verify the client’s X.509 certificate. Any client certificate signed by a known-CA will be accepted. Additionally, the client’s X509 certificate Common Name must meet the value of the Address directive. If the TLSAllowed CN onfiguration directive is used, the client’s x509 certificate Common Name must also correspond to one of the CN specified in the TLS Allowed CN directive. This directive is valid only for a server and not in client context. The default is yes.

Working Directory

Working Directory = <Directory>

This directive is mandatory and specifies a directory in which the Storage daemon may put its status files. This directory should be used only by NGBackup, but may be shared by other NGBackup daemons provided the names given to each daemon are unique. This directive is required