Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
Do you administer any Windows machines in your UCS domain? Do you also use Samba to provide an Active Directory-compliant domain controller with a login service for the Windows clients? If the answer is yes, you may have wondered what backup and restore strategy is best suited for your environment. What data do you need to back up? How do you go about restoring a single domain controller (DC) in the event of an emergency? And what to do if the entire domain is affected by a failure?
In this article I would like to introduce you to different approaches to backing up and restoring Samba on UCS. Admittedly, this is a complex topic—so I’d like to encourage you to discuss any questions you may have with us and other UCS users in our forum.
Table of Contents
Admins usually have plenty of things to deal with—especially in larger environments with many computers, maybe even at distributed locations. There are many opportunities for incidents of all kinds. It doesn’t necessarily have to be an attack from the outside, for example with ransomware or another Trojan. A hardware failure, incorrect configuration or another bug can also cause individual systems or the entire domain to fail.
One of the reasons the whole thing is so complex is that the entire Active Directory domain database is distributed across multiple domain controllers. Strictly speaking, of course, there are several databases involved: a parent one that manages the user accounts, and on each DC there is also a local copy. In the background, Samba synchronizes the data regularly so that each domain controller is always up to date (replication).
In the “simplest” case, a single domain controller fails, but the rest of the domain runs flawlessly. This can happen if, for example, the local DC database becomes corrupted. In addition, each DC stores local information in its database which is not replicated—this can also lead to problems. If the rest of the domain is working, you can restore individual DCs and then rejoin them to the domain. After that, the DC replaces its corrupted local database copy with a new copy that is (hopefully) error-free.
Basically, there are different approaches. In addition to the classic file-based backup, some admins also rely on snapshots for data and system backups. Snapshots usually require less time, generate less load on the systems and reduce data traffic. While snapshot-based backups have their place in a backup strategy, they cannot replace file-based backups.
File-based backups should always be part of the overall backup strategy as additional insurance, because there are a number of things to consider when restoring snapshots. For example, all domain controllers must be reset at the same time—if this is not successful, they must rejoin the domain. In addition, restoring individual files from a snapshot is inconvenient, so it makes sense to back up specific files individually.
So, in case of an emergency, what data and settings do you need to restore a system or an entire domain?
Next, I would like to show you which tools and mechanisms Univention Corporate Server (UCS) already provides to secure important files in your domain.
Univention Corporate Server already comes with a few useful default settings regarding the backup of system-relevant data. A cron job backs up the contents of the LDAP directory on the primary directory node and on all backup directory nodes of your domain every day. By default, the cron job runs every night at midnight and calls the script /usr/sbin/univention-ldap-backup:
~# cat /etc/cron.d/univention-ldap-server
0 0 * * * root /usr/sbin/univention-ldap-backup
As a result, two backup files are created every night in the /var/univention-backup directory: a gzip-compressed LDIF file (LDAP Data Interchange Format) and a gzip-compressed log file. Both files are readable only by the root user.
If you are running Samba in your domain, another cron job backs up various files from the /var/lib/samba directory every night at 3 am. These backups are created by the /usr/sbin/univention-samba4-backup script, and the backup copies end up in the /var/univention-backup/samba folder.
In both cases, the respective backup scripts ensure that the backup files have a timestamp in their name, which is composed of the year, month and day.
The UCR variable backup/clean/max_age defines how long UCS keeps old backups. Since UCS 4.4-7, the default setting is 365. You can change the value via the Univention Configuration Registry, which you can access via the portal, System. If the variable is not set, no backups are deleted.
Two UCR variables control the two cron jobs for backing up the LDAP and Samba data. For the LDAP server this is the variable slapd/backup/cron, and for Samba 4 the variable samba4/backup/cron.
Note: Please do not edit the cron jobs under /etc/cron.d/ in a text editor, as the files may be overwritten by the Univention Configuration Registry.
The above-mentioned Samba backup script (/usr/sbin/univention-samba4-backup) first defines the source directory (/var/lib/samba) and then the target directory for the backup copies (/var/univention-backup/samba). First, the script takes care of the subdirectory private and checks if there are .ldb and .tdb files:
The tdbbackup tool, which is part of the Samba suite, creates backups of both file types and compresses them into .tar.bz2 archives; some exclude statements exclude a few file types. The Univention script also bundles files from the /var/lib/samba/sysvol directory into .tar.bz2 archives. Finally, the script removes old backups.
For most environments the backup script /usr/sbin/univention-samba4-backup and the default schedules should be sufficient. If you are missing something here and want to develop your own backup concept for Samba, then I recommend this article in the Samba Wiki. It provides not only an introduction to the topic, but also describes in detail different backup approaches (online, offline and rename) and how to restore a Samba Active Directory domain or a single domain controller in case of emergency.
As a general rule, you should regularly review any backup strategy—this includes restoring backups to a test environment.
How does your backup strategy look like for your domains? Do you use any tools and scripts other than the UCS tools? Feel free to discuss with us—either in the comments below this article or in the forum.
Julia successfully completed her apprenticeship as an IT specialist in application development at Univention in July 2021 and works now as a open source software engineer.