> 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.
> 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/126.96.36.199 - 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:
# 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
> Job Cacka
> 389-users mailing list
389-users mailing list
Post a Comment