ShowTable of Contents
Table of Contents
Within a Lotus Domino environment, there are different restore scenarios:
- A full system restore - Which is required to recover from a disaster like a complete hardware or site failure.
- A restore of one or more database - Replacing the existing one or more databases.
- Restore of one or more documents within a database.
In general, the data restore technology depends on the scenarios. Also, the server type and the backups available are of interest.
The following table lists different type of data and the tools involved in the restore process:
|
|
|
|
|
File backup software, e.g.TSM client
|
|
|
File backup software, e.g.TSM client
|
|
|
Certified Domino Backup utility, e.g. TDP
|
In addition to the table above, Domino servers where transaction logging is enabled requires:
|
|
|
|
|
Your certified Domino Backup utility, e.g. TDP
|
|
|
Your file backup software, e.g.TSM client
|
DAOS enabled transaction logs require a different tool to backup the DAOS storage directory. DAOS stores attachments separately from the database files, and are not backed up with the traditional backup and restore products.
Transaction log files use a product external to Domino for backup and restores. Without transaction logging, DAOS and NSF may both use flat file recovery.
Three parts of a restore process can be distinguished:
- Disaster recovery
- Static file recovery
- Domino data file recovery
Disaster Recovery
This process is to restore a whole Domino server by recover all files and directories. A prerequisite for this process is to have a fully recovered operating system with all registry and configuration settings.
One disaster recovery scenario is to perform a bare-minimum-restore, which means to recover all software to a blank piece of hardware. Here the main challenge is to restore the operating system so that it is fully functional as before. How to do this depends on your server’s operating system and your configuration. Consult the operating system vendor as well as your backup software vendor for more detailed instructions.
If you can not bring the original server back online, for example, because of an hardware failure or similar problems, consider restoring Lotus Domino to a different hardware. Domino itself is not forced to use the same operating system or the same hardware. Lotus Domino can be moved if you take some items into consideration. IBM Technote 1087009 http://www-01.ibm.com/support/docview.wss?rs=899&uid=swg21087009 describes how to move a Lotus Domino server from one hardware to anther. The same concept can be used in case of a disaster recovery to rebuild the server on a different hardware than before.
As soon as operating system and installed operating system applications are recovered, it is time to restore Lotus Domino. For this to be done, tools and processes used for disaster recovery are described in the next two sections.
Static File Recovery
Static files are Domino program files and files in the Domino data without Domino databases and templates. In our example, the TSM client will be used to restore these files.
It is possible to restore the most recent backup or a file from a specific date, given that it is still retained within the backup. This restore process is not different than restoring a file from a file server.
Because Domino is constantly using some of the files within the program directory, when restoring Static Domino files, consider shutting down Domino before restoring the static files.
Domino Data File Recovery
Individual restores might be requested from users, for example, to restore a particular database (.nsf file) for a specific point in time from the backup environment. Users typically expect to get access to the data in the same way as before.
To accomplish different data restore, the following strategies are available:
- Stand-alone - Provides the restore in the form of a stand-alone application. It is accessible for users. The user needs to find and restore individual Notes documents.
- Merge - Restore data back into production by merging current data with the restored data.
- Replace - Replace the current application completely with the .nsf file obtained from the backup.
Each of these options is described in the following sections.
Stand-alone Restore
For a stand-alone restore, Domino Administrators provide the restored data so that the user can get access without impacting the data in production.
Although it sounds simple, there are small challenges which administrators need to be aware of for the restored databases:
- Restored databases are not any different from production databases when it comes to their functionality.
- Restored databases can and will run scheduled background agents (if not explicitly disabled).
- Have the same ACL and will therefore immediately allow users to access this file (if not configured otherwise).
- Restored database can replicate (if not configured otherwise).
For restoring Domino data files, TDP/TSM is used in this example. On Lotus Domino servers without transaction logging enabled in archive mode, TDP recovers one or more designated files from the TSM server.
In general, replication will be disabled for this restored database by the restore process (TDP/TSM) automatically, so restoring back to the server where files have been backed up is the preferred method, however there are cases where this is not possible e.g. because an old server has been switched off.
The Domino data file recovery is a three-stage process:
- Restore one or more data files. It is possible to restore the files under a different name, in a different directory or to a different server. (See figure 1 below). Domino data file restore can cover the most recent versions or a specific date for the files to recover.
- Activate the Domino data files. This function brings restored databases online for use by the Domino server. It is optional to apply transactions from the transaction log to update the database. Transactions can be applied up to a specific point in time or up through the most recent changes recorded in the transaction log. If archival logging is in effect, TDP for Lotus Domino automatically restores archived transaction log files as needed.
- After transaction log restore is completed and Domino database restore is therefore complete, TDP provides a list of DAOS Files that must be restored to complete the restore. Restore of the DAOS files is done using the TSM Client.
TDP restores Domino data files at the database level. To restore single documents, the entire database must be restored. Afterwards the documents can be copied to the original database using the Notes client.
Perform Single Database Restore
To prevent the most common mistakes, figure 1 illustrates a flowchart that provides assistance for defining the most efficient restore method and defining your restore target.
Note: The flowchart should be used as a reference only. It should not be mapped onto your environment as-is because every environment is unique and there are many things need to take into account that we might not mentioned here.
|
|
Comments and considerations
|
1 |
Is the database you are trying to restore encrypted?
For details see the database properties and encryption settings.
|
2 |
On the server where the backup was taken, is (or was) DAOS enabled on this server?
Check the server document DAOS tab for details
|
3 |
On the server where the backup was taken, is (or was) DAOS encryption enabled?
Note: DAOS Encryption is enabled by default unless you have explicitly configured your server to not encrypt DAOS objects (*.NLO files). This can be beneficial if you want to be able to restore back to server other than the restore was taken from.
|
4 |
In this situation, you must restore the database back to the server where the backup was taken. The server ID must be the same because the database itself or its DAOS objects are encrypted with this server ID. Restoring to a different server is not possible.
|
5 |
Although it is more efficient to restore a database back to its original server, there are environments where corporate policies request the usage of a dedicated restore server.
In this scenario, you can – if you want - restore this database to a different server.
|
6 |
Restore the Domino NSF file(s) using your backup and restore software. Make sure all of the following items are checked before you continue:
- Change the replica ID. Some backup software can do that as part of the restore process. If not, you have to do this manually!
- Disable replication. Some backup software can do that as part of the restore process. If not, refer to IBM Technote 1094568
- Disable scheduled agents, by enabling this check box in the database properties of the restored file.
- (Optional) change the ACL of the restored file so that only the requestor can get access.
|
7 |
|
8 |
Open the restored database (or request users to do that) and restore the documents requested.
|
9 |
If the restored database(s) are no longer required, delete them from the server.
|
Merge Restore with Production
Once a database has been restored using the method described above, you might want to merge data restored with the one currently available in production.
Clearly, merging a restore with production is NOT a recommended method because documents which have been deleted in the production replica will leave a deletion stub. So replicating a restored version of the same database will NOT restore the deleted document.
Although those deletion stubs can be removed, there might be local replicas of the same database for example, on the users desktop which also contain those deletion stubs. Removing deletion stubs as described in IBM Technote 1095683 will not remove them in other replicas. Result: Deletions will be performed again once you clear the replication history.
Replace Production Database with Restore
If you need to replace a production mail file or application database with a restored version of the same file, you can of course delete the production database and store the .nsf file which was restored as a single database restore (see above) to the same folder and file name.
Note this will not work if:
- You are attempting to restore a Domino system database; these files are in use by Domino and often require the ReplicaID to be consistent within a Domain. For technical details, refer to IBM Technote 1099635.
- As part of the restore process, you have changed the ReplicaID, but some (badly developed) custom applications require a specific ReplicaID to be used. Before changing the replicaID as you want it to have, think twice about the consequences!
Any user who got a replica of this file will replicate old content back to the server, including modifications you might not want to have.
When replacing a production database with a restore, evaluate using a different replica for the restored version. This prevents from old or modified content to replicate back into the restore.
Optimizing the Restore process
A restore process which is optimized for providing server availability and user satisfaction would run as an half automated process which can look like this:
- Restore the ,nsf file to a place outside of the Domino Data directory.
This will ensure the file would not replicate with other servers.
- A server side scheduled agent would open the database from this path outside the Domino Data directory and set the DB property “Disable background agents in this file."
The source code for such an agent can be found in IBM Technote 1380020. As an alternative, disable all scheduled agents as described in the end of IBM Technote 1201461
- To put back the database online and change the replica ID at the same time, use the Domino server command “Cluster Copy” , for example
> CL COPY C:\Restore\Filename.nsf RESTORE\filename.nsf
This command creates a non-replicating copy of the database “C:\Restore\Filename.nsf” in the new location “Restore\filename.nsf” below of the Domino Data directory.
For more details about this command and its usage, refer to this DominoWiki article
Note: for this command to be available, make sure to set the NOTES.INI variable CLUSTER_ADMIN_ON is set to 1
- (If required) change the ACL as needed.
Recommendations
In general, the following recommendations should be kept in mind when performing restores:
- If you want to use a dedicated server for your restores, consider to disable DAOS Encryption as described in this DominoWiki article
http://www-10.lotus.com/ldd/dominowiki.nsf/dx/DAOS_Deployment_Guide#Deciding+on+encryption+for+NLO+files
- Define AND test your emergency restore procedures on a regular basis.
- When restoring custom developed Domino applications, consult the application developer for specific details on how to restore individual documents without impacting the applications logic.
- Consider using specific file names which clearly indicate the point in time of a restore.
For example, . “Restore\2010-11-02\filename2009-12-01.nsf” indicating the file “filename.nsf” was restored on Nov. 2nd 2010 as it was on 1st of December 2009. Feel free to use your preferred method of naming files and folders, but make sure to use a consistent approach as this naming can be used for a cleanup script later on.
- Delete restored files when they are no longer required.
This can be automated with a small script if you define that any restore will be removed (e.g.) 7 days after it was provided.
- Configure your Domino servers to enable Cluster Administration command line options.
For more details, refer to this DominoWiki article.