Fedora directory users - Apr 2007 - Restoring an LDAP backup to a different server db2bak

Every night I run a db2bak.
Can this backup be safely restored to a different server? using bak2db?

Eddie C wrote:
> Every night I run a db2bak.
> Can this backup be safely restored to a different server? using bak2db?
If it is a configuration server (having NetscapeRoot in db), it cannot 
be, unfortunately.  And of course, the base suffix (or suffixes) should 
be identical between the 2 servers.

El lun, 09-04-2007 a las 14:22 -0400, Eddie C escribió:
> Every night I run a db2bak. 
> Can this backup be safely restored to a different server? using
> bak2db?
It won''t.

I had to do a restore by necessity, and here''s what I had to do (by
Noriko Hosoi''s gracious recommendation):

1. on the current directory server, export the data into ldif files.
  go to your <server_root>/slapd-<id>; run "db2ldif -n
<backend>" for each backend (e.g., userRoot) EXCEPT NetscapeRoot
2. install new FDS
3. go to the <new_server_root>/slapd-<id>
4. stop the directory server
5. import the ldif files from the current directory server
  repeat "ldif2db -n <backend> -i
<server_root>/slapd-<id>/<date_time>.ldif" for each
<date_time>.ldif file exported in (1).
6. start the directory server

The issue is documented in this thread:
https://www.redhat.com/archives/fedora-directory-users/2007-February/msg00024.html

The NetscapeRoot instance is server-specific, and it won''t restore
properly on a new server.
-- 
Oscar A. Valdez

I have tried this before without luck. I was hoping there was a way. My
situation is I have nightly db2bak files. I want to recover the database
from friday to a different machine to see the state of the application then.
I do not need much other then read only access to the old data on the new
server.

Any crafty hacks would be appreciated.

Edward




On 4/9/07, Noriko Hosoi <nhosoi@redhat.com> wrote:
>
> Eddie C wrote:
> > Every night I run a db2bak.
> > Can this backup be safely restored to a different server? using
bak2db?
> If it is a configuration server (having NetscapeRoot in db), it cannot
> be, unfortunately.  And of course, the base suffix (or suffixes) should
> be identical between the 2 servers.
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>

El lun, 09-04-2007 a las 14:48 -0400, Eddie C escribió:
> I have tried this before without luck. I was hoping there was a way.
> My situation is I have nightly db2bak files. I want to recover the
> database from friday to a different machine to see the state of the
> application then. I do not need much other then read only access to
> the old data on the new server.
>  
> Any crafty hacks would be appreciated.
>  

Write a script that runs "db2ldif -n <backend>" for each backend
(e.g.,
userRoot) EXCEPT NetscapeRoot

On the new server, import the ldif files generated above: "ldif2db -n
<backend>"
-- 
Oscar A. Valdez

Unfortunately I only have the db2bak from the day I need to restore. No ldif
files. And I need to restore them to a new server. I do not need all the
configuration data. I only need two of our data trees.





On 4/9/07, Oscar A. Valdez <oscar.valdez@duraflex.com.sv>
wrote:
>
> El lun, 09-04-2007 a las 14:22 -0400, Eddie C escribió:
> > Every night I run a db2bak.
> > Can this backup be safely restored to a different server? using
> > bak2db?
>
> It won''t.
>
> I had to do a restore by necessity, and here''s what I had to do
(by
> Noriko Hosoi''s gracious recommendation):
>
> 1. on the current directory server, export the data into ldif files.
> go to your <server_root>/slapd-<id>; run "db2ldif -n
<backend>" for each
> backend (e.g., userRoot) EXCEPT NetscapeRoot
> 2. install new FDS
> 3. go to the <new_server_root>/slapd-<id>
> 4. stop the directory server
> 5. import the ldif files from the current directory server
> repeat "ldif2db -n <backend> -i
<server_root>/slapd-<id>/<date_time>.ldif"
> for each <date_time>.ldif file exported in (1).
> 6. start the directory server
>
> The issue is documented in this thread:
>
https://www.redhat.com/archives/fedora-directory-users/2007-February/msg00024.html
>
>
> The NetscapeRoot instance is server-specific, and it won''t restore
> properly on a new server.
> --
> Oscar A. Valdez
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Eddie C wrote:
> Unfortunately I only have the db2bak from the day I need to restore. 
> No ldif files. And I need to restore them to a new server. I do not 
> need all the configuration data. I only need two of our data trees.
Once again, do your backed up server and the new server share the same 
set of suffixes not including NetscapeRoot (if you have o=netscaperoot 
on the servers, you can''t use this trick)?  If the answer is yes, you 
could restore the back-up onto the new server.

