Domain backup and rename: Difference between revisions

From SambaWiki
No edit summary
Line 5: Line 5:
Samba backups provide a way to recover your Samba network, in the unlikely event that a catastrophic failure of the domain occurs. For more details on the different types of Samba backups and how to use them, see [[Back up and Restoring a Samba AD DC]].
Samba backups provide a way to recover your Samba network, in the unlikely event that a catastrophic failure of the domain occurs. For more details on the different types of Samba backups and how to use them, see [[Back up and Restoring a Samba AD DC]].


One of the backup options involves renaming the domain (see [[Domain rename tool]]). Note that this works completely differently to the Windows tool for renaming domains, i.e. rendom. Windows renames each DC one at a time in situ. Whereas the Samba approach is to take a renamed copy of the domain, and start re-adding DCs again from scratch.
One of the backup options involves renaming the domain (see [[Domain rename tool]]). Note that this works completely differently to the Windows tool for renaming domains, i.e. <code>rendom</code>. Windows renames each DC one at a time in situ. Whereas the Samba approach is to take a renamed copy of the domain, and start re-adding DCs again from scratch.


=== How to configure it ===
=== How to configure it ===
Line 27: Line 27:
=== How to test it ===
=== How to test it ===


The main samba-tool backup/restore tests are run using:
<pre>
<pre>
make test TESTS=blah
make test TESTS="domain_backup"
</pre>
</pre>


However, a lot of the backup/restore functionality is testing by running testenvs created by doing a backup and then a restore. These testenvs are: restoredc, renamedc, labdc, and offlinebackupdc (which reflect the different backup use-cases). These testenvs are created by backing up a dedicated backupfromdc. A small subset of tests are then run against these testenvs to verify that they're functional. New tests were added to specifically sanity-check the restored DB is consistent with the original (ldapcmp_restore) and that you can do a basic join to the new testenvs (join_ldapcmp).
''<Anything else notable about running the tests...>''


=== Where the code is located ===
=== Where the code is located ===

Revision as of 03:32, 20 September 2018

Overview

Added in Samba version: v4.9

Samba backups provide a way to recover your Samba network, in the unlikely event that a catastrophic failure of the domain occurs. For more details on the different types of Samba backups and how to use them, see Back up and Restoring a Samba AD DC.

One of the backup options involves renaming the domain (see Domain rename tool). Note that this works completely differently to the Windows tool for renaming domains, i.e. rendom. Windows renames each DC one at a time in situ. Whereas the Samba approach is to take a renamed copy of the domain, and start re-adding DCs again from scratch.

How to configure it

Use the samba-tool domain backup set of commands to create a backup-file. There are three flavours of backup to choose from: online, offline, and rename. Then use samba-tool domain backup restore to restore the backup-file. Generally, you'll need to run the backup/restore commands as root. See Back up and Restoring a Samba AD DC for more details.

Known issues and limitations

The most important concept to grasp is you're taking a backup of your entire domain, not an individual DC. So restoring the domain is essentially completely replacing the existing domain DCs.

You can't restore the domain to the default install location (i.e. /usr/local/samba). You have to specify a new DC during the restore, i.e. one that is not already in the domain. See our recommended strategy for how to deal work around these problems.

See bug #13621 in Samba bugzilla for current issues in v4.9.0.

Troubleshooting

See Troubleshooting.

For Developers

How to test it

The main samba-tool backup/restore tests are run using:

make test TESTS="domain_backup"

However, a lot of the backup/restore functionality is testing by running testenvs created by doing a backup and then a restore. These testenvs are: restoredc, renamedc, labdc, and offlinebackupdc (which reflect the different backup use-cases). These testenvs are created by backing up a dedicated backupfromdc. A small subset of tests are then run against these testenvs to verify that they're functional. New tests were added to specifically sanity-check the restored DB is consistent with the original (ldapcmp_restore) and that you can do a basic join to the new testenvs (join_ldapcmp).

Where the code is located

<Notable files/functions to start looking at...>

Reference Docs

<E.g. Microsoft specification/section that describes the feature in more detail>