Lotus Domino Backup Strategy

Lotus Domino Backup Strategy

Introduction LOTUS DOMINO BACKUP STRATEGY White Paper 1 You've worked hard to put your Domino security shield in place. You've set up your firewall, Access Control Lists, and anti-virus protection. Still, you must assume that eventually you'll face a data loss crisis. It may be the result of an error; users have a tendency to hit that delete key at the worst possible moment. It may be a virus that bypasses your defenses. It may be a hardware failure or some other completely unforeseen event. So what do you do when you need to restore Domino data? A well-designed backup plan can give you peace of mind and confidence that you can restore Domino functions and recover critical data. Domino Backup Requirements Because it's a database system, Domino differs from traditional file servers. In traditional server systems, users open and use files during business hours, and administrators run backups during off-hours. In contrast, Domino servers work actively with their databases at all times. Even when users aren't accessing their mail files, Domino may be compacting those files, re-indexing views, or delivering mail. By default, most backup software skips open files (files that are in use). That's usually acceptable on a file server because very few files are open at backup time. However, any effective backup software that you run with Domino must support open files. If it doesn't, you risk more than just losing backups of open databases; the backup software could corrupt databases and even cause server crashes. Another key difference between file servers and Domino servers is that Domino servers don't handle incremental backups very well, if at all. Incremental backups record only changes that have occurred in files on the server since the last full backup. Incremental backup products check file timestamps to determine whether files have changed. Because Domino database files can change many times in a day for many reasons (e. g., agents, mail delivery, new records), an incremental backup product may back up the Domino server's entire content every day. Full, not incremental, backups are the norm for Domino servers (unless you use transaction logging and the new R5 backup API, which I'll describe in a moment). Domino is also very sensitive to locked files. Backup software often locks files when starting a backup to ensure that no other processes or programs try to use them during the backup cycle. If the software doesn't successfully release the locks, Domino can't access those files. This failure results in an error message that's familiar to many administrators: "The database is currently being used by someone else. In order to share a Notes database, all users must use a Notes Server instead of a File Server." It's not a good thing when your CEO receives this message the morning after a server backup. Make sure that your Domino backup software supports backup without locking files.

Backup Strategies LOTUS DOMINO BACKUP STRATEGY White Paper 2 There are several generally accepted strategies for Domino backup. Probably the least effective is replication. This method involves replicating important databases among servers to ensure that a live backup of the information is readily available. Relying only on replication is risky because deletions and corruptions can replicate just as well as good data. In addition, some critical files (e. g., Notes. INI, server IDs) don't replicate. If a hard drive fails and you don't have a backup of those files, you're in trouble. Shutdown/ Backup. Some Domino network administrators replicate the most important databases on the network to a single large Domino server that functions only as a backup hub and has no users connected to it. These administrators use a third-party backup program or a combination of batch files and the Windows Scheduler to automatically shut down and back up the server at the end of the day. This method ensures full daily backups of critical databases but has two disadvantages: it requires dedicating a server, and it doesn't back up the critical nondatabase files on the rest of the Domino network. A sure way to accomplish a full backup of a Domino server is to shut down the Domino server program before performing the backup. This action ensures that the database files are not in use. The downside, of course, is that bringing down a Domino server isn't acceptable in businesses that require mail and applications to be always accessible. If you do choose this strategy, you'll need an automated way to shut down the Domino process, perform the backup, and restart Domino or reboot the server. Many backup software programs let you run an operating system command before and after the backup runs against the server. I caution you not to use Program documents in the Domino Directory to schedule a shutdown or backup of your Domino server. Lotus specifically recommends against this approach because it produces inconsistent results. The problem is not that Program documents are inconsistent, but that control and completion of external commands is inconsistent. For example, if the shutdown of the server doesn't complete, backup and restart are usually unsuccessful. A complete Domino shutdown is important for all backup procedures that use this method. A good way to ensure that Domino is completely shut down on Windows is to use a batch file that not only commands Domino to shut down but also kills any outstanding Domino tasks that might hang on shutdown. Open-file Backup. If your Domino servers don't use transaction logging (a technique that I'll describe in a moment), the best (but most expensive) solution for Domino backups is an enterprise software package with components designed specifically to back up open files on Domino servers. These packages enable centralized backup of all the Domino servers in your network without taking them offline.

LOTUS DOMINO BACKUP STRATEGY White Paper 3 Transaction Logging and the R5 Backup API All the backup solutions I've described to this point assume that your Domino servers don't use transaction logging (TL), a new feature in Domino R5 that captures the changes users make to databases and writes them to a transaction log rather than directly to the databases. Domino waits until server loads are low before writing the transactions to the databases. When configured correctly, TL benefits Domino servers by speeding up system performance and enabling faster server restarts, enhanced data integrity, and simplified backup procedures. Domino R5 also features a new backup API that it uses in conjunction with TL. TL comes in two flavors: Archive logging. This requires a third-party backup solution compatible with the R5 backup API. Archive logging builds transaction logs and doesn't delete them until the third-party product backs them up via the API. This method captures all transactions in the Domino environment; it's the most comprehensive type of TL backup and recovery. Lotus recommends archive logging, but it isn't the default. Circular logging. This is the default, but Lotus discourages its use in favor of archive logging. With circular logging, you don't need a third-party backup solution that's compatible with the API. However, this method doesn't offer the advanced restoration capabilities that archive logging does. The R5 backup API has four components: 1. Online full backup. This utility flushes the database image to disk. It can back up databases that are in use and can even capture changes made during the backup cycle. 2. Online incremental backup. This is used only with archive logging. It backs up transaction logs daily, and the logs serve as incremental backups of the Domino system. Once Domino has backed up the logs, it deletes them. 3. Online restore. This feature automatically disables the existing database and brings a backup copy online. 4. Online media recovery. This backup utility uses the transaction logs to roll database transactions forward to a restored database. Note that administrators can't use these utilities directly; third-party backup software vendors use these features to build Domino R5-specific backup procedures into their products.

Choosing the Best Backup Solution LOTUS DOMINO BACKUP STRATEGY White Paper 4 All the backup solutions I've described here can work well. However, archiving TL with a backup product that supports the R5 API is by far the best solution. The API lets the backup software use Lotus's hooks to communicate with Domino and provide a backup and restore system that's even more reliable than software designed to handle open files. You have many options for backing up your Domino network because Lotus has decided to leave backup product development to third parties. But with transaction logging and the new backup API for R5, you now have a clear first choice. Organizations that don't implement transaction logging or can't afford the high cost of the third-party software that supports the backup API may opt for lowercost procedures such as shutdown/ backup or open-file backup. Regardless of the route your organization takes, make sure you have a good understanding of the options and procedures for effectively using your chosen tools, and you'll be ready when disaster strikes. itco Solutions Corporation P.O. Box 610090 Redwood City, CA 94061 United States http://www.itcosolutions.com/ Enterprise Sales Team Contact Ryan Edwards National Accounts Manger Tel: 650-367-0514 E-Mail: redwards@itcosolutions.com