The Backup Daemon is a new feature that adds to the existing options for creating and restoring backups for and from stand-alone and managed firewalls. Unlike backups stored in PAR files at a user's request, the backup daemon can be configured to operate autonomously at a scheduled time without any further interference. The backup daemon operates on the box level of an unmanaged box, a CC-managed box, and a Control Center, and must always be configured on the box level.
The backup daemon can create backups of the firewall configurations on the box level, on the CC level, and on the box & CC levels.
Creating Backup Storages and Backups
Local and Remote Storage
After enabling the backup daemon, you must register a certain type of storage that is identified by a unique ID.
The back-end storage can be one of three types:
Local Storage: Local back end in the file system of the firewall
Remote Storage: An AWS S3 bucket
Remote Storage: An Azure blob
Although the size of local storage is limited by the size of the firewall's internal hard disk/SSD, remote cloud storage is limited only by the licensing model you chose. However, if local control, availability, and speed are paramount to you, operating local storage can be the better choice.
Connecting to storage is provided by configuring a 'path' (back-end URL) that lets the backup daemon send data to the configured storage. The format for the 'path' depends on the type of storage you chose:
Local storage:
/myPath
Example:/myLocalStorageAWS S3 bucket:
server:port/bucket_name
Example:https://s3.amazonaws.com/bucket-backupsAzure blob:
container_name:/path
Example:containerbackup:/folder-backups
Authorization, Backup Encryption
Back-end storage is intended to be used over the long term. However, due to specific circumstances, a local back-end storage cannot be deleted on a user level after its creation and therefore requires thorough planning before being created.
Every local back-end storage requires information for permitting a specific user to write to its file system. Access to the local storage uses your firewall credentials. When using a remote storage, you must use an existing Backend user user ID and a Backend key for access. These credentials are mandatory for connecting to remote storage.
In addition, every storage is protected by encryption. You must provide an encryption password both for local and for remote storage.
The back-end URL contains the specific path for a certain storage (e.g., Local, AWS, Azure), as described above. This path entirely describes the directory nodes from the upmost directory down to the effective storage, e.g.:
Local:
/your/specific/the_storageAWS S3 bucket:
https://s3.amazonaws.com/bucket-backupsAzure blob:
containerbackup:/folder-backups
The encryption password is used to encrypt the content of the_storage. Therefore, every instance that is to access the content of this storage requires the use of this encryption password for encrypting/decrypting the content. Once the encryption password has been set, it can no longer be changed. If you want to delete a certain storage, you must do it manually via SSH on your firewall or by logging into your Cloud storage with your Cloud credentials.
For better organization, it is also possible to create multiple storage locations under a partly common path /your/common/storage_path/, e.g., /your/common/storage_path/storage_1, /your/common/storage_path/storage_2. In this case, as already mentioned, each storage_<n> requires its individual encryption password for access.
After entering the URL for the back end, you can add one or multiple backup jobs by configuring repeating trigger events.
Backup Jobs
A backup job is identified by a unique ID that relates exclusively to the firewall it is created on. The backup job can be configured to compress the data before sending it to the storage. You must create an execution trigger, which is the time to start the backup, supplied in Unix-like cronjob format. This cronjob format requires you to enter the time in the following template: 'Minute - Hour - Day of Month - Month - Day of the Week'.
The following table shows some examples of different possible entries:
Minute | Hour | Day of the Month | Month | Day of the Week | Meaning |
|---|---|---|---|---|---|
0 | 0 | * | * | * | Daily 00:00 |
20,40 | 3 | * | * | 5-6 | Every Friday and Saturday, always at 03:20 (AM) and 03:40 (AM). |
0 | 23 | */2 | * | * | Every second day at 23:00 |
20, 40 | 3 | * | * | 6-7 | Every Saturday and Sunday, always at 03:20 (AM) and 03:40 (AM) |
0 | 18 | 31 | 12 | * | Every 31st of December at 18:00 |
30 | 23 | 1,28 | */2 | * | On the first and 28th of every second month at 23:30 |
Backup Retention, Backup Removal
If you are configuring backup jobs that are executed on a regular basis, you must be aware that the increasing number of backups will also increase the amount of consumed space on your configured storage!
Because each configured backup can perform multiple backup jobs at either a single timestamp or at recurring time stamps, due to different execution triggers, the number of backups in the list will increase. However, you may not wish to keep all created backups. In order to more easily differentiate the importance of your backups, you can assign individual user tags to add meaningful information to your backups.
To protect your firewall/CC from consuming too much backup storage space, the edit field Retain last is preset with the value '5', and all other fields are left empty. An empty field has the intrinsic default value of '0'. This preset will ensure that the last 5 backups will be kept.
If you want to keep all backups indefinitely, set all Retain fields (e.g., last, hourly, daily, weekly, monthly, yearly) to '0'. Modify any of these fields to meet your individual retention requirements. As soon as one of these limits is exceeded, all backups that surpass the limit will be deleted automatically.
However, if you want to keep certain backups indefinitely, you can make use of your individually configured user tags. By configuring a retain tag, all backups having the same value in a user tag will be exempted from automatic deletion.
Monitoring and Restoring Backups
You can monitor your backups and their state at CONTROL > Backups. There are two views that provide all relevant information on all backup files and on the result of an action that was executed on each triggered backup:
Backup Overview
The Backups view displays a list of all configured back ends, their names, the levels of the configured backups (e.g., Box, Control Center, Box & Control Center), the tags that can attribute a backup, and the creation time.
Backup Jobs
The Backup Jobs view displays a list of all processed backups grouped by the Backup Job ID.
By expanding the entry for a Backup Job ID entry, the list displays all associated backup jobs that have been triggered by the configured execution trigger. The time-related columns show the beginning and end time stamps and the Result column shows the current state of a triggered backup job.
A backup job can be attributed to the following states:
Success – A backup job has been successfully completed.
Pending – A backup job is scheduled for execution.
Failed – A backup job has failed.
The Description column provides further details that refer to the signal state of the entry in a row. These details should be informative enough in most cases. At times, however, you may want to know more about what happened during a certain phase. In such cases, even further details can be found in the log box_Config_backup.log.
For more information on how to create scheduled backups, see How to Create and Monitor Backups Using the Backup Daemon.
Restoring Backus
Restoring a backup is done by locating the required backup and triggering the process for restoring it onto the related firewall.
For more information on how to configure the backup daemon and how to restore backups, see How to Restore/Delete Backups Using the Backup Daemon.