Most backup and recovery products work at file (i.e. database) level, so if you delete a document by accident, then you have to restore the whole database. You probably don't want to overwrite all the documents in your database, so you need to restore to a different copy, in a non-replicating directory, or server. Your restored database will have the same replication id as the original, even if you have renamed it. That means that just after your restore completes, Notes comes along, checks that it is 'older' than the existing files in the cluster, and replicates over your restore. That gets a bit frustrating. Notes will only replicate within its Notes directory structure, usually under d:/notes/ However, as good a standard as any other, is a C:/RECOVERY directory, which hopefully gives itself away by name.

Once you have a restored copy, select the document you want with your space bar, use CONTROL^C to copy the document you want, then CONTROL^V to paste it back into the correct database. If your document is corrupt, you need to delete it first, then use the restore process above.
If you find your restores are not working, then its possible that you are restoring a database link, rather than the real database. If the database is very small, check it with an editor, to see if it just contains a path name. If so, then you want to restore the database the path is pointing to.

Notes is a Client-Server application, with a set of clustered servers. Terminology can be confusing when using Client-Server backup products such as TSM. In TSM terms, the TSM server is the server, and all the Lotus Notes Servers and Clients are TSM clients. If replication is used, then its probably best just to install client code on the Notes servers, and leave the Notes Clients to replicate their data to the servers (the Notes Servers, that is). You might also want to consider filtering out some of the big, active databases, on some of the servers to prevent replicants being backed up on every server. Then again, if you leave them all in, you should have at least one good backup.

TSM knows nothing about Domains, so the TSM client code must be installed on every Notes server.

Incremental Backup of Lotus Notes Documents

While the operating system knows nothing of the internal structure of a Notes database, the Lotus Backup Agent interfaces between the TSM API and the Lotus Notes API, so backup can take place at document level. This means you do not backup the whole database just because one document gets updated, and also you can recover individual documents within the database. However there is a price to pay.
The first incremental backup of any database will take a long time, much longer than if you simply backed it up as a database. It will also take proportionally longer to recover a full database from bits of incrementals. However, if the database is not too active, the Notes Agent can save a lot of time overall. If the database is very busy, loads of documents updated every day, its probably best just to stick to a full database backup, and be out the office when someone wants one document recovered.

TSM uses Exclude and Include lists to decide what to back up. There are a few quirks with these. As Notes uses Directory Links and Database Links to help users navigate between files on the server, when you select a database in a given directory, you have no way of knowing if it really is a database, or just a pointer to a database somewhere else (unless you examine the file with an editor). To handle the concept of virtual drives, you just make then all virtual. specify databases in Exclude lists as

    ?:\database.NSF\*

where '?' takes the place of the normal drive letter. The \* on the end of the database is compulsory. It means back up all the documents in the database. If you miss it off, you won't back up anything, which will save a bit of space in your TSM backup storage.
Did you notice that not only do we not specify c:/notes, we don't even specify ?:/notes/ Lotus Notes knows where it lives, you don't need to tell it. Remember, TSM include/exclude lists are processed from the bottom up, not top down.

Incremental backup works at document level, which means you can't specify individual databases in INCLUDE lists. You associate management classes with documents, not databases. Also, when the data gets to the TSM storage, the file space is no longer the drive name, now its the database name. The recovery command is different too. Its DSMNOTES, not DSMC.

The incremental backup facility does not replace a 'proper' backup, as it only gets Notes databases, and you will have lots of other files on the server which are precious to someone. Its best to run both types of backups as complements, along the old 'full weekly backup and incremental dailys idea. That should speed up full database recovery, as you can recover your database from the server backup, then roll forward using the incrementals.

When you delete a document, you leave a stub behind, which the system eventually cleans up. If you backup product has a 'how many backups to keep if the file is deleted' facility, then set it to greater than one, or you may end up just keeping a backup of the stub file.

Transaction Logging

Transaction logging was introduced in Domino 5, and improved in Domino 6. If it is enabled, then Domino does not write changes to the database, but writes them to a transaction log. This has performance advantages, as the log writes are all sequential, whereas database writes are very random. The records in the log are copied out to the databases at a later time.
From a recovery standpoint, this means that if your server crashes, Domino can automatically recover a database back to its state just before the crash, by applying records from the transaction logs. This means fewer restores from backup. You can also define logging so Domino automatically does a 'fixup' on recovery.
Its important to allocate the recovery logs correctly. They need to be on different disks to the databases, and should be on RAID devices as they are so critical. They are also best kept on dedicated drives, as they must perform well.
They can reduce backup storage requirements significantly, possibly by up to 90%, as they allow an incremental backup approach. You can backup your databases once a week, then just backup your transaction logs on a daily basis. Then if you need to recover, you restore the database, then apply the logs. If you use this approach, then be aware that the default mode for logging is 'circular', which means that once the log is full, Domino just starts to overwrite if from the beginning again. You must change this to 'archive logging', then the logs will not be reused until they have been backed up. All the backup and recovery processing can be simplified, if your product uses the Domino API.

VENDOR Showcase