If the answer is no, did you run "db2bak" when the server was down? 
If
yes, theoretically you could do as follows.

    cd slapd-<newserver>  ## please make sure the new server already has
    corresponding root suffixes / backend to be restored.
    ./stop-slapd
    rm -rf db/*
    Repeat the command line for each backend to be restored:
    ./bak2db <full_path_to_backup_dir> -n <backendname>
    (e.g., bak2db /opt/fedora-ds/slapd-<id>/bak/2007_04_09_14_46_14/ -n
    exampleRoot; bak2db
    /opt/fedora-ds/slapd-<id>/bak/2007_04_09_14_46_14/ -n userRoot)
    ./start-slapd

But I remember it did not work as expected when Oscar experimented for 
us...  If it does not work, you may need to try what Oscar suggested.
Thanks,
--noriko
 
> On 4/9/07, *Oscar A. Valdez* <oscar.valdez@duraflex.com.sv 
> <mailto:oscar.valdez@duraflex.com.sv>> wrote:
>
>     El lun, 09-04-2007 a las 14:22 -0400, Eddie C escribió:
>     > Every night I run a db2bak.
>     > Can this backup be safely restored to a different server? using
>     > bak2db?
>
>     It won''t.
>
>     I had to do a restore by necessity, and here''s what I had to
do (by
>     Noriko Hosoi''s gracious recommendation):
>
>     1. on the current directory server, export the data into ldif files.
>     go to your <server_root>/slapd-<id>; run "db2ldif -n
<backend>"
>     for each backend (e.g., userRoot) EXCEPT NetscapeRoot
>     2. install new FDS
>     3. go to the <new_server_root>/slapd-<id>
>     4. stop the directory server
>     5. import the ldif files from the current directory server
>     repeat "ldif2db -n <backend> -i
>     <server_root>/slapd-<id>/<date_time>.ldif" for
each
>     <date_time>.ldif file exported in (1).
>     6. start the directory server
>
>     The issue is documented in this thread:
>    
https://www.redhat.com/archives/fedora-directory-users/2007-February/msg00024.html
>    
<https://www.redhat.com/archives/fedora-directory-users/2007-February/msg00024.html>
>
>     The NetscapeRoot instance is server-specific, and it won''t
restore
>     properly on a new server.
>     --
>     Oscar A. Valdez
>
>
>     --
>     Fedora-directory-users mailing list
>     Fedora-directory-users@redhat.com
>     <mailto:Fedora-directory-users@redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

OK, I found a stragegy that worked.

I took vmware and prepared a virtual machine. I did the RPM install of the
same directory server 1.0.4. that was installed on the old server. Luckily I
had retrospect on the machine. I used restrospect to do a full disk restore
of the old system onto the new one.


I stopped networking on the server first for fear that the system would
start up and try to join the live systme and corrupt data.

The server did startup but the data was not as it was that day. This was
probably due to the fact that retrospect backed up open files of the FDS.

That is ok though. I also had been running db2bak every night. I used
back2db.pl to restore one of the backups over the current. Then I ran
db2ldif and moved the ldif files out. Then I did an rpm -e fedora.1.0.4.

Then I reinstalled FDS again and used the ldif to restore the data.

The long way around. Having VMWare was nice because I was able to shut down
networking but still access the VMWARE console from the network. :)

Edward
  On 4/9/07, Eddie C <edlinuxguru@gmail.com>
wrote:
>
> Unfortunately I only have the db2bak from the day I need to restore. No
> ldif files. And I need to restore them to a new server. I do not need all
> the configuration data. I only need two of our data trees.
>
>
>
>
>
> On 4/9/07, Oscar A. Valdez <oscar.valdez@duraflex.com.sv > wrote:
> >
> > El lun, 09-04-2007 a las 14:22 -0400, Eddie C escribió:
> > > Every night I run a db2bak.
> > > Can this backup be safely restored to a different server? using
> > > bak2db?
> >
> > It won''t.
> >
> > I had to do a restore by necessity, and here''s what I had to
do (by
> > Noriko Hosoi''s gracious recommendation):
> >
> > 1. on the current directory server, export the data into ldif files.
> > go to your <server_root>/slapd-<id>; run "db2ldif -n
<backend>" for each
> > backend (e.g., userRoot) EXCEPT NetscapeRoot
> > 2. install new FDS
> > 3. go to the <new_server_root>/slapd-<id>
> > 4. stop the directory server
> > 5. import the ldif files from the current directory server
> > repeat "ldif2db -n <backend> -i
> > <server_root>/slapd-<id>/<date_time>.ldif" for
each <date_time>.ldif file
> > exported in (1).
> > 6. start the directory server
> >
> > The issue is documented in this thread:
> >
https://www.redhat.com/archives/fedora-directory-users/2007-February/msg00024.html
> >
> >
> > The NetscapeRoot instance is server-specific, and it won''t
restore
> > properly on a new server.
> > --
> > Oscar A. Valdez
> >
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
>
>