Novell EDIRECTORY 8.8 SP3, Administration Manual, Page: 485 / 634

Backing Up and Restoring Novell eDirectory 485
n
ov
do
cx (e
n)
11
Ju
ly 20
08
12. The restore verification is successful, so the database opens, back in its original tree.
The restore verification was successful because roll-forward logs were running on the server
when the hard drive failed, and Jorge included the logs in the restore.
13. Jorge re-creates the roll-forward logs configuration on the server after the restore is complete,
then he creates a new full backup.
The settings are reset to the default during a restore, which means roll-forward logging is
turned off, so he has to turn it back on. The new full backup is necessary so that he is prepared
for any failures that might occur before the next unattended full backup is scheduled to take
place.
Jorge checks the way the server is running, and it appears to be normal.
16.10.3 Scenario: Losing an Entire Server in a Multiple-Server
Environment
Bob is the administrator for 15 servers at GK Designs Company. He does full backups every
Saturday night and incremental backups nightly, running the eDirectory backup shortly before the
file system backup to tape.
All of the servers are participating in replica rings. Bob uses roll-forward logging for all the servers.
An electrical fire destroys one of the servers in a branch across town. Fortunately, all but one of the
partitions held by this server are also replicated on other servers. Bob had turned on roll-forward
logs on that server, but they were lost along with all the other server data, so he can't restore the
eDirectory database on that server to the state it was in just before the server went down.
However, he is able re-create the server's eDirectory identity by restoring with the existing backup
files. Because Bob can't include the roll-forward logs in the restore, the server does not match the
synchronization state that the other servers expect (see
“Transitive Vectors and the Restore
Verification Process” on page 435 ), so the restore verification process is not successful. This means
that by default the eDirectory database is not opened after the restore.
Bob addresses the situation by removing this server from the replica rings, using DSRepair to
change all the outdated replica information on the server to external references, and then re-adding a
new copy of each partition to this server using replication from the other servers that hold the up-to-
date replicas. (These steps are described in
Section 16.9, “Recovering the Database If Restore
Verification Fails,” on page 477 .)
The one partition on this server that Bob had not replicated was a container that held network
printing objects for the branch office location, such as a fax/printer and a wide-format color printer.
This partition information can't be recovered by the method noted above because no other server has
a replica. Bob must re-create the objects in that partition, and this time he chooses to replicate them
on other servers for better fault tolerance in the future.
Bob also re-creates the roll-forward log configuration after the server is back on line (because the
restore turns it off and resets the settings to the default), and creates a new full backup as a baseline.