Best Practices

Performing Backup of File System iDataAgent Installed on a Domino

If you have File System iDataAgent installed on an Domino, you should first edit your file system backup filter to exclude the Domino databases. This prevents Notes files from being backed up together with the file system. Also, exclude the transaction log directory from file system backups.

A full File System backup should be run once a week while an incremental backup should be run everyday except on the day of the full backup.

Note that the open files in the data directory is skipped by the file system backup of the Domino. If a file is being backed up when an application tries to write to it, then the application will wait to write its changes until the backup completes. These files are usually very small in size.

Transaction Logging

Logging methods should not be changed once the software has been installed. Else, this may result in unexpected behavior when the data aging operation is performed.

  • Keep the transaction log on a separate partition or drive.

  • Use the largest log drive possible or at least 4 to 5 times larger than your observed daily usage to safeguard against media contention situations.

  • It is a Domino best practice to back up transaction logs every two hours. After the backup server has backed up a log file, the file gets marked for reuse by Domino. This ensures that the log volume does not fill up.

  • Make sure the speed of logs being archived is faster than that of new logs being created. Otherwise, the total log size will increase over time.

  • Enable transaction logging in Archive mode for database-level backups. Transaction logging in Archive mode provides the best backup possibilities over all the other modes (like, Linear, Circular and Disabled).

  • Make sure that the Domino first writes the database changes to the transaction logs and then to the database. This results in performance increase as linear writes to the logs are faster than random writes to the database. This also allows point-in-time restores as the logs can be replayed after the database has been restored.

  • Enable the automatic fix of corrupt databases.

  • For advanced restore options like Change Database Instance ID (DBIID) and Change Database Replica ID to work as expected, set the Transaction logging in Archive mode.

Frequency of Running Backups

It is a Domino best practice to back up transaction logs every two hours and a Full backup every week.

Change Database Replica ID Option during the Restore Operation

If the Change Database Replica ID option is selected in the Restore Options dialog box, replication ID will be changed during the restore operation. Due to this, the database may not get replicated during replication operations with other Domino. So, we recommend that you do not select this option if you plan to replicate this database after the restore operation is complete.

Restoring Databases to Their Original Locations

If the first partition of the Domino Server on the destination computer is running and you want to restore databases to their original locations, only databases that are not open (such as, non-system databases and those not opened by a user) can be restored. If the server is shut down, all databases can be restored to their original locations.

Creating Multiple Subclients to Reduce Backup Time

If the setup is huge (like having more than 2K mailboxes, 1 TB database and 500 TR logs/day), then it is useful to split the database into multiple subclients. This will reduce the backup time considerably by running the backups on all the subclients simultaneously. However, your server should be powerful enough to tolerate the load of all the backups running simultaneously.

Domino That Use DAOS

If deferred deletion is configured, the interval time should be set to a period longer than the period between backups. For example, if backups are performed once every two weeks, the deferred deletion interval should be set to 15 days or longer. This setting can be specified in the server document's Defer deletion of DAOS objects in n days option.

DAOS.CFG file is not backed up by the Notes iDataAgents. However, you can back up this file using the File System iDataAgent.

Domino Configuration Files and Attachments (DAOS) Backup

It is a best practice to configure separate subclients for backing up Domino Configuration Files and Attachments (DAOS). Note that these files are not picked up if the subclients are configured for auto discovering databases by specifying the folder patterns.

Do not enable IntelliSnap on the subclients that are used to back up DAOS.

Configuring Subclients for Automatic Folder Level Discovery

If databases are frequently added in the folders, then it is advised to configure subclients for automatic folder level discovery rather than running a manual discovery each time a database is added.

Run IntelliSnap Backup to Reduce Backup Time

If the databases are stored on snap arrays, then it is recommended to run an IntelliSnap backup as it reduces the backup runtime exponentially when compared to the traditional backup runtime.

Reconfiguring Default Subclient Content

We recommend that you do not re-configure the content of a default subclient as this would disable its capability to serve as "catch-all" entity for the client data. As a result, the likelihood that some data will not get backed up or will not get scanned for archive would increase.

Upgrade Recommendation from 32-Bit Domino to 64-Bit Domino

We recommend you to follow any of the two methods mentioned below to upgrade a 32-bit Domino to a 64-bit Domino.

Method 1

Post upgrade, you will be required to maintain only the 64-bit server.

  1. Restore all the data to the existing 32-bit Domino Server that you want to upgrade.

  2. Build a 64-bit server and migrate all the databases and mailboxes to the new server.

  3. Uninstall Commvault from the 32-bit server setup and delete the client from the CommCell Console.

  4. Install Commvault on the 64-bit server setup and perform all the data protections operations.

Method 2

In case you wish to maintain the server ID, Cert ID and the admin ID of the 32-bit Domino on the 64-bit Domino follow the steps given below to upgrade the 32-bit server to 64-bit and also maintain both the server versions:

  1. Uninstall Commvault from the 32-bit server setup.

    Note

    Do not delete the client from the CommCell Console.

  2. Install Domino on the 64-bit server computer and use the Server ID, Cert ID and the Admin ID of that of the 32-bit server.

  3. Install Commvault on the 64-bit server setup.

  4. Install the Notes Database iDataAgent (read only) on the 32-bit server.

  5. Perform a cross-machine restore from the 32-bit server to the 64-bit server.

  6. Migrate databases to the 64-bit server.

Ensure that the link folder contains at least one empty file in it. This is to prevent the automatic deletion of the link folder by Domino, which happens when the link folder is empty.

Notes Database Restore Consideration

In a Domino environment, data restored on one server will not propagate to other servers within the Domino environment. The restored databases will be overwritten by the existing databases during replication. If you do not want the databases to be overwritten, from the Restore Options dialog box, select the Disable Replication check box before running a restore job.

For more information, see Disabling Replication of Restored Databases.

Shut Down the Domino Server

If the Domino Mailbox Archiver is installed on the client where you plan to install the service pack, shut down the Domino server to avoid errors during the installation.

Do Not Backup DAOS Objects

While upgrading client from V10 to V11, You are not required to use File System agent to back up DAOS objects, because DAOS backup is available in V11.

Note

To create a subclient in V11, while discovering databases, DAOS objects appear as "SYSTEMFILES" -> "ATTACHMENTS\\DAOS\*" .

Loading...