Copy Jobs

Backup tapes are still the media of choice for backing up data, but backups on disk also have advantages. Thus, the approaches are often combined: Disk-to-disk-to-tape (D2D2T) backups are common. With this method, the data is first saved to disk, then transferred to a tape by a Migration or Copy job.

Before Bareos v13.2, Migration and Copy jobs were only supported within a Storage daemon (Figure 2). This restriction has been lifted in Bareos v13.2 – data can now be transported between Storage daemons (Figure 3). Thus, you can back up data from different firewall compartments, for example.

Figure 2: Previously: Copying was only possible within Storage daemons.

Figure 3: Now: Copying is possible between different Storage daemons across the network.

A corresponding Copy job can also copy data periodically to another Storage daemon. The data properties can be modified here to store the data without compression on the first Storage daemon but with compression on the second, making it possible to design scenarios such as backup-to-disk-to-cloud.

Passive Clients

Firewalls commonly cause problems when setting up the backup environment. In a normal connection in a Bareos/Bacula environment, the Backup Director would establish a connection to the client and tell it what to save and where. It also connects to the backup Storage daemon and tells it to accept and store the data from the client. Finally, the client establishes the actual data connection to the Storage daemon and sends its data to it.

If the client is behind a firewall, then packet filtering and network address translation (NAT) on the firewall can make a connection from the client to the Storage daemon difficult or impossible. The problematic connection is thus the actual data connection between the client and Storage daemon (Figure 4).

Figure 4: Previously: The data connection was initiated from the client to the Storage daemon.

As of Bareos 13.2, this behavior is now configurable. Using the Passive client option, you set up all connections to start with the server components. The client then only needs to accept connections. The process of opening connections between the Director and client and between the Director and the Storage daemon remains the same, but the actual data connection is now initiated not by the client, but by the Storage daemon. After the connection has been established, the data is, of course, sent from the client to the Storage daemon (Figure 5).

Figure 5: Passive client: The data connection is initiated by the Storage daemon to the client.

Besides its firewall friendliness, this approach offers another advantage: Because the passive client does not establish any data connections, it does not need working name resolution. In practical terms, name resolution often has been a problem with the conventional method.

Security

In terms of security, Bareos continues using the familiar safety features of Bacula, such as:

• checksum computation for each backed up file and verification during the restore, and
• the ability to encrypt connections between the daemons with TLS.

Additionally, Bareos adds some more interesting security features; for example, you can now choose the encryption method for software encryption. Previously, only AES128 was used. Now, the following methods are additionally available: AES128, AES192, AES256, CAMELIA128, CAMELIA192, CAMELIA256, AES128HNACSHA1, AES256HNACSHA1, and Blowfish.

In addition to the encryption options in the software, you can now directly use LTO tape drive hardware encryption. Since LTO4 encryption is part of the LTO standard, all drives offer this option. Tape drive encryption relies on hardware support and thus has virtually no effect on the speed of your backup.

Whether you use LTO hardware encryption depends on your requirements. It is a particularly efficient option for those who want to outsource their tapes and, in doing so, prevent unauthorized persons from reading them. The passive client option I mentioned earlier also offers safety benefits: Because the connection to the Storage daemon is no longer necessary, the firewalls can prevent all connections into the backup network.

Previously, you could send arbitrary commands to the client through the Director. These commands were backup (run a backup) restore (perform a restore), verify (run a scan job to sync between system data and backed up data), estimate (estimate the amount of backup data), and runscript (run a script on the client system).

Now, you can use the Allowed JobCommand directive to filter these commands on the client. Commands that are not allowed are then not accepted by the client and not executed.

Running scripts on the system to be backed up poses a special security threat. If you cannot completely prohibit this scenario with Allowed JobCommand, you at least have the option of setting the directory in which scripts and commands must be located through Allowed ScriptDir. Commands that do not reside in this directory are not executed.