Procedure - leaving the Live DB in place
1: Restore the database to a separate location (no under the domino server data location) without including any NLO files.
2: Log on to a local admin client and turn off replication in the database replication settings
3: Place the data in a separate folder under the Domino server data location. This will mean the database will now be able to use the server based NLO files.
4: Local support can then assist the users in copying the lost information back into live.
5: Delete the restored Database and its location.
Procedure - Deleting the Live DB
1: Move the user over to the DR server if required.
2: Delete the live DB from the home server.
3: Restore the DB into the original location
4: Check to see if the missing attachments are available by opening the DB and try and open the attachments. (If the deleted / corrupt data is readable this would mean the deletion period of 30 days has not passed) if not:
5: Run the following command against the DB "tell daosmgr listnlo -o missing.txt MISSING restoreddatabasename.nsf" to work out what NLO files that need to be restored.
6:Restore the required NLO files into the DAOS file location.
7: Run "Fixup -j -D" on the DR servers DB.
8: Enable Replication and then replicate the DB from the live server.
DAOS Database Corruption in a Cluster
This section shows how the database can be replaced after deleting the corrupted database.
1. Replicate each entire NSF – New replicas can be created from the existing NSFs on the clustermate(s). Each new replica should be marked as DAOS enabled. As the replication occurs, the associated attachments will be saved to DAOS.
2. Copy NSFs, replicate missing attachments – All of the necessary NSFs are copied from the clustermate(s) to the server being repaired. This will create a copy of the document data without attachment data. Fixup -j -D is then run, deleting all documents that contain DAOS references to NLO files that do not exist. Subsequent replication will re-create those documents along with the associated attachments, which will be stored in DAOS.
3. Copy NSFs, copy/restore NLOs - All of the necessary NSFs are copied from the clustermate(s) to the server being restored. The command 'tell daosmgr listnlo missing somefile.nsf' is then issued for each individual NSF to generate a list of the NLO files that do not exist in the DAOS repository. Those NLO files are then restored from backup, or copied from the clustermate(s). (Note that copying the NLO files from another Domino server will work only if DAOS encryption is turned off. DAOS encryption is on by default, and uses the server key to do the encryption; therefore enc rypted NLO files are not portable between Domino servers.)
4. Copy full NSFs and re-extract – If you have a replica on another server that is not DAOS-enabled, the NSF can be copied to the server being restored. The attachments will be inline in that copy of the NSF, and 'compact -c -daos on' can be issued to extract the inline attachments out to DAOS.
5. Reintegrate NSFs and re-extract – If you have a replica on another server that is DAOS-enabled, but encryption prevents using the NLO files directly, you can run a 'compact -c -daos off' on the other server to re-integrate the attachments into the NSF. Once that is done, the NSF can be copied to the server being restored, and you can use 'compact -c -daos on' to extract the attachments to DAOS again.
How to determin what DAOS NLO files need to be restored for the corrupt Database
To determine which missing NLO files to bring back from the Domino server console, run
tell daosmgr listnlo -o missing.txt MISSING restoreddatabasename.nsf
Using the text file to restore the right NLO files
The resulting missing.txt file is then fed into the restore command With the Tivoli Storage Manager (TSM), the command would be.
dsmc restore -filelist=missing.txt -inact