Difference between revisions of "Restoring the LDAP user database"

From sshcWiki
Jump to navigation Jump to search
m (Formatting)
(Added some more steps to the restore process)
Line 15: Line 15:
  
 
= Restoration =  
 
= Restoration =  
<i> Warning: Outline, not tested, not complete.</i>
+
<i>Still testing this.</i>
* Set up a new 389 server with the same directory name as the one you are restoring (TODO: Figure out if this is stored in the db2bak backup program output, and if not, fix the script to add that in)
+
* Add an entry into your hosts file that resolves dir.sshchicago.org org to your DR testing machine (or, if this is the new machine, reconfigure DNS to point to this system beforehand). Be aware that the setup process is rather noisy about the mismatch between the PTR record if you are using a hosts file.
 +
* Set up a new 389 server with the same directory name as the one you are restoring (TODO: Figure out if this is stored in the db2bak backup program output, and if not, fix the script to add that in)<br/>
 +
setup-ds-admin.pl General.FullMachineName=dir.sshchicago.org
 +
<br/>Accept all defaults, choose secure passwords.  This will create a new, empty directory server.
 
* Restore the backup using bak2db
 
* Restore the backup using bak2db
 
* Start 389 up
 
* Start 389 up

Revision as of 21:24, 24 August 2013

This outlines the steps necessary for restoring our LDAP server.

Data Recovery

Follow the steps in Restoring files with Duply to restore our LDAP backup from Amazon S3. Set these files aside somewhere safe.

Requisite Software Installation

rpm --install http://mirrors.xmission.com/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
  • Install a pile of packages for 389.

Be aware that this will also install a bunch of dependencies, including X11 and Java, so have sufficient disk space available. Not all of these are necessary, though I've listed them all for completion's sake

yum install 389-ds-console 389-dsgw 389-adminutil 389-ds-base-libs 389-admin-console \ 
389-ds 389-ds-base 389-admin-console-doc 389-ds-base-devel 389-console 389-admin \
389-ds-console-doc 389-adminutil-devel 

Restoration

Still testing this.

  • Add an entry into your hosts file that resolves dir.sshchicago.org org to your DR testing machine (or, if this is the new machine, reconfigure DNS to point to this system beforehand). Be aware that the setup process is rather noisy about the mismatch between the PTR record if you are using a hosts file.
  • Set up a new 389 server with the same directory name as the one you are restoring (TODO: Figure out if this is stored in the db2bak backup program output, and if not, fix the script to add that in)
setup-ds-admin.pl General.FullMachineName=dir.sshchicago.org


Accept all defaults, choose secure passwords. This will create a new, empty directory server.

  • Restore the backup using bak2db
  • Start 389 up

Testing

TODO: Write out how to validate that the restore worked properly

References

4.3. Backing up and Restoring Data - Red Hat Directory Server Administration Guide