Difference between revisions of "Back up and Restoring a Samba AD DC"

From SambaWiki
m (added category)
Line 72: Line 72:
For more details on creating a rename backup, see [[Domain rename tool]].
For more details on creating a rename backup, see [[Domain rename tool]].
=== Untarring backups ===
If you simply want to use the backup for forensic purposes (i.e. interrogating the details of specific DB objects in a 'good' state), then it's safe to just untar it and query the DB directly on disk. Note that you cannot start samba on an untarred backup - you ''must'' use the restore command to do this.
=== Restoring the domain ===
=== Restoring the domain ===

Revision as of 23:27, 9 August 2018


Samba backups provide a way to recover your Samba network, in the unlikely event that a catastrophic failure of the domain occurs.

There are a few different flavours of backup, which work in different ways and achieve different things:

  • Online. This takes a clone of a running DC's DB. It's similar in functionality to joining a new DC to the network.
  • Offline (or 'local'). This backs up the Samba files as they appear on disk. This includes replication meta-data that's local to this particular DC and which is not included in online backups. It can also create a backup file when the DC is offline (i.e. the samba process is not actually running).
  • Rename. This produces a backup file with the domain renamed, and is intended as only a temporary replacement.

These different types of backup have several things in common. The backups are all produced using a variant of the 'samba-tool domain backup' command. Each command creates a .tar.bz2 backup-file which contains an entire backup of the domain (based on a given DC). The backup-file can then be used to restore the domain using the 'samba-tool domain backup restore' command.

Note that the backup-file is a backup of your domain, not your DC. Restoring the backup-file will create a brand new DC with your domain's information. To restore subsequent DCs you must then join fresh new DCs to the restored DC.

So which backup should I use?

This is a difficult question to answer, as it somewhat involves predicting how your Samba domain will fail. It also depends on how you plan to react to the failure. By creating a backup, you may be trying to achieve one of several different objectives:

  • Provide temporary replacment DC(s), which will buy you time while you troubleshoot and fix the problems on your original Samba network.
  • Provide a long-term replacement for your domain, i.e. you plan to completely discard your failed domain and rollback to the last backup taken.
  • Provide forensics on why the domain failure occurred in the first place, e.g. if a DB corruption occurred, what factors may have led to the problem?
  • Provide a 'good working state' DB that can be used as a guide for repairing and recovering deleted or corrupted objects in the production DB.

The rename backup works best for providing a temporary replacement domain, however, it is no good as a long-term replacement for the domain. Normally you can't run restored DCs and troubleshoot the failed domain DCs at the same time, because both will be using the same domain name (which will cause even more wild and weird problems to appear in your network). However, because the renamed backup is using a different domain name, it means you can safely run both the restored domain and the original domain in parallel.

The online backup works best for providing a long-term replacement for your domain. It can be used as a temporary replacement, but you cannot easily troubleshoot the failed domain DCs at the same time. Investigating the reason behind the failure of a Samba domain could be time-consuming and technically complex work. If, in the event of a catastrophic domain failure, you don't intend to investigate the problem and just want to revert back to a older copy of a working domain, then this is the best option for you.

The offline backup works best for forensics purposes, as it contains additional data that is not normally replicated. However, note that the offline backup-file contains all the sensitive/secret information for your entire domain, so you still may not be able to share this backed-up information easily with samba developers or mailing-lists. Also note that because the backup is copying the actual DB on disk, there is potentially more chance that a corruption in the DB is copied through to the backup.

If you want to create multiple different types of backups, note that the details of the backup are saved in a 'backup.txt' file within the backup-file itself.

Testing the backup restoration

The often overlooked step in any disaster recovery plan is testing that your recovery system actually works before you need to put it into practice. Creating the backup-file is not much good if samba fails to start up on your restored DC.

Note that the backup/restore commands are new to Samba v4.9, and there may be something specific to your network which means they don't work as well as intended. It's better to find any problems now (and report them to the samba mailing-list), rather than in an emergency.

Unfortunately, testing a samba backup is hard to do. Because the online and offline backups use the exact same domain information as your production network, it is not safe to run samba on a restored backup - the restored DC will interfere with your production network traffic.

