On 05/02/2016 01:14 PM, Job Cacka wrote:
Today I attempted to restore the dirsrv-admin to a previous version.
I used this Documentation, "4.3.4. Restoring a Single Database" from Redhat's web site.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Backing_Up_and_Restoring_Data.html#Backing_Up_and_Restoring_Data-Restoring_a_Single_Database
I stopped the dirsrv-admin with:
# service dirsrv-admin stop
Shutting down dirsrv-admin:
[ OK ]
You must stop the Directory Server, not the HTTP Admin server(dirsrv-admin)
I ran the following from the location of the script:
# ./bak2db /var/lib/dirsrv/slapd-zigzag/bak/2013_10_14_14_14_13/ -n NetscapeRoot
[02/May/2016:09:59:38 -0700] 389-Directory/1.2.11.15 - debug level: backend (524288)
[02/May/2016:09:59:38 -0700] - Unable to import the database because it is being used by another slapd process.
[02/May/2016:09:59:38 -0700] - Shutting down due to possible conflicts with other slapd processes
The directory is not stopped, so the bak2db is aborted. To stop the
directory server use:
# stop-dirsrv
or
# service dirsrv stop
and since it looked like it failed I restarted the server with:
#service dirsrv-admin start
What did I do wrong?
Isn't NetscapeRoot the dirsrv-admin data?
No, dirsrv-admin is the HTTP administration server. The netscaperoot
data is stored in the directory server instance.
Should I plan on doing this after hours when I can stop both servers?
That is probably best, but the restore should be a quick process.
If this is the dirsrv-admin then how do I restore it?
If it is not the correct procedure then what is?
Your restore process looks okay, you just didn't stop the DS before
attempting it.
Mark
Thanks,
Job Cacka
--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
