Backup¶
Zentyal configuration Backup¶
Zentyal offers a backup service, critical to ensure the recovery of a server when a disaster happens, for example a hard disk failure or a human error managing configurations.
Backup Screen
Backups can be made locally, saving them in the local hard drive of the Zentyal host. After this, it is recommended to save them in an external physical support, so if the machine suffers a failure, we can access to this data.
It’s also possible to make these backups in a remote host, since they are included in the subscription services provided by Zentyal. Both the Professional Subscription and the Enterprise Subscription, part of the commercial offering of Zentyal, include these configuration backups. Likewise, the Basic Subscription [1] , totally free and designed for test environments of the Zentyal server, also includes the remote configuration backups. With any of this three options, in case a server failure or human error causes a problem with the configuration, we can always recover it quickly from the Zentyal repositories in the cloud.
| [1] | http://store.zentyal.com/serversubscriptions/subscription-basic.html |
To access the backup options, we can go to System ‣ Backup. We cannot back up if they are non saved changes in the configuration, as we can see in the warning message from the figure:
Configuring the backup
Once we have entered the Name for the backup, choosing the desired type (incremental or full) and clicking on Backup, we will see a window which will show the progress of the different modules until we reach the message Backup successfully completed.
Afterwards, if we return to the former window, we will see in the bottom part of the page a Backups list. Using this list we can restore, download to client disk or delete any of the saved copies. Additionally , we will have informative data about the copy type, the creation date and size.
In the section Restore backup from a file we can send a security copy file that we have previously downloaded, for example, associated with a former Zentyal server installation in another host and restore it using Restore. We will be asked for confirmation, we have to be careful, cause the current configuration will be completely overwritten. The restoration process is similar to the copy, after showing the progress, the user will be notified with a success message if there is no error.
CLI tools for the configuration backup¶
There are two CLI tools available that will also allow us to save and restore the configuration. You can find them in /usr/share/ebox, they are called using ebox-make-backup and ebox-restore-backup.
ebox-make-backup allows us to make configuration backups, among its options we have choosing the typo of backup we want to execute, and also the configuration report that will help developers to diagnosis a sending failure with extra information. Note that in this mode, the user’s passwords are replaced for better confidentiality. The configuration report can also be generated from General ‣ Configuration report in the web interface.
We can see all the options of the program with the parameter –help.
ebox-restore-backup allows us to restore configuration backup files. It also has an option to extract information from the file. Another interesting option is the possibility of making partial restorations, only of the selected modules. This is the typical case when we want to restore part of the configuration of an old copy. It’s also useful when the restoration process has failed for any cause. We have to have special care with the dependencies between modules. For example, if we restore a copy of the firewall module which depends on a configuration of the module objects and services, we have to restore these first. Even then, we have the option of ignoring dependencies, which can be useful if used with care.
If we want to see all the options of this program we can also use the parameter –help.
Backup configuration in a Zentyal server¶
First of all, we have to decide if we are going to store our backups locally or remotely. In the last case, we need to specify which protocol is going to be used to connect the remote server.
Configuration
- Method:
The different supported methods are FTP, Rsync, SCP, Zentyal Cloud, File system. We have to take into account that depending on the method we choose, we will have to provide more or less information. All the methods except File system use remote servers. If you select FTP, Rsync or SCP, you will have to enter the associated authorization to connect with the server and the remote server’s address.
Zentyal Cloud is the Zentyal Disaster Recovery Service [2] whose usage guarantees your most critical data is backed up, secured, monitored and recovered easily quickly in case of a disaster. In order to use this service, you must obtain a Professional or Entreprise Subscription.
[2] https://store.zentyal.com/other/disaster-recovery.html
Warning
If we use SCP, we have to run sudo ssh user@server and accept the server fingerprint in order to add to the list of servers known by SSH. If we don’t perform this operation, the backup will not be possible, because the connection with the server will fail.
Host or destination:
For remote methods we have to enter the remote server name or its IP address with the following format: other.host:port/existing_directory In case we are using File system, we only need the local directory path.
- User:
- User name to authenticate in the remote host.
- Password:
- Password to authenticate in the remote host.
- Encryption:
- We can cypher the data in the backup using a symmetric key that will be entered in the form, or we can use a GPG key already created to perform asymmetric cyphering in our data. The GPG keyring is got from ebox user.
- Full Backup Frequency
This parameter is used to determine the frequency for the complete backups to be performed. The values are: Only the first time, Daily, Weekly, Twice a month and Monthly. If Weekly, Twice a month or Monthly is selected, we will see a selection to choose the exact day of the week or month to perform the backup.
If Only the first time is selected, then it is mandatory to set a frequency for incremental backups.
- Incremental Backup Frequency
This value sets the frequency of the incremental copy or disables it.
If the incremental copy is enabled, we can choose a Daily or Weekly frequency. In the latter, we have to decide the day of the week, anyway we have to take into account the chosen frequency has to be greater than the full backup.
The days that we have a scheduled full backup, Zentyal won’t perform any scheduled incremental copy.
- Backup process starts at
- This field is used to set when the process of backup copy is started, both the full one and the incremental one. It is a good idea to set it to a time frame where no other activities are being performed in the network, because it can consume a lot of upstream bandwidth.
- Keep previous full copies
This value is used to limit the total number of copies that can be stored. We can limit by number or by age.
If we limit by number, only the set number of copies, plus the last complete copy will be stored. If we limit by age, we will only save full copies that are newer than the indicated period.
When a full copy is deleted, all the incremental copies associated with it are also deleted.
Configuration of the directories and files that are saved¶
The default configuration will perform a copy of all the file system except the files and directories explicitly excluded. In case we are using the method File system, the destination directory and all its contents will be excluded as well.
We can set path exclusions and exclusions that match a regular expression. Exclusions by regular expression will exclude any path which matches the expression. Any excluded directory will also exclude all its contents.
In order to refine further the backup contents, we can also define inclusions, when the path matches with an inclusion before it matches with an exclusion, it will be included in the backup.
The order of application of inclusions and exclusion can be changed using the arrow icons.
The default list of excluded directories is: /mnt, /dev, /media, /sys, /tmp, /var/cache and /proc. It’s a bad idea to include any of this directories, because it may cause the backup process to fail.
A full copy of a Zentyal server with all its modules but without user data fill around 300MB.
Inclusion and Exclusion list
Checking the status of the backups¶
We can check the backups status in the section Remote Backup Status. Within this table, we can see the type of backup, full or incremental and the execution date.
Backup status
Restore files¶
There are two ways of restoring a file. Depending on the file size or the directory we want to restore.
It is possible to restore files directly from Zentyal Server’s control panel. In the section Backup ‣ Restore files we have access to the list of all the files and directories that are contained in the remote backup, and the dates of the different versions we can restore.
If the path to restore is a directory, all its content will be restored, including subdirectories.
The file will be restored with its contents on the selected date, if the file is not present in the backup that day, the version found in the former backups will be restored. If there is no copy of the file in any of the versions, it will be notified with an error message.
Warning
The files shown in the interface are the ones that are present in the last backup. The files that are stored in former copies but not in the last one are not shown, but they can be restored using the command line.
We can use this method with small files. For big files, the process is time consuming and we cannot use the Zentyal web interface while the operation is being made. We have to be specially careful with the type of file we are restoring. Normally, it will be safe to restore data files that are not being used by applications at that moment. This data files are located in the directory /home/samba. On the other hand, restoring system file of directories like /lib, /var or /usr while the system is running can be very dangerous. Don’t do this unless you are really sure of what you are doing.
Restore a file
The big files and the directories and system files should be restored manually. Depending of the file, we can do it while the system is running. On the other hand, to rescue system directories, we will use a rescue CD, as will be explained afterwards.
In any case, we must become familiar with the tool used by this module duplicity [3]. The restoration process of a file or directory is very simple. We execute the following command:
duplicity restore --file-to-restore -t 3D <file or directory to restore> <remote URL and arguments> <destination>
| [3] | duplicity: Encrypted bandwidth-efficient backup using the rsync algorithm <http://duplicity.nongnu.org/>. |
The -t option is used to select which date we want to restore. In this case 3D means three days ago. Using now we can restore the most updated copy.
We can obtain <Remote URL and arguments> reading the note that is included above the section Restore files in Zentyal.
Remote URL and arguments
For example, if we want to restore the file /home/samba/users/john/balance.odc we will execute the following command:
- # duplicity restore –file-to-restore home/samba/users/john/balance.odc
- scp://backupuser@192.168.122.1 –ssh-askpass –no-encryption /tmp/balance.odc
The command shown above will restore the file in /tmp/balance.odc. If we need to overwrite a file or a directory during a restore operation, we need to add the option –force, otherwise duplicity will refuse overwriting files.
How to recover from a disaster¶
As important as knowing how to make backups is to know the procedure and skills to perform a recovery during a critical event. We have to be able to restore the service as soon as possible when the system is rendered non operative by a disaster.
To recover from a total disaster, we will boot the system using a rescue CD-ROM that includes the backup software duplicity, for example grml [4]
| [4] | grml <http://www.grml.org/>. |
We will download the grml image and will boot the host with it. We can use the parameter nofb in case we experience problems with screen size.
Grml boot.
Once the boot process is finished, we can go to a command line interpreter pressing enter.
Starting a command line interpreter
If our network is not correctly configured, we can execute netcardconfig to configure it.
The next step is to mount the hard drive of our system. In this case, let’s suppose that our root partition is /dev/sda1. We will execute:
# mount /dev/sda1 /mnt
The former command will mount the partition in the directory /mnt. In this example we will perform a complete restore. First, we will delete all the existing directories in the partition. Obviously, if we don’t do a complete restoration, this step is not needed.
To delete all the existing files before the restore we will execute:
# rm -rf /mnt/*
We will install duplicity if we don’t have it available:
# apt-get update
# apt-get install duplicity
Before doing a complete restore, we need to restore the /etc/passwd and /etc/group. Otherwise we may have problems restoring files with an incorrect owner. The problem appears because duplicity stores the usernames and groups and not the numerical values. Thus, we will have problems if we restore the files in a system where the users and groups have differente UID or GID. To avoid this problem, we will overwrite /etc/passwd and /etc/group in the rescue system. Execute:
# duplicity restore --file-to-restore etc/passwd \
# scp://[email protected] /etc/passwd --ssh-askpass --no-encryption --force
# duplicity restore --file-to-restore etc/group \
# scp://[email protected] /etc/group --ssh-askpass --no-encryption --force
Warning
If we use SCP, we have to execure sudo ssh user@server and accept the server fingerprint in order to add to the list of server known by SSH. If we don’t perform this operation, the backup will not be possible, because the connection with the server will fail.
Now we can proceed with the complete restore running duplicity manually:
# duplicity restore scp://[email protected] /mnt/ --ssh-askpass --no-encryption --force
Finally, we have to create the excluded directories, and clean the temporary directories:
# mkdir -p /mnt/dev
# mkdir -p /mnt/sys
# mkdir -p /mnt/proc
# rm -fr /mnt/var/run/*
# rm -fr /mnt/var/lock/*
The restoration process is finished and we can boot in the original system.
Restoring services¶
Apart from the files, additional data is store to allow the direct restoration of some services. This data is:
- security copy of Zentyal configuration
- security copy of the registers database of Zentyal
In the tab Service restoration both can be restored for a given date.
The security copy of Zentyal configuration contains the configuration of all the modules that have been enable at least once at any moment, all the LDAP data and any other additional file needed for the functioning of the modules.
You have to be careful when restoring Zentyal configuration, cause all the current configuration and LDAP data will be replaced. Nevertheless, for the case of configuration non stored in LDAP, we have to click in “Save changes” to make it effective.
Restoring services