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
What could possibly go wrong?
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.
What to back up?
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?
- LDAP databases
- TDB databases
- configuration file smb.conf
- group policies
Next, I would like to show you which tools and mechanisms Univention Corporate Server (UCS) already provides to secure important files in your domain.
Daily LDAP and Samba Backups
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.