Here are a few options to help you gain confidence that your samba backup will actually be useful.

  • If you're generating a 'rename' backup, then it's always safe to restore the backup-file onto a new DC and start samba on it. So you can always sanity-check that your rename backup works successfully. A rename backup is quite similar to an online backup, so if your rename backup works, then you can have some confidence that your online backup would probably work too.
  • It's always safe to restore the backup-file to disk, as long as you don't actually start samba on the restored DB. You could then use tools like ldbsearch (by specifying the local filepath of the DB on disk) to sanity-check DB objects were backed up correctly.
  • If you just want to get a better feel for what the various backup options do, one option is to create a samba lab-domain, and then create and restore online/offline backups within the lab domain itself.
  • Another option is configure your network switches to completely isolate the restored DC from the rest of your samba network, although in practice this proves quite tricky to get right.

Note that the backup tool creates a 'warts and all' copy of the domain DB. If you don't run dbcheck over your Samba DB regularly, then it's worth getting into the habit, especially before you generate a new backup. Otherwise, any problems in your DB will persist right through a backup and restore of your domain. Dbcheck will report any obvious problems that exist in your DB, and provides a '--fix' option that will resolve the problems for you. To run it, use:

samba-tool dbcheck -H ldap://<DC-server> --cross-ncs

Online DC backup

To create an online backup, use:

sudo samba-tool domain backup online --target-dir=<output-dir> --server=<DC-server> [admin-creds]

This command can be run locally on the DC or remotely. If running the command remotely, you may want to specify a --configfile option so that the correct smb.conf settings get included in the backup.

Offline/local DC backup

To create a offline backup, login on the DC you're backing up, and simply specify the target-directory location to write the backup-file to. E.g.

sudo samba-tool domain backup offline --target-dir=<output-dir>

Note that despite this option's name, the DC does not actually need to be offline when running this command. The tool is simply backing up the local files and it has sufficient locking in place to ensure the backup is generated safely.

Domain rename backup

For more details on creating a rename backup, see Domain rename tool.

Untarring backups

If you simply want to use the backup for forensic purposes (i.e. interrogating the details of specific DB objects in a 'good' state), then it's safe to just untar it and query the DB directly on disk. Note that you cannot start samba on an untarred backup - you must use the restore command to do this.

Restoring the domain

In the event of a catastrophic domain failure, to restore the domain from backup-file you would do the following:

  1. Stop samba on all the old DCs. (Unless you're using a renamed backup, in which case you can skip this step).
  2. Run the 'samba-tool domain backup restore' command to restore the domain DB on a single new DC. See below for more details.
  3. Start samba on the new DC.
  4. Add any further DCs to the network by joining them to the restored DC, e.g.
    samba-tool domain join <dns-realm> DC --server=<restored-dc>
  5. If you're using a renamed backup, you would then need to re-configure your network appliances so that traffic is redirected to the restored domain, instead of the failed/original domain.

Restoring the backup-file

The step to restore a backup is similar to the 'domain provision' you did back when you first setup your Samba network, except this time the backup contains all the DB objects you've added since then. Similar to doing a provision, you need to specify a new DC when you run the restore command. This new DC must not have existed previously in the samba-network. The restore command will look something like:

sudo samba-tool domain backup restore --backup-file=<tar-file> --newservername=<DC-name> --targetdir=<new-samba-dir>

Note that the target-directory specified must be empty (or non-existent). This means it's not practical to restore the domain DB back into /usr/local/samba. Instead, we recommend that you restore the domain DB into a different targetdir, and then use the '-s' (or '--configfile') option when running samba, e.g.

samba -s <targetdir>/etc/smb.conf

Specifying the restored smb.conf will mean that samba will use the DB files in the correct location.

If you really want the samba DB files to reside in /usr/local/samba then you would have to restore to another directory and manually move the restored directories back into /usr/local/samba. Note that you would need to take care updating smb.conf to make sure the filepaths are correct.

Before starting samba on the restored DC, you should double-check the restored smb.conf settings are correct. It may also be helpful to run samba_dnsupdate (although this still gets run automatically when you start samba).