Back up and Restoring a Samba AD DC

Revision as of 23:04, 9 August 2018 by Timbeale (talk | contribs) (Replace redirect with new content for backup/restore functionality added to master/4.9)




  • Online. This takes a clone of a running DC's DB. It's similar in functionality to joining a new DC to the network.


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?


  • 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 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.


Testing the backup restoration


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, if 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.

  • 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 ldbsearch (by passing the local filepath of the DB) to sanity-check DB objects were backed up correctly.
  • Another option is configure your network switches to 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:


Online DC backup

To create an online backup, use:

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


Offline/local DC backup




Domain rename backup


Restoring the domain


  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.

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:


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.