I'm reviewing our backup/restore scripts and processes. The
directory in question has a single suffix containing about 41,000
entries. It has a single R/W instance, with several R/O replicas,
running 389-Directory/1.4.4.
Working with on-line data, if needed, we could turn one of our
R/O instances into a R/W, and create some new replication
agreements. Or, we could build a new R/W instance, and populate it
by exporting the required information from a R/O instance. We'd
have additional work to do with certs, DNS, and hostnames to put
the finishing touches on.
To make an off-line backup of our R/W instance, we have a scripted process which does:
- dsconf userdata backup create
- dsconf userdata backend export
makes a tar of those and the contents of:
- /etc/dirsrv/slapd-userdata (to pick up certs and scheme
extensions)
and parks the resulting .tar in a safe place for a couple of months.
My questions are:
- After looking this over, I don't see that we are capturing
cn=config
Is that implicit in the dsconf 'backup'? Are we just missing it? If so, how best to capture the objects we want from it? - Does the answer change as we shift to 389-Directory/2.1.8 ?
-- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston@xxxxxxxxxx Department of Administration State of Alaska
-- _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
