Daos

DAOS for Notes and Domino 8.
ii
DAOS for Notes and Domino 8.5
Contents
DAOS on Notes and Domino 8.5 . . . . 1
DAOS: DAOS: DAOS: DAOS: Exercise Exercise Exercise Exercise 1. . . . . . . . . . . . . 1 2. . . . . . . . . . . . . 7 3 . . . . . . . . . . . . 12 4 . . . . . . . . . . . . 16 DAOS DAOS DAOS DAOS Exercise 5 Exercise 6 Exercise 7 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 25 29 48
iii
iv
DAOS on Notes and Domino 8.5

Overview, objectives, and requirements of the DAOS on Notes and Domino 8.5 course.
Overview
One of the most significant features introduced for the Domino 8.5 server is DAOS: Domino Attachment and Object Service. As the name suggests, this optional feature gives administrators the ability to consolidate the storage of attachments. As a result, the DAOS functionality is sometimes described as attachment consolidation. DAOS has two primary benefits: 1. Reducing the disk space consumed when attachments are posted to multiple documents and databases on the same Domino server. 2. Reducing the time (I/O) needed to route mail and to perform other server tasks that are impacted by database size (such as compacting). In this course, you will learn to use and troubleshoot DAOS.
Audience
Intermediate-level Domino administrators
Time required
It should take approximately 7 hours to complete all the lessons in this course.
Prerequisites and system requirements

To successfully complete this course, you will need: v A understanding of basic Domino Administrator tasks (e.g. registering users, using mail.box, replication) v A Notes and Domino 8.5 environment with two servers configured in the same domain. v Five registered test users. v Headphones. Learning objectives The DAOS for Notes and Domino 8.5 course covers the following topics. Objectives for each topic are listed in the corresponding exercise.
DAOS: Exercise 1
This exercise covers enabling DAOS on the server and in mail files for space savings.
Introduction
In this exercise, you enable DAOS on your IBM Lotus Domino 8.5 server, enable a set of mail files to use DAOS, and then observe the reduction in disk space that results from DAOS when sending the same attachments to multiple users on the same server.
Time needed
This exercise takes approximately 45 minutes to complete.
Objectives
After completing this exercise you should be able to perform the following tasks: v Configure your Domino 8.5 Server for DAOS. v Demonstrate that the server is configured for DAOS by a show server command. v Configure future databases to be ODS 51 by adding to the Notes.ini parameter Create_R85_Databases=1. v Use a load compact command to simultaneously upgrade all your existing users mail files to ODS 51 and configure them to use DAOS. v Observe DAOS in operation by sending e-mails with attachments to several users and displaying the .NLO files created on your server. There are three parts to this exercise. Complete each part in the order listed below:
Exercise 1, Part 1: Enabling DAOS on the server

Follow the steps below to enable DAOS on your Domino 8.5 server. If you need further detailed instructions, refer to the Notes and Domino 8.5 Information Center.
Activity
1. Add the following string to the notes.ini file on the Domino server: Create_R85_Databases=1. This parameter configures the Domino server to create new Notes applications using the Notes and Domino 8.5 ODS (On Disk Structure). By default, new applications in both Domino 8.0 and 8.5 are created with an ODS of 43 unless an .ini parameter is in place. For more detail, refer to Technote 1267844.. 2. Perform the following steps to enable transaction logging for the Domino server: a. Edit the Domino Server document. b. Navigate to the Transactional Logging tab. c. In the Basics section, change Transactional logging to Enabled. A message will display advising you to place the log files on a separate drive. This is not necessary in a test environment. d. Set the Maximum log space to 2000 MB. If you leave this field blank, you receive an error when trying to save the Server document. The error explains that an entry is required and that the minimum recommended value is 192 MB. e. Accept all the other defaults. f. Save and close the Server document. g. Restart the Domino server for the change to take effect.
h. As the server is restarting, you will see console messages that reflect this change. This is correct behavior. This process can take several minutes. In some cases, it can appear as though the server is not processing. Give it a another minute or two. 3. Perform the following steps to enable DAOS in the servers Server document: a. In the Domino Server document, navigate to the DAOS tab. b. In the field for enabling DAOS, specify Enabled. c. Accept the default minimum object size and DAOS base path (the Domino\data\daos directory). d. Save and close the Server document. e. Restart the Domino server. Applications on this Domino server can now use DAOS. 4. In the Domino server console, enter the show server command. The command reports the status of DAOS. Enabling DAOS in the server document results in the following changes: v There is now a DAOS folder located beneath the servers Domino\Data folder: ...Domino\Data\DAOS. This is the default location of the consolidated object store repository. v The DAOS Catalog (DAOScat.nsf) has been created. You will learn more about DAOScat.nsf in a subsequent exercise. If you do not see the DAOScat.nsf listed on the Files tab in your Domino Administrator, restart the Administrator client.
Note: Enabling DAOS within a Domino Server document does not configure any databases to use DAOS. Administrators and database managers choose which applications participate in DAOS. In the next part of the exercise, you will configure both new and existing mail files to use DAOS.
Summary
You can continue with Exercise 1, Part 2: Configuring Mail files to Participate in DAOS
Exercise 1, Part 2: Configuring Mail files to Participate in DAOS

Follow the steps below to configure the specified mail files to use DAOS.
Activity
1. Perform the following steps to enable DAOS in a newly created mail file: a. Log in to the Domino server as an administrator b. Register a new user and give them editor access to their mail file. Leaving the access at Editor ensures your administrator is set as Manager. c. Access the newly created mail file. On the Database Info tab, note that the ODS version indicates 51. This is a result of the notes.ini parameter you configured in Part 1 of this exercise. d. On the Advanced tab, under Advanced options, select Use Domino Attachment and Object Service.
Note: Only administrators can enable DAOS. An individual user, even with Manager access, cannot turn on participation of DAOS for their own mail file. 2. Perform the following steps to make sure that databases that do not have the 8.5 ODS cannot be configured to participate in DAOS: a. Access the administrators mail file. b. Display the application properties. v On the Database Info tab, note that the ODS version is 43. v On the Advanced tab, under Advanced options, observe that there is no visible option to Use Domino Attachment and Object Service. 3. Enable DAOS for existing users mail files in one of the following ways: v Update all applications at the same time. Open the Domino server console and enter the following syntax to run compact: load compact mail -c -daos on. This updates the ODS and activates the use of DAOS for all applications. v Update applications individually. Update the applications ODS ?HOW?, and then enable participation in DAOS either by specifying Use Domino Attachment and Object Service in the Advanced database property, ?OR? in the Files tab in the Domino Administrator client. 4. Perform the following steps to confirm that the administrators mail file is configured to use DAOS: a. Access the administrators mail file. b. Display the application properties. c. Click the Database Info tab, make sure that the ODS version is 51. d. Click the Advanced tab, and then under Advanced options make sure that the application is configured to Use Domino Attachment and Object Service.
Summary
You can continue with Exercise 1, Part 3: Observing the space savings with DAOS
Exercise 1, Part 3: Observing the space savings with DAOS

Follow the steps below to send e-mails with attachments and observe the space savings that results from using DAOS.
DAOS compression
Domino already manages attachment compression. DAOS itself does not compress data in any way. The decision to compress data is made when you attach the data. From the client, when you attach a file you see something like this dialog box. (Compress is the default).
If the Compress checkbox is selected, the attachment will be compressed before it is sent to the server for storage. Depending on the database properties for this database this will either be Huffman compression or LZ1 compression.
The most important thing from a DAOS perspective is that all the mail files use the same type of compression. If different types of compression are used, you could end up with one master copy of the LZ1 attachment and one master copy of the Huffman attachment. This is because DAOS recognizes them as different and unique file attachments based on their checksums.
Activity
1. Verify that the Domino servers mail.box is configured for DAOS: a. Select mail.box in the files tab b. Click File Application Properties c. On the Database Info tab, verify the ODS version indicates 51V. d. On the Database Properties tab, verify Disable transaction logging is not checked e. On the Database Properties tab, verify Use LZ1 compression for attachments is checked f. On the Database Properties tab, verify Use Domino Attachment and Object Service is checked 2. Register 5 test users. 3. Open your Administrators mail file and send a single memo to all users with an attachment of about 3000Kb.
4. Using Windows Explorer, navigate to the DAOS folder and observe that an additional subfolder has been created and that within it resides an .NLO file that corresponds to the attachment you just sent. Keep the Explorer window open. 5. Return to your Administrators mail file to send two more memos to all users. The first memo should have two attachments of about 10Kb and 20Kb each. The second memo should have one attachment of about 50Kb. 6. Switch to back to Windows Explorer and observe the activity in the \Domino\Data\DAOS\0001 folder. You will see the expected .NLO file for each attachment. You will also see an additional, temporary copy of each .NLO file. Once DAOS determines that an .NLO file exists for a given attachment, the additional .NLO file is removed. If you are unable to see the temporary NLO files, repeat Step 4 to send another set of memos with the same attachments to the same recipients. 7. Return to your Administrators mail file to send a final memo. Send one memo to only yourself with an attachment of no more than 2.5Kb. 8. Switch back to Windows Explorer and examine the consolidated object store repository on the server. There should be 4 .NLO files even though you have sent a total of 5 attachments. Why only 4 .NLO files? Because the last attachment you sent (the one less than 2.5Kb) is too small to be saved to the consolidated attachment store repository. This is based on the default settings you accepted in the server document when enabling DAOS in Part 1 of this exercise.
Summary
You have successfully completed this exercise when you have: v Configured your Domino server for DAOS. v Enabled future databases to use ODS 51. v Upgraded your user mail files to ODS 51 and to use DAOS. v Observed DAOS in operation by sending e-mails with attachments to several users and displaying the .NLO files created on your server. You can continue with DAOS: Exercise 2.
DAOS: Exercise 2
This exercise covers enabling DAOS on mail.box to improve router I/O.
Overview
As you learned in the introductory presentation, DAOS can also improve router I/O. To gain this additional benefit from DAOS, you enable DAOS on mail.box. Once this configuration is in place, mail.box writes an .NLO file once. Any time mail.box handles an email that points to an existing .NLO file, it routes only the small ticket (pointer) to that .NLO file. Enabling DAOS on mail.box is optional and is not required to gain any of the space saving benefits you observed in the previous exercise. In this exercise, you will enable DAOS on mail.box and then observe the results. You will then build upon your knowledge of DAOS by reading a developerWorks article and check your knowledge by answering some questions.
Time needed
It will take approximately 20 minutes to complete this content.
Objectives
After completing this exercise you should be able to: v Upgrade your mail.box to ODS 51 and to use DAOS. v Observe the router I/O benefits of enabling DAOS for mail.box v Answer a set of questions to review your familiarity with DAOS There are two parts to this exercise. Complete each part in the order it is listed below:
Exercise 2, Part 1: Enabling DAOS on mail.box

Follow the steps below to enable DAOS on mail.box and observe the results.
Enabling DAOS on mail.box

About this task
The following steps will walk you through the process of upgrading your mail.boxto ODS 51 and enabling DAOS. Note: Transaction logging should not be disabled for mail.box. DAOS requires transaction logging to be turned on for any and all DAOS-enabled databases, including mail.box. By enabling DAOS formail.box, you are making use of one of the most important DAOS features, the ability to route DAOS objects from mail.boxdirectly to mail recipients. 1. Run compact on the template, mailbox.ntf on your server in order to upgrade it to ODS 51. By default, it is ODS 43. Use copy style compact to upgrade the template to the current level (ODS 51).
2. Still working with mail.box, click File Application Properties and select Use Domino Attachment and Object Service. LZ1 is selected by default. 3. Exit the Administrator client. Shut down the server and delete your mail.box at the OS level. 4. Start the Domino server. A new mail.box will be created based on the altered mailbox.ntf. 5. Start the Administrator client. 6. Verify that the newly created mail.box is configured for DAOS: a. b. c. d. e. f. Select mail.box in the Files tab SelectFile Application Properties Verify the information tab shows ODS 51 Verify Disable transaction loggingis not checked Verify Use LZ1 compression for attachmentsis checked Verify Use Domino Attachment and Object Serviceis checked
Activity
1. Send another memo of about 20Kb to five users. 2. While the messages are routing, switch over to Windows Explorer. Observe that no additional temporary .NLO files are being written to the \DATA\DAOS\OO1 folder. You may recall from the previous exercise, when messages with large attachments are sent to multiple users, additional .NLO files were being temporarily written to this folder. When DAOS is not enabled on mail.box, the entire attachment is written even if it already exists. Once DAOS determines that an .NLO file already exists in the consolidated attachment store, the additional copy is removed.
Summary
You can continue with Exercise 2, Part 2: Assessment
Exercise 2, Part 2: Assessment

Background
Read the developerWorks article IBM Lotus Domino going green: The new Lotus Domino attachment and object service. As you read the article, note the following corrections: v The section entitled On-disk structure states Attachment consolidation is supported on Windows, Linux SLES 10, AIX, and System i. DAOS is supported on ALL platforms supported by the Domino 8.5 server. Noticeably missing from the list are Solaris, zLinux and Linux RHEL. Also, the article cites the ODS for Notes and Domino 8.5 as 50. In the time since the article was written, the ODS for 8.5 has been updated to 51. v The section entitled How attachment consolidation works states In any DAOS-enabled database, if a user saves a document containing one or more file
10
attachments larger than the size specified on the DAOS tab, the Lotus Domino server stores a reference to the file attachment in the object header of the document, and it stores a single copy of the file attachment in the attachment repository on the server. It should be noted that the size used to determine if an object is placed in DAOS is the net size after compression. For example, the minimum DAOS size is set to 4k and the user attaches a 6k text file. Because compression is enabled, the attachment compresses to 3k. This attachment would not be stored in DAOS because its compressed size is below the threshold. v The section entitled Setting up and enabling DAOS states To mark a selected database for attachment consolidation, follow these steps: From the Lotus Domino Administrator, choose File - Application - Properties. Click the Advanced tab. (The icon on this tab is a beanie.) Enable the Use Domino Attachment and Object Service option. While this process is correct and is the simplest way to enable use of DAOS for a database, it should be noted that you must have administrative rights to the database in order to set this property. If the Use Domino Attachment and Object Service property is displayed but greyed, this is a sign that the ID you are using does not have administrative privileges for this database. v The section entitled Deleting DAOS unreferenced objects describes the DAOS Prune command. All DAOS management commands are now accessed through the DAOS manager server task (DAOSMgr). So DAOS Prune [number of days old] would now be invoked from the Domino console as tell DAOSMgr Prune [number of days old]. This is very important as the old console command no longer works.
Questions and Answers

What does thetell DAOSMgr Prune [number of days old] command do? This command deletes all DAOS unreferenced objects that are older than the number of days old argument specified. You can delete all unreferenced objects explicitly at any time by using the DAOS prune command. What types of .NSF files can DAOS be enabled for? You can enable DAOS for any database that is ODS 51 or higher. You can enable it for some databases and not for others. However, a greater percentage of disk space savings can be seen when more people reference an attachment that is saved to the consolidated object store repository. It is obvious that the most significant savings for most Domino environments can be seen when DAOS is enabled for mail files and mail.box.
What happens if a user edits a document and saves a new version of the attachment? v A revised copy of the file attachment is added to the attachment repository. Not quite. v The reference to the original file attachment is deleted from the document. That isnt the best answer. v A new reference to the revised attachment is created Try again. v All of the above. Correct!
11
The minimum size required for a file to be consolidated into the attachment consolidated storage is specified in the DAOS tab of what document? server No. The correct answer is in the DAOS tab of the server document. In theDAOS tab of theserver document is correct!
True or False: When a User opens a document with an attachment, how is the attachment accessed? v True Well done! v False The correct answer is True.
You have successfully completed this exercise when you have: v Upgraded your mail.box to ODS 51 and to use DAOS. v Observed the I/O benefit of enabling DAOS on mail.box. v Answered the questions to review your familiarity with DAOS. You can continue with DAOS: Exercise 3.
DAOS: Exercise 3
This exercise covers tell daosmgr commands and synchronization.
Overview
You may be wondering, How can I determine which databases have each .NLO file mapped to them? In this exercise, you will learn how to determine the answer using tell daosmgr server commands. Along the way, you will also learn about the DAOS catalog (DAOScat.nsf) and, through a simulation, correct a situation where the DAOS catalog NEEDS RESYNC.
Time needed
Objectives
After completing this exercise, you should be able to: v Run tell DAOSMgr resync to resynchronize DAOS references in the catalog. v Simulate the need to resynchronize the DAOS catalog and use tell DAOSMgr resync to resynchronize it. v View dbsummary output to observe resychronization status. There are two parts to this exercise. Complete each part in the order listed below:
Exercise 3, Part 1: Evaluating with tell DAOSMgr commands

Follow the steps below to evaluate DAOS with tell DAOSMgr commands.
12
The DAOS catalog

The DAOS catalog (DAOScat.nsf) is the central map of database references (tickets) to .NLO files. Each DAOS-enabled server maintains its own DAOS catalog. Each DAOS catalog stands alone and does not replicate or synchronize with the DAOS catalog on other servers in any way. Each servers DAOS catalog must stay synchronized by synchronizing the references to the .NLO files held by each database on the server with all the .NLO files (the consolidated object store repository on that server). The DAOScat.nsf cannot be opened by the Domino Administrator or anyone else. Even if an Administrator could open it, there is nothing to see that will mean anything. However, there are several tell DAOSMgr commands that report out the information needed from the catalog. For example, one option for reporting the catalog status is the tell DAOSMgr status command:
> tell daosmgr status catalog 10/07/2008 01:08:56 PM DAOSMGR: Status CATALOG started 10/07/2008 01:08:56 PM DAOS catalog status: 10/07/2008 01:08:56 PM catalogState = SYNCHRONIZED 10/07/2008 01:08:56 PM catalogVersion = 3 10/07/2008 01:08:56 PM catalogMinVersion = 3 10/07/2008 01:08:56 PM DAOSMGR: Status CATALOG completed
For perspective, similar information is reported out by the show stat daos command:
> sh stat daos.engine.* DAOS.Engine.Catalog = Synchronized DAOS.Engine.Encryption = Enabled DAOS.Engine.Status = Enabled 3 statistics found
If a servers DAOS catalog needs synchronization, DAOS fires a DDM event. Administrators can choose to schedule a DAOSMgr resync in response to this DDM event. To learn more about the DDM event and resynchronization, read the Notes/Domino wiki article How to set up an automatic resynchronization ddm event. An Administrator can also run tell DAOSMgr Resync at any time to manually synchronize the catalog on demand.
Evaluating tell DAOSMgr commands

About this task
Run each of the following tell DAOSMgr commands at your server console and observe their output: 1. tell DAOSMgr Status Displays status of various DAOS Manager operations. 2. tell DAOSMgr Status Catalog Displays status of the DAOS catalog. 3. tell DAOSMgr Dbsummary Displays status of all DAOS-enabled databases. 4. tell DAOSMgr Databases Displays status of all DAOS-enabled databases with additional details, for example, a databases last resynchronization point. 5. tell DAOSMgr ListNLO what to list
13
Lists DAOS objects (.NLO files) in the DAOS storage repository, allowing an administrator to identify documents whose objects may be missing after an event such as a server restore or the deletion of a database file through the operating system. You can restore the missing objects from backup sources. Files are missing when they are still referenced by documents in at least one database, but are no longer present in the repository. You can enter -o to specify the name of an output file, the keyword ALL or MISSING to list all or just missing files, and the name of a database whose objects to list. For example: tell daosmgr listnlo -o mymailobjects.txt MISSING mymail.nsf or tell daosmgr listnlo -o mytest.txt ALL mail\mymail.nsf Note: The text file is created on the fly in the Domino directory. 6. tell DAOSMgr Resync Resynchronizes DAOS-enabled databases with DAOS objects in the storage repository. Resynchronization is necessary whenever DAOS reference counts need to be recalculated, for example when there has been a database restore, deletion of a database through the operating system, or any other event that can invalidate the count. Resynchronization corrects mismatches between reference counts in the DAOS catalog (DAOSCAT.NSF) and actual references to objects found in the DAOS enabled databases. When a mismatch is detected, DAOS disallows pruning (deleting from the NLO repository) of attachment objects (.NLO files) until DAOS is synchronized using this command shown on the left. If you run the command and it starts and stops quickly, then the catalog is synchronized. If it is not synchronized it may take a while because this is what it does: v scans all the databases enabled for DAOS v asks each database what references(tickets) to .NLO filess are held by it v updates the record in the DAOScat.nsf to match what it has found during its scan If you want DAOS to resynchronize the catalog even if it is already reporting to be synchronized, then you can run the tell daosmgr resync force command.
Summary
You can continue with Exercise 3, Part 2: Resynchronizing
Exercise 3, Part 2: Resynchronizing

Follow the steps below to resynchronize DAOS-enabled databases with DAOS objects in the storage repository.
About resynchronization
There are many reasons you may need to resynchronize DAOS-enabled databases with DAOS objects in the storage repository. To resynchronize, you perform a DAOS synchronization using the tell DAOSMgr Resync command. One instance when you may need to resynchronize is when Domino encounters a database whose information no longer matches what is known in the DAOS catalog file. In this case, DAOS operations are automatically discontinued to avoid possible data loss, and the catalog is not synchronized. The mismatch between the catalog and the database could have been caused by deleting the database through
14
the operating system instead of using the Domino Administrator client, or by restoring a version of the database after a backup that does not have the same information as the DAOS catalog. To correct this problem, run the tell DAOSMgr Resync command.
How do I know if my DAOS catalog needs resynchronization?

When your DAOS catalog needs resynchronization, one way you will know is that tell DAOSMgr status will display catalogState = NEEDS RESYNC. A DDM event is generated to indicate that DAOS is out of sync:
How to set up an automatic resynchronization ddm event

For more information on setting up external resynchronization, read the Domino and Notes 8.5 wiki article, DAOS: How To Set Up Resychronization Events With DDM.
Activity
Follow the steps below to simulate the need to resynchronize and perform a resynchronization. 1. Shut down your Domino server. 2. In order to cause a your DAOS catalog (DAOScat.nsf) to be in a state of NEEDS RESYNC do one of the following: v copy a DAOS enabled database into the data directory from the OS v delete a DAOS enabled database from the OS v rename a database from the OS v delete an NLO from the OS (will transition to NEEDS RESYNC when the NLO is attempted to be opened.) 3. 4. 5. 6. 7. v restore a database directly to the data directory Restart your Domino server. At the server console, enter the tell DAOSMgr status command. Verify the catalogState. You should see catalogState=NEEDS RESYNC. At the server console, type the tell daosmgr dbsummary command. Verify the database is listed as NEEDS RESYNC
8. Just to make sure it exists on your Domino server, check the Files tab in the Domino Administrator 9. Repeat steps 4 and 5 until you see that the catalog state NEEDS RESYNC and the database NEEDS RESYNC. 10. To resynchronize, enter the tell daosmgr resync command. The server console will show the status of the resynch operation:
15
11. Enter the tell daosmgr dbsummary command. Your application should appear as synchronized in the summary. Note: It is harmless to run tell daosmgr resync if the catalog is in a synchronized state. The catalog will not be rebuilt, and the command will run quickly in that case. However, if you run tell daosmgr resync force, the DAOS catalog will be rebuilt from scratch, and this can take a long time. Using force is not required when DAOScat.nsf is already in a state of NEEDS RESYNC. 12. Observe that the catalog is synchronized by entering tell daosmgr status catalog command. 13. Observe alternative output by entering the tell daosmgr databases command.
Summary
You have successfully completed this exercise when you have: v Run tell DAOSMgr Resync to resynchronize DAOS references v Put the DAOS catalog in a state of NEEDS RESYNC. v Performed a resynchronization You can continue with DAOS: Exercise 4.
DAOS: Exercise 4
This exercise covers DAOS cleanup, orphaned .NLO files and corruption.
Overview
Since the main objective of DAOS is to save space, it would seem right to regularly purge the NLO directory just to keep it neat, right? Not right. Sure, there may be times when you will want to remove orphaned files or when you know that you will never ever need an .NLO file again. However, DAOS automatically removes .NLO files that are no longer referenced. By design, DAOS has built-in safeguards. For example, DAOS doesnt delete or remove any .NLO file that it doesnt know it doesnt need. In this exercise, you will explore DAOS references to .NLO files, the DAOS catalog, the tell DAOSMgr prune command and what to do if you have a missing NLO file.
Time needed
Objectives
After completing this exercise you should be able to: v Compare DAOS references with DAOS objects in the repository, by observing daosmgr daosdiag -d with daosmgr daosdiag -a output side by side v Simulate and detect missing .NLO files in the DAOS repository
16
v Prune unreferenced .NLO files at any time using prune commands v Observe DDM probes generated as a result of a missing .NLO file or need to resync There are three parts to this exercise. Complete each part in the order that it is listed.
Exercise 4, Part 1: Simulate a missing .NLO file

Follow the steps below to simulate a missing .NLO file.
How is the DAOS repository maintained in a safeguarded way?

It automatically deletes unreferenced .NLO files from the repository. The DAOS catalog is keeping track of the number of references that exist for each .NLO file and when the refcount drops to 0, meaning no databases have any references to the .NLO file, only then will it automatically consider deleting the .NLO file. At the moment an .NLO file is unreferenced, the consideration of when to actually delete it is calculated based on the deferred delete feature, built into the DAOS and configurable in the server doc. There is a defer delete for .NLO files . Take the case where you have a corrupt database that is enabled for DAOS. Sooner or later, DAOS is going to resynch and bring its catalog up to date. It will reflect what and how many references databases hold for a particular .NLO file. DAOS does this by adding up all references from all databases by scanning the DAOS-enabled databases on the server and learning about all the references to the .NLO files within each If DAOS is not able to properly scan a database because it is corrupt, it will not be able to read any of its references. When a reference to an .NLO file has gone to 0, DAOS will delete the .NLO file when it reaches the number of days listed in the Defer object deletion for: field in the server document. The default value is 30. For example, if the corrupt database was the only database to originally hold any references to the .NLO file, the catalog will keep track of the fact that the .NLO file no longer has a reference, and that the .NLO file should be deleted in 30 days. At 30 days, DAOS will automatically delete the .NLO file. In the meantime, if the Administrator was able to restore the corrupted .NSF file with a good .NSF file, DAOS will be able to resync to the restored .NSF file, read all the references it has and update the catalog to reflect the references that exist for the restored database. The result would be that the .NLO file would have references to it and would therefore not be deleted. The connection to the .NLO file would automatically come back. In this way, the DAOS repository acts like a form of backup. Your need to actually go to a backup system can be managed better when you rely on the deferred delete behavior. DAOS does not delete .NLO files when the DAOS catalog is in the state of NEED RESYNC . If your catalog needs a resync, pending deletes will not occur until the catalog is brought to a state of synchronization. It will become synchronized sooner or later, and when it is, those pending deletes will occur automatically. The DAOSmgr tool helps us determine what .NLO files are no longer referenced in the DAOS repository. Your DAOS repository should hold all .NLO files that are still being referenced and 30
17
days (by default) worth of unreferenced .NLO files. You can override the deferred delete configuration for your server (default 30 days) and delete them on demand using the tell DAOSMgr prune command. We will test the prune command in Part 2 of this exercise.
Activity
About this task
Missing .NLO files are a big concern. While running DAOS operations, Domino may fail to access an .NLO file for the following reasons: v A specified database was restored to the server from backup but the referenced .NLO files were not restored v .NLO files may have been removed by anti-virus software v The specified database was copied from another server through the operating system, and may contain tickets for .NLO files that exist only on the other server v The storage location specified for DAOS files (the repository) is inaccessible. Example Your .NLO files (DAOS repository) are stored on a physical device that goes down. This would be an aggravated situation. The .NLO files would be missing and not accessible. For missing .NLO files, running the fixupatabase name-D -J database name command may be a good idea when you have a replica of the database(s) in question. Running the fixupatabase name-D -J database name command will delete the documents with references to missing .NLO files in the database. Those notes can be replicated back in and the attachments will replicate with the note and then be newly DAOSed by the server. If however, the databases that have missing .NLO files do not have replicas, you would not want to run the fixupatabase name-D -J database name command against them. 1. Move an .NLO file from the first DAOS exercise out of the consolidated object repository. This will simulate a missing .NLO file. 2. Try to open the corresponding attachment from inside the mail message of the Domino Administrators mail file. You should not be able to open the attachment. An error dialog should appear. 3. Observe the same error in the console. 4. Along with issuing the error message at the console, a DDM event is fired. Before we get into which event, well examine all the possible DAOS DDM messages. a. Within events4.nsf, Click the view Advanced Event Messages by Text b. Click View Search this View c. Search on the term DAOS Many of the DAOS DDM messages will be of Severity: Warning(Low). Some are informational and are Warning Normal or Warning Failure. Take a minute to observe the types of DAOS DDM messages and the probable cause text inside some of the documents. Which DAOS DDM error message should be fired when an NLO file is missing from the repository?
5. Follow these steps to set up a DAOS DDM probe on your server: a. Open the Monitoring Configuration database (events4.nsf) on your server
18
b. Set up and enable the Database/Error Monitoring probe with a Severity: Warning(Low). Refer to the instructions provided in the Notes/Domino Wiki article DAOS: How to set up resynchronization events with DDM. For the purposes of this exercise, we are only enabling the probe for DDM events to be written to DDM.nsf. We are not concerned with event handling. c. Copy the Database/Error Monitoring probe you just created. Modify and enable the copy to be Severity: Warning (High) d. Make a third copy the Database/Error Monitoring probe. Modify and enable the copy to be Severity: Warning (Normal) e. Make a fourth copy of the Database/Error Monitoring probe. Modify and enable the copy to be Severity: Failure 6. In the servers notes.ini file, add the parameter DAOS_LOGGING=c:\temp\daos.txt DDM. 7. Restart the server. Try to access a missing .NLO file. This will generate a DDM event. 8. The error is captured by the DDM event in two locations: v In the daos.txt log v In the DDM.nsf. Open the DDM event document to view the error message.
9. At the server console, enter: tell daosmgr resync tell daosmgr listnlo -o myfile.txt missing mail\admin.nsf where myfile.txt is an arbitrary text filename and admin.nsf is the name of the Domino Administrators mail file. As a result, myfile.txt will be found in the Domino\datadirectory. The file should contain the path to an .NLO file, indicating that the file is missing.
Summary
You can continue with Exercise 4, Part 2: The tell DAOSMgr prune command.
Exercise 4, Part 2: The tell DAOSMgr prune command

The tell DAOSMgr prune command will do the following: Tell DAOSMgr prune 0 Immediately deletes all DAOS unreferenced objects that are older than the deferred delete interval specified in the Server document. Tell DAOSMgr prune number of days old Deletes all DAOS unreferenced objects that are older than the argument, overriding the delete interval specified in the Server document. The command is useful for cleaning up all objects if you want to do that independently from the default deferred deletion interval. Follow the steps below to bring the references to a DAOS object to 0 and then prune the unreferenced object from the DAOS repository.
19
Activity
1. Observe the number of .NLO files that exist in the DAOS repository right now. 2. Observe the value in theDefer deletion of object for field in the DAOS tab of the server document. The value designates how many days a DAOS object will be kept in the DAOS repository after the last ticket to it is deleted. 3. Now remove all the references to a particular .NLO file. To do this, you must remove the reference from both the sender and all recipients. a. To remove it from the recipients, log into each of your users mail files and deselect Allow soft deletions in the Application properties dialog. If a document is deleted while soft deletion is enabled, the references to it will remain in a document that is located in another folder in that database. Therefore, DAOS will still reflect that the reference is in the DAOS catalog. Note: You can deselect Allow soft deletions for multiple mail files by selecting all the mail files in the Files tab of Domino Administrator. Then use the advanced properties database tool to deselect the Allow soft deletions application property. b. Select an attachment you used in Exercise 1, Part 3. Delete all messages with that particular attachment so that no messages are referencing it. 4. At the server console, enter the tell DAOSMgr resync command. Is the .NOL file removed from the DAOS repository? No Why? Because the deletion of it is deferred for 30 days as per the server document 5. To override the Defer object deletion field value, you may use the tell DAOSMgr prune command. In this case, we are trying to immediately delete unreferenced objects, so enter the tell DAOSMgr prune 0command at the Domino server console. Is the .NLO file removed from the DAOS repository? It should be.
What if there is an .NLO file that is orphaned in your DAOS repository? An orphaned .NLO file is not referenced by any database. For example, if you delete a database manually at the OS, the server will detect it and the DAOS catalog will then be in the state of NEEDS RESYNC. There will be a DDM event and statistic that let you know when the catalog needs a resync. Alternatively, you can run the tell DAOSMgr status catalog command to determine if it is in need of a resync. When you issue the tell DAOSMgr resync command all orphaned .NLO files will be deleted.
Summary
You can continue with Exercise 4, Part 3: DAOS and corruption.
20
Exercise 4, Part 3: DAOS and corruption

.....And then there is the question of corruption. If a database is corrupt, fix the database corruption, leave the .NLO files alone and then restore the repaired database or backed-up database to the server. The .NLO files that you havent touched will reconnect and all will become resynchronized to the DAOS catalog after the database is restored. You can run the load fixup database name -D -j command to delete the document with the corrupt ticket from the database. For more information about Fixup options, refer to the DAOS option for Fixup section of the Domino Administrator 8.5 InfoCenter document Fixup options. When you try to view the attachment in the client, corrupt tickets will display an error similar to the one below:
If an .NLO file is corrupt, you must replace it from a backup for that server. What if the DAOS catalog itself is corrupt? Well, the DAOS catalog is just an index, and DAOS can get by without it. For example, if the DAOS catalog becomes corrupt, you can forcefully remove DAOScat.nsf at the OS, and the tickets held by databases will still find the .NLO files. However, if you have many subdirectories of .NLO files (after 4000 .NLO files in the 0001 directory, a new subdirectory is automatically created), without the DAOS catalog index, the search for an .NLO file will take a long time. So, to make things faster for your Domino system, after you remove the DAOScat.nsf, rebuild it using tell DAOSMgr resync. All the references will be built into a new catalog.
If a database containing references to .NLO files is corrupt, what should you do? v You should leave the .NLO files in their repository and restore a good backup of the database. Correct! v You should delete the .NLO files from their repository and restore a good backup of the database. Try again!
Summary
You have successfully completed this exercise when you have: v Simulated and detected missing .NLO files in the DAOS repository. v Pruned un-referenced .NLO files on demand by using the tell DAOSMgr prune command You can continue with DAOS: Exercise 5.
DAOS Exercise 5
This exercise covers DAOS and replication.
21
Overview
DAOS is server-based. Therefore, in a cluster situation, each Domino server or partition must be DAOS-enabled. Also, each server in the cluster set must have its own data store. Sharing is not allowed. Because of this, its not a good idea for you to restore a DAOS store from one server with the DAOS store on its cluster mate. Remember that DAOS is server-specific. If you want DAOS enabled on all servers in a cluster, you must configure it on each server. It is also acceptable to have one or more servers in the cluster not using DAOS. When a DAOS-enabled database on a DAOS-enabled server replicates with another DAOS-enabled server, the full attachments replicate over the wire to the other server. Once they get there, they are DAOSified on the receiving server. When you create a new replica of a database, the full attachments will replicate. If the new replica is on a DAOS-enabled server, the attachments will automatically be DAOSified on that server. If the replica is not on a DAOS-enabled server, the full attachments will replicate anyway and stay that way in the new replica. You can create a replica on a Notes client or via the admin process (to a non-DAOS enabled server). The database with full attachments will be created. If you do an OS replica to another server that is not DAOS-enabled, there will be issues. Using OS commands to move or copy a DAOS-enabled database to another server will not move any of the DAOS attachments. The database and its documents will be able to be opened, but many (or all) of the attachments will be inaccessible, depending on what happens in the destination servers DAOS repository. Copying a database in this manner will also cause the DAOS catalog to require resynchronization in order to update the reference counts for all DAOS objects. DAOS only works on the Domino server, not on the Notes client. There are no .NLO files or repositories for local replicas. This means that when a local replica is created of a DAOS-enabled database on the server, all the .NLO files are pulled into the database as full attachments inside Notes documents. You may use this approach to un-DAOS a database.
Time needed
Objectives
After completing this exercise, you should be able to complete the following Critical Objectives: v Use the Admin Client to replicate a database from one DAOS-enabled server to a non-DAOS server v Use the Admin Client to replicate a database from one DAOS-enabled server to another DAOS-enabled server v Answer the question, What happens to the attachments already in existence within a database if I enable DAOS on my server today? v Create a local replica of a database stored on the server that uses DAOS
Requirements
To begin this exercise you will need v One DAOS-enabled server.
22
v Install files to install a second server in the same domain as the first. v A machine on which to install a second server. There are three parts to this exercise. Complete each part in the order that it is listed.
Exercise 5, Part 1: Replicate a database from a DAOS enabled server to a non-DAOS enabled server
Follow the steps below to replicate a database from a DAOS-enabled server to a non-DAOS enabled server.
Activity
1. On the first server create a discussion database, blue.nsf using discussion8.ntf. 2. Add two user names to the ACL of blue.nsf, giving Manager access to both. 3. From a client, enable DAOS on blue.nsf. 4. Open blue.nsf and add a new main topic that includes a file attachment. 5. Ensure that the attachment can be read or viewed by double-clicking on it within its document. 6. Save the document and exit Notes. 7. Observe that a new .NLO file has been created in the DAOS\0001 directory. 8. Install and configure a second server in your same organization and domain. Do not configure the second server for DAOS. 9. Use Domino Administrator to make a replica of blue.nsf on the second server. a. Select blue.nsfon the files tab b. Select Tools Database Create Replica c. Add the source servers name to the server document Can create replicas field on the receiving server d. At the server console to replicate that domino directory change to the receiving server using the replicate Server2 names.nsf command e. After the replica is created on the new server, the replica will only be a stub. To initialize it, at the source servers server console enter the replicate Server2 blue.nsf command to manually replicate with the receiving server. The result will be that the server replicates the documents to the receiving servers replica stub. It will then be initialized and can be opened on the receiving server. 10. Open the blue.nsf replica on the second server. Open the document with the attachment, then open the attachment. Is it there? It should be. Keep track of the fact that DAOS is not yet active on the second server. What do you think will happen with the existing attachment once we enable DAOS later on the second server? Hold that thought. Were going to test it out. 11. Verify that DAOS is still not enabled on your server by using the sh server command at the server console or by verifying there is no DAOS\0001 directory on the second server. Attachments are absorbed into the replica on second server because it does not use DAOS and Domino knows it.
Summary
You can continue with Exercise 5, Part 2: Replicate a database from a DAOS enabled server to local on page 24
23
Exercise 5, Part 2: Replicate a database from a DAOS enabled server to local

Follow the steps below to replicate a database from a DAOS-enabled server to local.
Activity
1. Using the same database stored on Server 1,blue.nsf use your Notes client to create a local replica. 2. Open the local replica and try to open the attachment in the document. Is it there? It should be. Is there a DAOS repository in your local Notes directory structure? It should not be. The database should replicate and attachments should work as expected. The attachments are in the local database and are not DAOSed.
Summary
You can continue with Exercise 5, Part 3: Replicate a database from a DAOS-enabled server to one the becomes DAOS-enabled
Exercise 5, Part 3: Replicate a database from a DAOS-enabled server to one the becomes DAOS-enabled
Follow the steps below to replicate a database from a DAOS-enabled server to one the becomes DAOS-enabled.
Activity
1. Configure your second server for DAOS. a. In your servers NOTES.INI, set Create_R85_Databases=1 b. Enable Transaction Logging through the server document. Set the maximum log space to 2000 MB. c. Restart the server. d. Enable DAOS through the server document. e. Restart the server. f. Enable existing databases (and their existing attachments) to participate in DAOS using the load compact -c -daos on command Enable encryption for DAOS by adding DAOS_Encrypt_NLO=1 to the second servers NOTES.INI. Restart the server. Open the replica of blue.nsf on the second server. Check the Application Properties to ensure that Use Domino Attachment and Object Services is selected. Create a new main topic and include a second attachment.
2. 3. 4.
5.
6. Ensure that the attachment opens and can be viewed from the blue.nsf application on the second server. 7. Look for the DAOS repository in the server file structure. It should be there. 8. Determine if both attachments in the blue.nsf replica are stored in the second servers DAOS repository using the tell daosmgr listnlo all blue.nsf command 9. Replicate blue.nsf with the first server. 10. Read the section Enabling a Notes Database from the Lotus Notes and Domino wiki article DAOS Quick Start Guide
24
Summary
You have successfully completed this exercise when you have: v Used the Admin Client to Replicate a database from one DAOS enabled server to a non-DAOS server v Used the Admin Client to Replicate a database from one DAOS enabled server to another DAOS enabled server v Determined what happens to attachments that existed in a database pre-DAOS, when you suddenly enable DAOS for your server v Create a local replica of a database stored on the server that uses DAOS You can continue with DAOS: Exercise 6.
DAOS Exercise 6
This exercise covers DAOS and mail.
Overview
In this exercise you will explore how DAOS behaves with multiple mail servers. You already know that DAOS is server-based and that sharing DAOS repositories between servers is not allowed. One reason sharing is not allowed is because each server is keeps track of only its own store using its own DAOScat.nsf. Another reason sharing is not allowed is because in the case that .NLO files are encrypted, they are encrypted with the key of the server on which they were created. So what does that mean when a user on a DAOS-enabled sends a message to a user on another DAOS-enabled server? What does it mean when a message comes from a DAOS server but goes to a non-DAOS server? What about a non-DAOS enbabled mail file on a DAOS-enabled server? What about an internet recipient? In this exercise, we will explore these questions.
Time needed
Objectives
After completing this exercise, you should be able to: v Observe the impact of using different type of compression for mail files enabled with DAOS. v Observe the impact of sending a message by a user with a DAOS-enabled mail file on a DAOS-enabled server with a DAOS-enabled mail.box to a recipient with a DAOS-enabled mail file on another DAOS-enabled Server with a DAOS-enabled mail.box.
Requirements
Completion of this exercise requires two DAOS-enabled Domino servers (you should have this already from the previous exercise on replication). There are two parts to this exercise. Complete each part in the order that it is listed.
25
Exercise 6, Part 1: Using different compression formats

Follow the steps below to use different compression formats.
Activity
1. Register a new mail user, Orvil Red, on your first DAOS-enabled server. Orvil will be known as the Original Sender. When you register Orvil, choose to save his ID to file 2. Log into Notes as Orvil and ensure the following application properties for Orvils mail file: v Transaction logging enabled v LZ1 compression enabled v DAOS enabled v Soft deletions disabled 3. Register another new mail user, Bevo Longhorn, on the same server. Bevo will be known as the recipient. Once again, for your convenience, choose to save his ID to file. 4. Log into Notes as Bevo and ensure the following application properties for Bevos mail file: - this setting is different for Original Sender and this means Huffman compression will used for any attachments in the database DAOS enabled Soft deletions disabled v Transaction logging enabled v LZ1 compression disabled Note: This means Huffman compression will used for any attachments in the database. v DAOS enabled 5. v Soft deletions disabled Check your first Servers DAOS repository (where Orvil and Bevo are registered). Make note of the attachments that are in there right now. How many are there? Acting as Orvil, send a message with an attachment to Bevo. Verify the references to the attachment were acknowledged by DAOS for both of the mail files by entering the tell DAOSMgr dbsummary command in the first servers console Determine how many .NLO files were created as a result of sending the one attachment by entering the tell daosmgr daosdiag -a -v -o hufflz mail command at the server console and examining the hufflz output file created in the Domino directory. Why did the one attachment create two .NLO files? Two .NLO files were created because of the different compressions used. Orvils .NLO file was created based on the checksum completed by DAOS for the attachment compressed with LZ1. Bevos .NLO file was created with a checksum of the attachment that was compressed as Huffman.
6. 7.
8.
Summary
You can continue with Exercise 6, Part 2: Sending mail from one DAOS server to another on page 27
26
Exercise 6, Part 2: Sending mail from one DAOS server to another

Common Questions about DAOS and Mail
1) What is required for DAOS to place the attachments in a memo into the DAOS repository? v Transaction logging and DAOS must be enabled for the server. v Transaction logging and DAOS must be enabled for any mail file that will use DAOS. v The stored size of the attachment must be greater than the minimum DAOS object size specified in the server configuration. The size in the server doc is in bytes, the default is 4096, or 4Kb. v To optimize performance, transaction logging and DAOS must be enabled for the mail.box. This does not affect whether or not DAOS is used; it affects only performance. If mail.box(es) are DAOS-enabled, the router can save significant I/O by routing the DAOS tickets to the recipient mail files instead of sending the entire attachment content. Either way, the attachments will end up in DAOS and will be consolidated. 2) What gets sent when a mail message is sent by a user with a DAOS-enabled mail file on a DAOS-enabled server with DAOS -enabled mail.box to a recipient with a DAOS-enabled mail file on another DAOS-enabled Server with a DAOS-enabled mail.box? The router from the first server sees that the recipient is located at another server, so it copies the email into the other servers mail.box. When the email is copied, the attachment is read from the DAOS repository on the first server, and the email is copied entirely including the full attachment. This means that the whole email including the full attachment (not the ticket) will be sent through the network. On the recipient server, DAOS will create the .NLO file in that servers DAOS repository. The recipients mail file will contain the ticket to the .NLO file. From the recipients perspective, this is all transparent. Note: Because of this transparency, DAOS-enabled servers can interact (replicate, route mail) with non-DAOS servers as well as non-8.5 servers. 3) What if the recipient is on a non-DAOS server? The router from the first server sees that the recipient is located in another server, so it copies the email in the other servers mail.box. When the email is copied, the attachment is read from the DAOS repository on the first server, and the email is copied entirely including the full attachment. This means that the whole email including the full attachment (not the ticket) will be sent through the network. On the recipient server, the attachment remains as a full attachment in the recipients mail file. From the recipients perspective, this is all transparent. 4) What if the recipient on the non-DAOS server replies to the original sender (who uses DAOS) and includes attachments? The router from the second server transfers the message to the first servers mail.box (DAOS enabled). DAOS on the first server knows that the message is going to the mail file of the original sender that is enabled for DAOS. DAOS compares the checksum of the new attachment to the DAOS repository. If there is already an .NLO file with that checksum, DAOS increases the refcount to the .NLO file by 1. The refcount is increased in
27
the original senders mail file (receives a ticket), and the new refcount for that particular .NLO file is ultimately reflected in the DAOS catalog (DAOScat.nsf). 5) What if the sender and senders server are using DAOS, but the recipient of a mail message is going to someone on the internet? An .NLO file is created on the first server, and the full attachment is sent over the wire and out for the internet recipient. 6) What if a user replies to or forwards a message with an attachment on a DAOS-enabled server with DAOS-enabled mail files? Only the ticket is used. If you forward a document with an attachment, if the recipient is on the same DAOS-enabled server, they also get the ticket instead of the full attachment. And, once it leaves the Domino domain, the full attachment is sent automatically - you dont have to do anything. 7) How do soft deletions factor in? When a mail file has soft deletions enabled, messages arent really deleted from the database, they just move into a different folder for a while. So, messages that contain a reference to an .NLO file, will contain that reference whether they are in your inbox or elsewhere within your mail file. When DAOS synchronizes, it doesnt care if the message was soft deleted or not. It just sees and reads the reference/ticket when it scans the mail file. 8) Will a server with Mail archives support DAOS? Yes. The mail archive is an .NSF file, and if DAOS is enabled for that archive .NSF file, the attachments will be stored in DAOS. DAOS only works on the Domino server, not on the Notes client. If the archive is stored on the users local client data area, it is not eligible to participate in DAOS. If the archive is local, the attachments are stored within it in full. There is no such thing as a local .NLO file. 9) How does it work with BlackBerrys if an attachment is placed in storage on the BES server? The BES server will act as any non-DAOS enabled server, and the Blackberry user receives a message with the full attachment.
Activity
1. Orvil Red is the Original Sender from Part 1. On your second DAOS -enabled server, register a recipient, Kate Kite. 2. Log into Notes as Kate Kitet and verify the following application properties for Kate Kites mail file (application properties): v Transaction logging enabled v LZ1 compression used v DAOS enabled v Soft deletions disabled 3. Ensure that you can route mail, any mail, from the first server to the second server. Replicate names.nsf as needed to update the Domino directory on both servers. 4. Acting as Orvil Red on the first server, send a message with an attachment to Kate Kite. 5. Ensure that the .NLO file is created by entering the tell DAOSMgr dbsummary command at the first server console. At this point, the refcount for Orvil Red should be 2 because he already had 1 from the previous exercise.
28
6. Log into Notes as Kate Kite and look for the new message. Open the attachment just to make sure it worked. 7. Ensure that the .NLO file is created by entering the tell DAOSMgr dbsummary command at the second server console. You should see the refcount for Kate Kite is 1. 8. Acting as Kate Kite,, forward the same message and attachment that you just received back to Orvil Red. 9. Once you have confirmed that Orvil Red has received the message check the refcounts using the DAOSMgr dbsummary. command. The refcounts have increased for both. The number of .NLO files should not have increased because the file has not been changed. Orvil Red and Kate Kite are both referencing the .NLO file that was created in their own servers DAOS repository. 10. Register another user, Sally Seashell, on the second server. 11. Disable DAOS on Sallys mail file. 12. Send a message from Orvil to both Kate Kite and Sally Seashell. Both Kate Kite and Sally Seashell will receive the message with the attachment, and will be able to view it. However, only Kate Kite will have a DAOS reference to it. You verify check references by issuing the tell DAOSMgr dbsummary command.
Summary
You have successfully completed this exercise when you have: v Observed the impact of using a different type of compression for mail files enabled with DAOS v Observed the impact of sending a message by a user with a DAOS-enabled mail file on a DAOS-enabled server with a DAOS-enabled mail.box to a recipient with a DAOS-enabled mail file on another DAOS-enabled server with a DAOS enabled mail.box. You can continue with DAOS: Exercise 7.
DAOS Exercise 7
This exercise covers DAOS with backup and restore.
Overview
Backup and restore activities for DAOS-enabled servers follow a few rules of behavior. For example, you cannot backup .NLO files from one cluster-mate to another. And existing backup and recovery applications will work fine for doing backup and restore. The only change is procedural; there is no backup software update necessary. .NSF files can be backed up with their existing NSF backup process. .NLO files should be backed up with the same product, treating them as flat files that require no special treatment. In this exercise, you will explore backup situations.
Time needed
29
Objectives
After completing this exercise you should be able to: v Use the Domino Administrator to make a copy of a database from another DAOS-enabled server with .NLO files being referenced properly on both servers. v Understand why you are able to open attachments stored within documents on a database copied through the Administrator client on a different server. v Identify and restore an .NLO file that is missing.
Requirements
To perform this exercise you will need: v Two DAOS-enabled Domino servers in the same organization. v Transaction logging turned on for the server s v Transaction logging turned on for both mail.box v DAOS enabled for the servers v DAOS_Encrypt_NLO=1 in the servers NOTES.INI There are two parts to this exercise. Complete each part in the order that it is listed.
Exercise 7, Part 1: Copying through the Administrator client

Follow the steps below to copy through the Administrator client.
Activity
1. Review the procedure for backing up a Domino server that participates in attachment consolidation a. If you are using deferred deletion with DAOS, set the interval to longer than the interval between your backups. For example, if you back up weekly, specify 8 days for the setting Defer deletion of DAOS objects n days in the server document. b. Back up .NSF files on the server using a backup utility that is compatible with .NSF files. The utility must be able to use the backup and recovery methods of the Domino C API Toolkit. Existing APIs have not changed. c. Back up the DAOSCAT.NSF and DAOS.CFG files. These files are located in the data directory. d. Back up all .NLO files in your DAOS repository. You can use any flat file backup utility of your choice (such as Tivoli Storage Manager). If DAOS has created subdirectories, maintain the directory hierarchy in your backup. If the server is operating during this process, new .NLO files may have been created due to activity. .NLO files should be backed up after .NSF files to ensure that everything referenced by the database exists in the backup of the .NLO files. e. After the first backup of the DAOS repository, perform incremental or full backups as desired of both .NSF and .NLO files. .NLO files are never modified by Domino after their initial creation other than deleting them once their reference count goes to 0 and the deferred deletion interval is reached. f. It is highly recommended that you archive any transaction logs so that changes that occurred after the last backup can be replayed for the most complete restoration of data. 2. Review the procedure to move or restore the DAOS repository
30
a. Do one of the following to move or restore the DAOS repository: v To move the DAOS repository directory: 1) Create the new directory in the new location 2) Use your operating system to copy the entire contents of the existing DAOS directory to it v To restore the DAOS repository directory from your backup file: 1) Copy the backed-up contents of the DAOS directory to the new file location Note: Remember that if the DAOS deferred delete interval is beyond the restoration date, the NLO files will not have been deleted, and no NLO restore operations will be needed. b. From the Lotus Domino Administrator, click the Configuration tab and then expand the Server section. c. Click the DAOS tab. d. In the DAOS base path field, specify the new location for the directory. Save the server document. e. Restart the Lotus Domino server. 3. Consider User case 1 Your server console reports a message such as this:
We know from this message which file is missing. We can easily examine the DAOS repository to confirm if that file is missing or not. We might not know why it is missing. One possible reason could be that the specified database was copied from another server through the operating system, and may contain tickets for .NLO files that exist only on the other server. If that is the case, then there is a simple solution: Delete the database and use the Domino Administrator client to copy the database file from the other server. Copying through the Administrator client properly adjusts DAOS references so that they are correct for any .NLO files that exist on the current server, and they do not specify nonexistent files. a. On the first DAOS-enabled server which is also enabled for DAOS encryption, create a discussion database named smile.nsf. b. Add both server names and two user names to the ACL of smile.nsf., giving Manager access to all. c. From a client (Administrator or Notes), enable DAOS on smile.nsf. d. Open the database and add a new main topic with an attachment. e. Ensure that the attachment can be read or viewed by double-clicking on it within its document. f. Observe that a new .NLO file has been created in the DAOS repository. g. Shut down both servers. Make an OS copy of smile.nsf. from the first server to the second servers Domino data directory. Restart both servers. h. From a client, open smile.nsf. on the second server. i. Open the document that contains the attachment. Observe the error and server console report. j. Exit Notes. k. Delete smile.nsf. from the second server.
31
l. Select File Application New Copy to copy smile.nsf. from the first to the second server. m. From a client, open smile.nsf. on the second server again. Attempt to open the document with the attachment. You should be able to open it now. Why does it open now? It opens becausebu making a copy properly through the client, DAOS has properly adjusted DAOS references so that they are correct for any .NLO files that exist on the current server, and they do not specify nonexistent files.
Summary
You can continue with Exercise 7, Part 2: Identifying and restoring a missing .NLO file
Exercise 7, Part 2: Identifying and restoring a missing .NLO file

Follow the steps below to experience a missing .NLO file and then to restore it.
Activity
Consider User case 2: A referenced DAOS object (an .NLO file) is mistakenly deleted and needs to be restored. How would you do that? Follow the steps below to experience a missing .NLO file and then to restore it. 1. Move all of the .NLO files out of the consolidated object repository into a directory called backup. This will simulate a missing .NLO file. 2. Try to open an attachment from inside a mail message of the Domino Administrators mail file. You should not be able to. Observe the console error. 3. Restore the .NLO file back to the DAOS repository and attempt to open the attachment again. The .NLO file should have reconnected, and the attachment should appear. To restore the .NLO file, a simple OS copy works.
Summary
You have successfully completed this exercise when you have: v Used the Notes client to make a copy of a database from another DAOS enabled server with .NLO files being referenced properly on both servers v Understood why you are able to open attachments stored within documents on a database copied through client on a different server v Identified and restored a missing .NLO file. This concludes the DAOS on Notes and Domino 8.5 training. For more information refer to the links in the DAOS Resources document.
DAOS Quick Start Guide

The following guide shows the minimum number of steps needed to get the Domino Attachment and Object Service (DAOS) configured and running. For more detail on all these and other optional steps, see the DAOS Best Practices Guide.
Enabling DAOS
1. Upgrade your Domino server to 8.5.
32
2. Verify that transaction logging is enabled on your server. This is a prerequisite for DAOS. Using show server on the server console, you should see a line stating Transactional Logging: Enabled. Transaction logging can be enabled on the Transaction Logging tab of your server document. 3. Completely disable Shared Mail. Set the Shared Mail field to None on the Shared Mail tab of your server document and run the object UNLINK command to unlink any existing mail files from the shared ones. 4. Fill in the four fields on the DAOS tab of your server document: a. Store file attachments in DAOS: Set to Enabled. b. Minimum size of object before Domino will store in DAOS (bytes): The default is 4096. 64,000 is recommended. c. DAOS base path: Specify a file path for DAOS storage. This file path can be a valid absolute path (for example, C:\DAOS on Windows), or a relative path to be created as a subdirectory of the Domino data directory. The default is DAOS. d. Defer object deletion for (days): The default is 30. This is recommended. 5. Add Create_R85_Databases=1 to the servers notes.ini file. 6. Restart the server. 7. Verify that DAOS is now enabled on the server by typing show server from the server console. You should see a line stating DAOS: Enabled.
Enabling a Notes Database

With the server enabled for DAOS, a user with Administrator rights can enable a Notes database to participate in DAOS using one of three methods: 1. Navigate to the Advanced tab of the Application Properties box and select the Use Domino Attachment and Object Service option. 2. Using the Domino Administrator, select a Notes database from the Files tab and choose Tools - Database - Advanced Properties. - Select the Use Domino Attachment and Object Service option. 3. From the server console, issue a load compact -daos on dbname where dbname is the name of a Notes database. After you use one of these methods, any new attachments created in that Notes database that meet the minimum DAOS size requirement will be managed by DAOS. To enable multiple Notes databases at one time, use option 2 and select multiple files or use option 3 and designate a path or standard Domino indirect (.IND) file rather than a single database (dbname). To enable DAOS on an existing Notes database and move its current attachments into DAOS, you must use option 3 and add an additional flag to the command. Adding the -c flag (copy-style compact) moves existing attachments out of the NSF and into the DAOS repository. The full command is as follows: load compact -c -daos on dbname. You can also run this from the command line with or without the server running. Again, dbname can be replaced by a relative path or standard Domino indirect (.IND) file to act on multiple files. NOTE: This compaction will automatically upgrade the database to ODS 51. NOTE: load compact -c -daos off will disable DAOS on a Notes database and move the attachments back into the NSF.
33
DAOS setup is now complete. To monitor and verify that DAOS is functioning properly, use tell daosmgr status from the server console to give a status or tell daosmgr status databases for a status of all DAOS enabled databases. You can also verify a databases participation in DAOS with the Domino Administrator or the server console command show directory -daos. Monitor DDM messages to verify continued correct operation of DAOS. If you believe that DAOS is not functioning properly at this time, see DAOS FAQ for more information.
DAOS FAQ
How do I determine why the DAOS catalog needs resync? When the DAOS catalog transitions to the state of NEEDS RESYNC a DDM event is fired that will identify the database that first caused the catalog to go into this state. This information can be found in the DDM database or in the log.nsf. The following is a list of operations that cause the DAOS catalog to transition to the state of NEEDS RESYNC: v copy a DAOS enabled database into the data directory from the OS v delete a DAOS enabled database from the OS v rename a database from the OS v delete an NLO from the OS (will transition to NEEDS RESYNC when the NLO is attempted to be opened.) v restore a database directly to the data directory If you can not determine what action caused the catalog to NEEDS RESYNC and it continues to occur, debug code should be enabled. Setting
DAOS_LOGGING=c:\debug\daos.txt STATE_CHANGE
will log all DAOS state change activity. Also enabling DAOS_LOGGING will cause DAOS to output the call stack to the server console that caused the catalog to transition to this state. That should be given to support along with the daos.txt file to help troubleshoot the problem. To clear the NEEDS RESYNC state run a resync by entering the command tell daosmgr resync. Note that while the catalog is in this state DAOS will continue to operate normally. However deletion of NLO files by the PRUNE task will be postponed until the catalog is in the SYNCHRONIZED state again. How do I determine if objects are going into DAOS? You can look in the DAOS directory to see that NLO files are being created. Under the DAOS directory are subdirectories for the containers. Each subcontainer holds 40,000 NLO files by default. Why are new attachments added to a database not creating new NLO files? Verify that the database is DAOS enabled and the status is Read/Write. This is done by entering the command tell daosmgr dbsummary dbname It is also possible that the attachment does not meet the minimum DAOS size requirement. Remember that the size of the object is compared to the DAOS Minimum after it is compressed.
34
The attachment already exists. Attachments are written to a temporary NLO file so that the MD5sum can be calculated. If that checksum matches an existing NLO, the temporary file is deleted. In this case the refcount for the object is incremented. A problem was encountered when creating an NLO file. In this case the fallback is to immediately create a standard, inline NSF attachment. If anything goes wrong along the way (cant create NLO file due to out of disk space, write error, permission, etc.), the DAOS operation returns control to the normal NSF attachment handling code. Worst case, itll get in-lined in the database. How do I determine which databases are DAOS enabled? Run the command tell daosmgr dbsummary. It will display the list of DAOS enabled databases, their ticket counts and their DAOS state. Why are NLO files not being deleted? NLO files are cleaned up (deleted) by the DAOS Prune process that is scheduled to run nightly at 2:00 AM. NLO files are only removed when the DAOS catalog is in a Synchronized state, the NLO refcount is zero, and the NLO was marked deleted longer than the prune interval ago. You can also run Prune from the console with the command tell daosmgr prune prune interval. An interval of zero will cause all NLO files with a refcount of zero to be deleted immediately. Use caution when here as you could potentially delete attachments that have never been backed up. Why cant I open attachmen ts when I open a DAOS enabled database locally? The DAOS references are only resolved through the Domino server. When you open the database locally and you try to open a DAOS attachment you will get the error The object store database is disabled. : Could not save to file c:\tmp\notesEA312D\daosdb.nsf How do I troubleshoot DAOS related database problems? In order to troubleshoot a DAOS related problem off line, or for support to diagnose the problem, the database along with all NLO files will need to be provided. You can obtain a list of all NLO files referenced by a database by running the command tell daosmgr listnlo Note that this is only necessary if the problem is with the attachment. Otherwise a resync of a database with missing attachments will result in Ghost entries in the DAOS catalog, allowing for diagnosis of issues not related to the attachments. How do I troubleshoot non-DAOS related database problems? A DAOS enabled database will function normally as long as attachments are not opened. So if you are troubleshooting a problem that is not DAOS related you do not need to provide the NLO files. Why are some DAOS NLO files missing? One possible cause is the Anti-virus software found a virus and quarantined the file. This can happen when compacting a database into DAOS and a virus is found on an attachment within the database. You should set your anti-virus settings to match you data directory. Also deleting NLO files from the OS will cause problems with DAOS. Why cant I compact a database containing tickets with missing attachments? This can happen due to the reasons above. When you encounter this
35
problem you will need to run fixup -j -D. The -j switch is for transaction logged databases and the -D switch will cause documents with DAOS tickets pointing to invalid or missing NLO files to be deleted. These documents are deleted without a deletion stub so they may replicate back in. Why dont I see the Use Domino Attachment and Object Service option under File -> Application -> Properties? If you are not running a Notes 8.5 client or later you will not see that option. If the database is not ODS 51 or greater you will not see that option. Make sure CREATE_R85_DATABASES=1 is set in the notes.ini and compact -c the database. Adding the -DAOS on flag will directly enable DAOS before the compact. Why do I get error when compacting a large database out of DAOS? If the resulting database would exceed the 64GB NSF limitation with the attachments in-lined within the NSF then you can not compact the database out of DAOS. Why am I getting the error File Not Found when replicating a DAOS enabled database? If an NLO file is missing on one system and that document is replicated, the replicator will report this error. This will cause the replicator to continue to attempt to replicate this document on every replication. If this error is encountered three times in a row the replicator will abort replicating the database. This can be avoided by setting DEBUG_REPL_TOLERATE_ERRORS but does not resolve the problem. There are two ways to resolve this problem: v Restore the NLO file. v Run fixup -j -D to delete the document referencing the missing NLO. Why does DAOS require Transaction Logging to be enabled? Storing attachments in DAOS involves coordinated actions for three different files: the Notes database receiving the attachment, the DAOS file, and the daos catalog (index). Transaction logging is used to guarantee that we can put these distributed pieces of the transaction back into a consistent state after a server crash (T/L redo) or catastrophic failure (recover roll T/L forward). Transaction logging is a requirement for DAOS and you simply cannot use the feature without it. Overall, using transaction logging increases the consistency and integrity of all NSF data. The one area where T/L is optional with DAOS is mail boxes (e.g. MAIL.BOX). T/L mail boxes is optional. There is a performance enhancement that allows optimized routing of messages with attachments to DAOS enabled mail files. Not enabling T/L on mailboxes does not affect the disk space savings from using DAOS. It only disables a performance optimization.
DAOS Best Practices

When it comes to configuring the Domino Attachment and Object Service (DAOS), you may be asking yourself - and us in turn - whats the right way to set it up? For example, is there an optimum Minimum Size setting? Should the repository go under the data directory or on its own drive? Whats the best Deferred
36
Deletion Interval in relation to my backup and restore schedule? This guide, and the documents it references, attempts to answer these questions of individual, site-specific configuration in general terms with guidelines for adapting and modifying them based on measurements made against your particular environment.
Where To Locate Your DAOS Base Path Repository

By default the DAOS repository resides under the servers data directory and defines a single container as indicated by the DAOS Base Path setting in the DAOS tab of the server document. So, on Windows for example, if you use the default, DAOS, and your data directory is C:\Lotus\Domino\Data, the full path to the repository would be C:\Lotus\Domino\Data\DAOS. For Domino 8.5, only this one container may be specified. However, this default location, chosen simply for being well-known, may not be the most efficacious. Some things to consider: 1. What is the total capacity of all file attachments? With only one container in Domino 8.5, flexibility may be important when choosing the best DAOS base path. Youll want to be sure you have significant storage capacity or the ability to reconfigure a logical drive as space needs increase. Use the Domino Attachment and Object Service Estimator to plan for your storage requirements. 2. What I/O costs do I expect to incur? DAOS base path I/O is significantly less than that of Dominos Data directory. In benchmark tests, DAOS repository I/O was 94% less than that of the servers Data directory. Lower performing storage (a NAS device, for example) can be used here. 3. Can I use lower cost or external storage devices? In many cases, you might find attachments are infrequently accessed -- for example, when theyre part of old email messages collecting the proverbial dust in ones inbox. In these environments, locating DAOS on lower cost storage (tier 3) devices may be indicated. On the other hand, if full text indexing, agents, or other applications make heavy use of the consolidated attachments, lower cost storage may cost you in performance. Note: Externalizing the DAOS repository in this manner does not mean you can map multiple Domino servers to the same container. This is an unsupported configuration as of this publication and could very well lead to data loss due to encryption with the servers key. NLO files cannot be shared across Domino servers. Note: Modifying the location of the DAOS repository at a later time is allowed and requires that you first change the DAOS Base Path field on the DAOS tab in the server document, stop the Domino server and then relocate the existing subdirectory structure with its NLO files to the new location. On server restart, the modification will take place seamlessly.
Optimum Minimum Size For Participation

By default, the minimum size setting for an attachment to make use of DAOS is 4096 bytes. While we recommend using 64,000, there are a number of things to consider when determining the best DAOS minimum size setting for your system. 1. Do not set the minimum size lower than the default setting. Due to attachment file overhead, setting the minimum size to anything lower than the default size would actually be less efficient than storing the attachment in the NSF file.
37
2. Set a minimum size that is a multiple of your file systems disk block size. By choosing a minimum size that is a multiple of the disk block size, you optimize disk usage. To ascertain the disk block size for your file system, on a Windows NTFS, use fsutil fsinfo ntfsinfo and take note of the Bytes Per Cluster. This is the disk block size. On Solaris, you could use df -g. 3. Take note of possible limitations on number of files. The smaller you make the setting, the more attachments will qualify for DAOS consolidation. The larger you make the setting, the fewer will qualify. In Domino 8.5, the DAOS repository allows for one container with up to 1,000 subcontainers, each with a maximum of 40,000 NLO files. Thus the storage capacity of DAOS is limited to 40 million distinct objects. This is a significant number of files, so if you expect to come anywhere close to approaching it, you should check the limits on your backup and restore solution, as some applications and file systems have limitations on maximum number of files. Refer to your operating system and/or backup application guidelines. To get an idea of how many files various settings would generate, you can run them through the Domino Attachment and Object Service Estimator. The ultimate goal with this setting is to minimize the number of files in your DAOS repository and maximize the amount of disk space saved.
Deferred Deletion Interval

DAOS automatically deletes NLO files that are no longer being referenced by any databases. This deletion of NLO files is known as pruning and occurs at the specified Deferred Deletion Interval. Establishing a useful Deferred Deletion Interval for your server involves a few considerations, primary among them your backup and restore schedule. You want to ensure that NLO files which are no longer needed remain in existence at least as long as your backup cycle. In this way, they will not be deleted before the next backup. A secondary consideration is the size of attachments typically stored in the repository for your server. If they are usually quite large, you may want to have them cleaned up as quickly as possible after there are no longer any references to them. If your deferred deletion interval is set too high, NLO files which are no longer needed will continue to take up valuable space in the repository. If your deferred deletion interval is set too low, you could be deleting NLO files that have not yet been backed up, thus making it difficult, and in some cases not even feasible, to restore them. It is important to find a balance that satisfies both your backup schedule and the system integrity of a neatly pruned environment.
Pruning
Pruning can also be manually triggered to override the automatic deferred deletion interval. The administrator can issue the console command tell daosmgr prune x to forcibly delete unreferenced NLOs that are x days old. This will recover the disk space still being used by unreferenced NLO files immediately rather than waiting for the automatic deferred deletion interval to do so. When performing this action, you must consider your backup cycles. As with setting the deferred deletion interval too low, pruning too soon could delete NLO files that have not yet been backed up.
38
When Should A Notes Database Use DAOS?

There are several good reasons to select an NSF file for participation in DAOS consolidation. 1. It contains or is likely to have multiple copies of the same attachments. Even a single NSF can benefit from DAOS consolidation. 2. It resides on a server where the same attachments appear across multiple NSF files. If others are also referencing attachments present in your database, why not share? 3. It contains very large attachments. In this case, it may not matter how many other NSF files hold the attachments in question. If theyre large enough, the simple step of storing them outside the NSF can make common operations against that database much faster. While DAOS can always benefit your data, DAOS has less benefit under the follow conditions: 1. Databases have lots of small attachments. Attachment consolidation is less efficient in this scenario due to disk blocking. You can, however, eliminate this issue by adjusting the minimum size setting upward. 2. There is little or no attachment duplication across databases. Backup would still benefit due to extracting static data, but you would have little disk space reduction. 3. Databases contain few or no attachments. In 8.5, DAOS stores only file attachment data. 4. Databases need to be quickly portable. Because DAOS object files (NLOs) cannot be shared across Domino servers, it is more difficult to move DAOS-enabled Notes databases from server to server. Its not necessary for all databases on a server to leverage DAOS, but for those that do, the savings in both space and time, as for example, in much accelerated compact operations, are significant.
Mail.box
Although DAOS will work in any configuration, it operates most efficiently when it is enabled on both the mail.box files and individual mail files. Enabling transaction logging and DAOS on mail.box will enable the Router to optimize the delivery of DAOS based attachments. This can result in significant I/O savings for the case where the same attachment is sent to multiple recipients on the same Domino server. Note: If you have multiple mail.box files, you must enable transaction logging and DAOS on all of them to leverage DAOS cloning, an attachment delivery optimization. Since Domino creates new mailboxes as needed, you should also set these properties on the mail.box template. If you choose not to enable DAOS or transaction logging on the mail box, DAOS will still be used by any DAOS-enabled mail files. Using DAOS on mail.box(es) only affects the optimized routing (delivery) of attachments. When an incoming document is received at mail.box, it is stored there until it is delivered to the individual mail file(s) of the recipient(s). Several results are possible:
39
If DAOS is not enabled anywhere, the document will be stored in mail.box, and the attachment will be stored inline. As the document is delivered to the recipient mail file(s), the document and the contents of the attachment are read from mail.box, and the document is written to the mail file with the attachment inline. Total I/O cost to deliver to N recipients: 1 + N doc writes, 1 + N attachment reads, 1 + N attachment writes. If DAOS is enabled on both mail.box and destination mail file(s), any attachments in that document will be extracted and converted to NLO files as it is being written to mail.box. The document and DAOS ticket are written to the destination mail file(s). IMPORTANT: In the case where both mail.box and the mail file are DAOS-enabled, the contents of the attachment will not be written again as the document is delivered, only a reference to the existing NLO file will be copied. Total I/O cost to deliver to N recipients: 1 + N doc writes, 1 attachment read, 1 attachment write. If DAOS is enabled on mail.box but not on the destination mail file(s), any attachments in that document will be extracted and converted to NLO files as it is being written to mail.box. Since the destination mail file(s) is/are not using DAOS, the attachment must be stored inline, and the contents of the attachment will be read out of mail.box (which has it stored in DAOS) in order to do that. Total I/O cost to deliver to N recipients: 1 + N doc writes, 1+N attachment read, 1+N attachment writes. If DAOS is not enabled on mail.box, but is for the destination mail file(s), the attachment will be stored inline in mail.box. As the document is delivered to the recipient mail file(s), the contents of the attachment are read out of the mail.box document, and a temporary NLO file is created for each destination mail file so that a checksum can be calculated. If an NLO file with the same checksum already exists, the temporary file is deleted. In the case of N recipients, this process will be repeated N times, even though only one NLO file will remain at the end of the process. Total I/O cost to deliver to N recipients: 1 + N doc writes, 1+N attachment read, 1+N attachment writes. IMPORTANT: In this case, although the end result (a single NLO file per unique attachment) is the same, the I/O cost is significantly increased over the case where mail.box is enabled for DAOS.
Mail Journaling
For 8.5, it is recommended that you not enable DAOS on the mail journal (mailjrn.nsf).
Encryption
By default, DAOS employs encryption to safeguard its repository. This setting is separate from encryption settings that apply to an NSF or document. The encryption is done with the server key, so the resulting NLO files can be read only on a server that uses that same key. This may be a consideration for backup or redundant server setup. The performance hit for DAOS encryption is negligible; testing showed a 5% CPU increase with no change in I/O versus unencrypted data. However, if your organization has reason to disable it, weve provided the server notes.ini setting DAOS_ENCRYPT_NLO, which can be set to zero to affect that change. To determine the current status of encryption, use the sh stat daos command from the server console.
40
Compression
While DAOS is compatible with compression, there are a couple of points to remember: 1. Its possible for an attachment to disqualify itself from DAOS consolidation by compressing to a size smaller than the Minimum Size setting. 2. The same attachment, undergoing different compression types, LZ1 versus Huffman versus no compression, will be seen by DAOS as different objects and will, therefore, be shared only with others of like type.
Resynchronization Of The Catalog

In order to ensure that NLO files are not physically deleted when there are still ticket holders referencing them, if there is any reason to question the accuracy of a reference count, DAOS puts itself in a safe mode whereby no deletes are allowed to proceed. This state is signaled to the administrator via the Domino Domain Monitoring systems and is reported as a NEEDS RESYNC state from the tell daosmgr status catalog server console command. To perform this catalog resynchronization manually, type tell daosmgr resync from the server console. Note: The duration of a resync can be significant and depends on the number of DAOS-enabled databases, the number of NLO files in your environment, and your system configuration. It can take several hours to complete causing its execution to overlap into normal business hours. Although Domino and DAOS are functional while a resync is in progress, there may be a degradation in performance while it is running. If you find it necessary to halt the resync operation, you can interrupt it by issuing tell daosmgr quit from the servers console. However, for continued operation of DAOS, immediately restart the DAOSMGR task using the console command load daosmgr. When it is convenient to continue the resync operation, issue tell daosmgr resync again from the servers console and resync processing will continue where it left off. If you choose, you can automate the resynchronization of the catalog using two different techniques. In short, you could either run a scheduled resynchronization via a program document or respond to the Domino Domain Monitoring events that signal a NEEDS RESYNC condition. Both these methods are detailed, complete with screen shots, in the document DAOS: How To Set Up Resynchronization Events With DDM.
Antivirus
Consider DAOS interaction with antivirus scans. Its critical the DAOS base path and .NLO file extension have the same anti-virus policy as the Domino data directory and .NSF file extension. If the two file types have different policies, consolidating attachments from an existing NSF using compact -daos on -c can result in NLO files being quarantined as theyre extracted from the NSF. A user who then opens a quarantined attachment would see a Missing NLO error message.
41
The screenshot below shows how youd configure Symantec Antivirus to exclude the .NLO file extension. From the Configure folder on the left, select File System Auto-Protect. Click the Exclusions button, then the Extensions button. Type NLO without the quotes and click Add.
Attachment consolidation (DAOS) -- Troubleshooting

This topic describes error messages that may occur related to the Domino Attachment and Object Service (DAOS) and how to address the problems. v The DAOS catalog does not exist on page 43 v The DAOS catalog cannot be created. DAOS cannot operate normally. on page 43 v The DAOS catalog cannot be updated on page 44 v The database <database> attempted to access a missing file: <.NLO file> on page 44 v The database <database> was unable to open or read the file <.NLO file> on page 45 v The database <database> was unable to write to file <NLO file> on page 45 v The database <database> appears to have changed at an OS level on page 46
42
v DAOS was unable to rebuild the list of external files while trying to resynchronize on page 46 v DAOS was unable to scan the database <database> to gather its DAOS tickets while trying to resynchronize on page 47 v The database <database> has caused DAOS to postpone deletions until it can resynchronize on page 47 v The DAOS catalog cannot be opened. DAOS cannot operate normally. on page 47 v The DAOS catalog cannot be resynchronized. DAOS deletions will be postponed on page 48
The DAOS catalog does not exist

This message occurs for one of two reasons: v DAOS has been enabled on the Domino server for the first time and the catalog file DAOS uses (DAOSCAT.NSF) is yet to be created. v DAOS has previously been enabled, but its catalog file has been deleted or moved from the servers data directory. A new one will automatically be created. No action by the administrator is required in either case. The new catalog will include any existing .NLO files. DAOS will defer NLO deletion until it has re-synchronized the catalog with all existing .NSF files on the server that contain DAOS references (tickets). Caution Do not replace this new catalog file with any previous backup copy of the file. Instead, use the Tell DAOSMgr command to re-synchronize DAOS references and bring the new catalog up to date. Depending on the number of DAOS references, the Resync command may take time to complete, and is best run at a time when the server is not in active use to avoid compromising performance.
The DAOS catalog cannot be created. DAOS cannot operate normally.

This message occurs when Domino cannot create DAOSCAT.NSF, the catalog file it uses to track DAOS references (tickets) and .NSF files (ticket holders). This catalog file is required for DAOS, so this error causes DAOS to be disabled on the Domino server. Try the following approaches to allow creation of the catalog file. v There may be a file named DAOSCAT.NSF that Domino is unable to remove to create the new file. Remove any existing DAOSCAT.NSF file and restart the server. v There may be a subdirectory/directory link in the Domino data directory named DAOSCAT.NSF that Domino is unable to remove. Remove the subdirectory/directory link named DAOSCAT.NSF and restart the server. v The server may not have appropriate access to create the catalog file in the Domino data directory. Change the access control on the Domino data directory so that the Domino server can create files, and then restart the server. v There may be insufficient disk space on the device holding the Domino data directory to create the DAOS catalog file. Create additional disk space, and restart the server. v The Domino data directory may be on a machine that is experiencing problems such as hardware failure, network failure (if using a networked or NAS device)
43
or any other similar problem. Check the system logs to see if there are any logged events related to problems with the device. Correct any issues, and then restart the server.
The DAOS catalog cannot be updated

This message occurs when Domino fails to open and update the DAOS catalog file (DAOSCAT.NSF). An additional message such as Disk Full may provide information on why the catalog could not be opened or modified. Correct any problem described in an additional message, for example: v Make sure the DAOSCAT.NSF file exists at the root of the Domino server data directory. v There may be insufficient disk space on the device holding the Domino data directory. Create additional disk space, and restart the Domino server. v There may be insufficient disk space on the device where Domino stores .NLO files. Create additional disk space on that device, and restart the Domino server. v Make sure that the Domino server has appropriate access to open and modify the catalog file.
The database <database> attempted to access a missing file: <.NLO file>

This message occurs when Domino, running DAOS operations, fails to access an attachment (.NLO) file that is referenced by DAOS using the cited file path and name. The specified database contains a valid DAOS ticket, but the referenced .NLO file cannot be found. Check the following list for possible causes and potential solutions for this message. v If the server is running antivirus software, the file may have been removed by that software. Set the servers antivirus software to exempt folders used by DAOS, and restore the missing file from backup. v The specified database was restored from backup, but the referenced .NLO file(s) were not restored. Use the Tell DAOSMgr ListNLO command to identify missing files for the specified database, and then restore the files from backup. Depending on the number of DAOS references, the Resync command may take time to complete, and is best run at a time when the server is not in active use to avoid compromising performance. Tip If backup copies are not available, and if encryption on .NLO files is not enabled, it may be possible to copy missing files through the operating system from another Domino server. However, this workaround is not useful if encryption is enabled, because the .NLO files will be encrypted with the key of the other server and therefore unusable on the current server. Note: v The specified database was copied from another server through the operating system, and may contain tickets for .NLO files that exist only on the other server. Delete the database and use the Domino Administrator client to copy the database file from the other server. Copying through the Administrator client properly adjusts DAOS references so that they are correct for any .NLO files that exist on the current server, and they do not specify nonexistent files. v The storage location specified for DAOS files (the repository) is inaccessible. There may be a temporary power outage, powered-off external drive, lost
44
network connection, or similar problem with the machine or device. Check the availability of the device specified for storing DAOS files, and that the specification for it is correct in the Domino Server document. If no such problems exist, check to see that the .NLO file itself exists, and if it is missing, try the approaches above.
The database <database> was unable to open or read the file <.NLO file>
This message occurs when Domino, running DAOS operations, fails to open or read an attachment (.NLO) file that is referenced by DAOS using the cited file path and name. An additional message such as Device Not Found may provide information on why the file was inaccessible. Check the following list for possible causes and potential solutions for this message. v If the server is running antivirus software, the .NLO file may have been removed by that software. Set the servers antivirus software to exempt folders used by DAOS, and restore the missing file from backup. v The storage location specified for .NLO files is inaccessible. There may be a temporary power outage, powered-off external drive, lost network connection, or similar problem with the machine or device. Check the availability of the device specified for storing DAOS files, and that the specification for it is correct in the Domino Server document. Then restart the Domino server. v The .NLO file is corrupted. Restore it from backup and complete the DAOS operation. v The .NLO file was copied from another server through the operating system, and had been encrypted on the other server, so its encryption key is unrecognizable on the current server. To correct this problem: 1. Identify the database(s) that reference the file. 2. To remove the document that contains the ticket for the unreadable .NLO file, on the database(S) containing the document, run: fixup j -d 3. To remove the invalid .NLO from the catalog files list, run Tell DAOSMgr Resync. Note: Depending on the number of DAOS references, the Resync command may take time to complete, and is best run at a time when the server is not in active use to avoid compromising performance. 4. Restore the document to the database(s) by replicating from another server.
The database <database> was unable to write to file <NLO file>

This message occurs when Domino, running DAOS operations, fails to modify or delete an attachment (.NLO) file that is referenced by DAOS using the cited file path and name. An additional message such as Device Not Found may provide information on why the file was inaccessible. When DAOS is enabled, Domino always stores attachment data in locations outside of Notes databases and may store data outside of the Domino data directory (for example, on an external drive if the DAOS repository is there). When any of these external locations for data becomes inaccessible, Domino reverts to storing data in a Notes database until the problem is corrected.
45
v Check that the storage location (repository) specified for .NLO files is accessible. There may be a temporary power outage, powered-off external drive, lost network connection, or similar problem with the machine or device. v Make sure that the specification for the storage location is correct in the Domino Server document. v To correct any instances of attachment data incorrectly stored in databases while desired locations were temporarily inaccessible, compact the databases (copy-style compact). v Restart the Domino server.
The database <database> appears to have changed at an OS level

This message occurs when Domino is rebuilding the DAOS catalog (DAOSCAT.NSF) and encounters changes to a database that is included in DAOS. An additional message may provide information on how the database changed. The following are some examples of changes: v The database was deleted and restored from a backup copy through the operating system. v The database was moved through the operating system and subsequently modified by users. v The database was overwritten through the operating system using a copy from another server. Until a re-synchronization is performed, DAOS will suspend deletions of shared .NLO files since some databases may contain a usable reference to such a file. v A compact operation on the database failed, causing the DAOS catalog to fail in updating its information about references in the database. After the DAOS catalog has been recreated or updated, compact the database (copy-style compact) to correct its DAOS-related information. If the database was copied from another server, also run the Tell DAOSMgr Resync command. Tip Depending on the number of DAOS references, the Resync command may take time to complete, and is best run at a time when the server is not in active use to avoid compromising performance.
DAOS was unable to rebuild the list of external files while trying to resynchronize
This message occurs when Domino fails to complete the list it builds of all attachment (.NLO) files in DAOS while running a DAOS re-synchronization. To avoid possible data loss, until this error is resolved, attachments will be stored inside Notes databases as if DAOS were not enabled. Note: This should not be a frequently occurring error. An additional message may provide information on why DAOS failed to complete the list. Some possible causes include sudden inaccessibility of the storage device as a result of power loss or loss of network connection. To correct this problem, run the Tell DAOSMgr Resync command.
46
Tip Depending on the number of DAOS references, the Resync command may take time to complete, and is best run at a time when the server is not in active use to avoid compromising performance.
DAOS was unable to scan the database <database> to gather its DAOS tickets while trying to resynchronize
This message occurs when a problem with the specified database stops DAOS from re-synchronizing its references related to the database. An additional message may provide information on the problem that blocked re-synchronization. Some possible causes of this message are: v The database has DAOS tickets but is not known to be enabled for DAOS on the current server. v The database has been deleted through the operating system. v The database was renamed during a DAOS operation. v The database was deleted during a DAOS operation. To correct problems with the database, restore it from backup if necessary, run a copy-style compact on it, and then run the Tell DAOSMgr Resync command. Depending on the additional error information, you may also want to run Fixup on the database. Tip Depending on the number of DAOS references, the Resync command may take time to complete, and is best run at a time when the server is not in active use to avoid compromising performance.
The database <database> has caused DAOS to postpone deletions until it can resynchronize
This message occurs during DAOS operations when Domino encounters a database whose information no longer matches what is known in the DAOS catalog file. DAOS operation is automatically discontinued to avoid possible data loss. This mismatch between the catalog and a database could have been caused by deleting a database through the operating system instead of using the Domino Administrator client, or restoring a version of the database after a backup that does not have the same information as the DAOS catalog. To correct this problem, run the Tell DAOSMgr Resync command. Tip Depending on the number of DAOS references, the Resync command may take time to complete, and is best run at a time when the server is not in active use to avoid compromising performance.
The DAOS catalog cannot be opened. DAOS cannot operate normally.

This message occurs when Domino cannot access DAOSCAT.NSF, the catalog file it uses to track DAOS references (tickets) and .NSF files (ticket holders). Opening this catalog file is required for DAOS to verify or update .NLO file information, so this error causes DAOS to be disabled on the Domino server. An additional message such as Disk Not Ready may provide information on why the catalog could not be opened.
47
Try the following approaches to allow Domino to open the catalog file. v The server may not have appropriate access to the catalog file in the Domino data directory. Change the access control on the Domino data directory so that the Domino server can open files, and then restart the server. v The Domino data directory may be on a machine or device that is experiencing problems such as hardware failure, network failure (if using a networked or NAS device) or any other similar problem. Check the system logs to see if there are any logged events related to problems with the device. Correct any issues, and then restart the server. If neither of the conditions above exist, you can cause Domino to recreate a fresh catalog database. 1. Stop the Domino server. 2. Create a backup copy of the DAOSCAT.NSF to send to IBM Technical Support. 3. Delete the catalog file. 4. Restart the server. 5. After Domino has recreated the catalog, use the Tell DAOSMgr Resync command to re-synchronize DAOS references. Tip Depending on the number of DAOS references, the Resync command may take time to complete, and is best run at a time when the server is not in active use to avoid compromising performance.
The DAOS catalog cannot be resynchronized. DAOS deletions will be postponed

This message occurs when the Tell DAOSMgr Resync command does not complete. An additional message such as Device Not Found may provide information on why the re-synchronization stopped. There are two likely causes for this message: v Re-synchronization stopped while Domino was scanning existing .NLO files in order to rebuild its list of all files on the server. To correct this problem, check that the storage location specified for .NLO files (the repository) is accessible. There may be a temporary power outage, powered-off external drive, lost network connection, or similar problem with the machine or device. v Re-synchronization stopped while Domino was scanning a database for tickets in order to rebuild its list of all tickets held by all databases on the server. You may be able to correct the problem by running Fixup on the cited database. After the problem is corrected, run the Tell DAOSMgr Resync command.
DAOS Resources
Use these resources to learn more about DAOS.
Links
v Attachment consolidation (DAOS) -- Troubleshooting v IBM Lotus Domino and Notes information center v Article on DAOS Estimator, a tool to plan roll-out of DAOS on a Domino 8.5 server v DAOS entries in the Domino wiki
48
v v v v v
DAOS Quick Start Guide DAOS FAQ DAOS Best Practices DAOS Backup and Restore The Domino blog
DAOS backup and restore

Covers a number of backup and restore issues.
Backup considerations for DAOS

In a standard Notes database (NSF), the attachments are stored inside of the NSF file itself, and the database is self-contained. In order to back up a standard Notes database, only the NSF file itself needs to be backed up. After you introduce DAOS, the NSFs that participate in DAOS contain only references to the NLO files where the attachment content is stored. As a result, backing up the NSF alone is no longer enough. The NLO data needs to be backed up as well. When performing standard NSF backups, there are two main approaches. The individual NSF being backed up can be taken offline (or the entire server can be stopped) so that no changes occur to the NSF over the duration of the backup operation. The other method allows the NSF and server to remain active, but requires using a backup utility program that interacts with the Domino backup/restore API. Using a utility ensures that a consistent copy of the NSF contents is recorded, despite any changes that occur to the NSF over the duration of the backup operation. None of the processing for NSF backups needs to change for DAOS. The change needed to accommodate DAOS is simply a procedural addition: in addition to backing up the NSF data, you must also back up the NLO data. Backing up the NLO files in the DAOS repository can be done either while the Domino server is down, or when it is up and running. The backup does not require the use of any Domino API-based utilities. Once NLO files are written initially, Domino never modifies their contents, so the backup mechanism does not have to work around file-write activity. NLO files can be backed up as any other generic file on the file system. Only the NLO files that are complete and not in the process of being written to or renamed need to be backed up. Any that are busy can be skipped until the next backup. Most backup applications will automatically skip files that they can not read because of other activity.
Order Matters
If you shut down the Domino server during the backup process, the NSF and NLO files can be backed up in any order. If you must keep the Domino server up and running during the backup process, it is important to back up all the NSF data before backing up the NLO files. The reason has to do with the addition of references to new NLO files in an active system, described in this section. When you back up an NSF that participates in DAOS, there are some number of NLO references contained in that NSF at the time of the backup. Since there is some duration to the backup operation for all NSFs, the number of references to NLO files may be increasing over that duration in a system that is operating during the backup process. If there were (for example) 10,000 NLO files referenced
49
collectively by all the NSFs at the beginning of the NSF backup process, there could be 10,100 by the time the last NSF is backed up. Likewise, the backup of the NLO data has a duration as well, so while there might have been 10,100 NLO files at the beginning of the NLO backup process, there could be 10,200 by the time the last NLO is backed up. In this scenario, the backed up version of the NSFs could reference at most only 10,100 NLO files. Because the NLO backup was done after the NSF backup process, the NLO backup included at least that many, but may have as many as 10,200 NLO files. Worst case, there are more NLO files backed up than strictly necessary to satisfy the NSF references. Since all accesses to the NLO files are done through the NSFs, and the NSFs were done first, all of the referenced NLO files are guaranteed to exist in the set of NLO files that were backed up. If there is an error accessing an NLO file in order to back it up because its in use, that can safely be ignored. If the file is being written, the activity must have occurred after the NSF was backed up; therefore, this NLO file does not need to be in the corresponding set of NLO files, and will be backed up as part of the next cycle. The deferred deletion interval should be set to a period longer than your chosen backup cycle. In this way, the NLOs are not pruned (physically deleted) prior to the next backup. Instead, the actual deletion is deferred until theyve aged accordingly. If you were to have a shorter or nonexistent deletion intervalthe feature can be disabled by setting it to zero in the DAOS tab of the server documentit opens a window of time during which a deleted attachment is non-recoverable, as the NLO file has been physically deleted before the backup has occurred. Avoid pruning NLO files from the repository (by issuing a prune command at the Domino console) before they have had a chance to be backed up; you will prevent them from being recoverable. When an attachment is deleted, and the associated NLO files reference count goes to zero, it becomes a candidate for deletion. The deferred deletion interval determines when the deletion actually occurs. If the deferred deletion interval is set (as recommended) to be longer than the backup cycle, all NLOs will be in existence for at least one backup cycle, and therefore any NLO can be recovered later. After the initial full backup of the NLO files in the DAOS repository, you can perform incremental backups, which save only the data that has changed since the last backup. NLO files are ideal candidates for incremental backup because there are no changes to them after their initial creation. One NLO file is created for each unique attachment, so it is possible to have a very large number of NLO files in large deployments. The maximum number of files per numbered DAOS subdirectory is 40,000, and there can be 1000 subdirectories, for a maximum total of 40 million NLO files. Check with your backup utility specifications to see if there is a limit on the total number of files it will manage, and monitor the growth of the DAOS directory file population accordingly.
Daoscat.nsf and daos.cfg

The daos.cfg and daoscat.nsf files should not be backed up. These two index files can be re-created from the DAOS repository and the NSFs participating in DAOS if necessary. If these files become corrupted, they can be safely deleted while Domino is not running. They will be created on startup automatically.
50
The daos.cfg file helps manage the files in the DAOS repository. The NLO files are stored in subdirectories (0001, 0002, and so forth) underneath the base DAOS directory. For several reasons (including performance), DAOS limits the number of NLO files in each subdirectory. The daos.cfg file keeps track of how many files are currently in each subdirectory so that DAOS puts new files in subdirectories where the count of files is below that limit. As NLOs are deleted, the corresponding file count is decremented, allowing backfilling of older subdirectories. The daos.cfg file is expendable, and will be re-created at Domino startup time if it is missing. The daoscat.nsf file contains two indexes. One is a list of all NSFs that are holding NLO references (DAOS ID Table, or DIT.) The second is a list of all NLOs that exist, and the DAOS repository subdirectory they exist in (DAOS Object Index, or DOI). There are no externally visible parts to this NSF, and there are no privileges that apply to change that. The DIT is modified when an NSF acquires its first NLO reference. The DOI is modified when a new (unique) NLO is created. The daoscat.nsf file is expendable, and will be re-created at Domino startup time if it is missing. Since a full resync can take a significant amount of time, only empty indexes are created by this process at startup. A resync operation should be done as soon as it is convenient, however. In some cases it could be necessary to fully reboot the server until the daoscat.nsf and the daos.cfg are re-created. A DAOS resync operation (tell daosmgr resync) fully re-populates these two indexes from scratch. You can also run the command [n]daosmgr resyncif you want to perform a resync operation with the Domino server shut down.
Transaction logging
Because all NSFs that participate in DAOS have to also participate in transaction logging, the contents of all their attachments will be included in the log. Any NLO files that are created as a result of activity to the NSF will be re-created if the log is replayed.
Command examples
Using the Tivoli Storage Manager (TSM), the command to back up the DAOS repository would be:
dsmc incremental c:\lotus\domino\data\daos
where the path specified is the full one to the DAOS repository. Since the NLO files are being backed up incrementally, the initial backup will be quite large, but subsequent ones will be much smaller. The total footprint of the DAOS directory will be written out during the first backup.
DAOS enable/disable considerations

Once a Domino server has DAOS enabled, and NSFs are selected to participate in DAOS, their attachments are stored in the DAOS repository. If DAOS is subsequently disabled, the attachments that were in DAOS remain in DAOS until they are re-integrated into the NSF. Any DAOS references that remain in the NSF will continue to be serviced by DAOS, even if it is disabled. An NSF that contains DAOS references is not self-contained, and must continue to be treated as an active DAOS participant as long as it has DAOS references. To re-integrate the DAOS attachments into an NSF and remove the DAOS references, you can process the
51
NSF with the compact -c -daos off command. Once that is done, the NSF will be self-contained again, and can be treated as a normal NSF. Furthermore, to ensure that the DAOS enablement change takes effect completely, the Domino server as well as all processes that use the Domino API (compact, resync, backup, etc) are stopped. This allows the API to terminate completely, so the status change can be picked up at the next startup.
Space and Time Savings

The disk footprint savings with DAOS continues into the backup processing as well. The NLO files represent the static data that used to reside in the NSF, and was backed up every cycle even though it hadnt changed. In a typical mail environment, a large reduction in the NSF footprint plus a very small amount of NLO data means the reduction in the NSF footprint translates almost directly into a reduction in the backup footprint. Not only is the duplicate data being eliminated, the mailfile data is being separated into static and dynamic components. By applying an incremental backup regimen to the static (NLO) data, only the NLO files created since the last backup cycle need to be processed. That represents typically a very small amount of data compared with the entire set of NLO files. Using DAOS enables backup software solutions to optimally backup the NLO files. This is because once an NLO is written to disk, it never changes. Therefore, the file need only be backed up once in its lifetime. Based on the example shown in the DAOS Estimator document [link], the space saving per full backup would be 38.8 GB, roughly equal to the number of shared NLOs times the average NLO size. In the incremental backup case, duplicate NLOs will not be backup up again. Thus, the space savings from DAOS is directly proportional to the numbe r of duplicate NLOs seen in the environment, and the backup time savings is the product of the space saved and the backup throughput.
Restoring DAOS Objects

A well-preserved DAOS repository makes for fast and easy restoration. And, while not really a backup mechanism, the default deferred deletion interval allows for accidentally deleted attachments to be saved from physical deletion up to 30 days after a mishap. Simply pull the document out of the trash folder, if soft deletion is enabled. If its too late for that, restore from backup, then resynchronize the DAOS catalog using the server console command tell daosmgr resync force -- DAOS will once again recognize that the NLO has references. Although an NLO will survive for the period of time specified by the deferred deletion interval, if soft deletion is disabled or a backup of the referencing document has not been made, there is no way to get at the contents of the NLO, especially if encryption is enabled (the default).
Restoring Documents or NSF Files with DAOS Attachments

To restore either a full NSF or a single document, the process starts off the same. You must first restore the database and then the missing NLOs. To do this using Tivoli Data Protection for Domino, you would issue the command:
domdsmc restore -into
52
To determine which missing NLO files to bring back from the Domino server console, run
tell daosmgr listnlo -o missing.txt MISSING restoreddatabasename.nsf
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
If you are restoring the entire NSF, you are done. Note that any restoration operation will put the DAOS catalog into the Needs Resync state, so a resync operation should be performed as soon as convenient. If you need only one document, you can now copy and paste it to its intended destination. For a complete recovery after a catastrophic failure, the NSF and NLO files can be restored, followed by replaying the archived transaction logs. This will result in the most up-to-date recovery situation.
Dealing with damaged files and/or clusters

If an NSF is damaged, and you have clustered servers or replicas of the NSF on another server, you have several options. 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.
53
Options for restoration

The need for restoring NLO files depends partly on the deferred deletion interval. If the restore is happening from a snapshot thats within the interval (for example, the interval is 30 days, and the NSF is being restored from last weeks backup) its not possible for any of the NLOs to have been deleted yet, so there shouldnt be a need to restore any NLOs. If the NSF being restored is older than the interval (for example, the interval is 30 days, but the NSF being restored is from 3 months ago), its possible that some of the NLOs have been deleted, and would need to be restored. Some of this also depends on what the reason for the restore is. If its a catastrophic failure, you should restore the NSF(s) and run tell daosmgr listnlo missing filename.nsf to get a list of all of the NLOs needed to make it whole again. That list should then be fed into the restore utility to restore those NLOs as well. If its just a matter of getting a single document with attachments back, you dont really need everything to be made whole to access just that one set of attachments. In the spirit of Work smarter not harder, you can restore the NSF, and then attempt to access the desired document (and attachments, if any) and finally deal with any missing NLOs that are mentioned during that operation. If there arent any attachments on the document, theres no other work to be done. If there are attachments, the NLOs may still be there, so its worth trying to access them before doing anything else. If any are missing, youll get a console message that mentions the name of the NLO, at which point you can restore only what you need.
Offline Archival
For offline archival purposes, it is recommended that the attachments be re-integrated into the NSF using a compact -c -daos off operation prior to archiving. That eliminates the need to archive all the individual NLO files referred to by the NSF also. For example, if an employee was leaving the company, and their mail account was being closed and archived, this approach would be appropriate.
54

Daos

Uploaded by

Copyright:

Available Formats

Daos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Daos

Uploaded by

Copyright:

Available Formats

DAOS for Notes and Domino 8.

DAOS for Notes and Domino 8.5

DAOS for Notes and Domino 8.5

DAOS on Notes and Domino 8.5

Prerequisites and system requirements

Exercise 1, Part 1: Enabling DAOS on the server

DAOS for Notes and Domino 8.5

Exercise 1, Part 2: Configuring Mail files to Participate in DAOS

Exercise 1, Part 3: Observing the space savings with DAOS

DAOS for Notes and Domino 8.5

DAOS on Notes and Domino 8.5

DAOS for Notes and Domino 8.5

Exercise 2, Part 1: Enabling DAOS on mail.box

Enabling DAOS on mail.box

DAOS for Notes and Domino 8.5

DAOS on Notes and Domino 8.5

Exercise 2, Part 2: Assessment

DAOS for Notes and Domino 8.5

Questions and Answers

DAOS on Notes and Domino 8.5

Exercise 3, Part 1: Evaluating with tell DAOSMgr commands

DAOS for Notes and Domino 8.5

The DAOS catalog

Evaluating tell DAOSMgr commands

Exercise 3, Part 2: Resynchronizing

DAOS for Notes and Domino 8.5

How do I know if my DAOS catalog needs resynchronization?

How to set up an automatic resynchronization ddm event

DAOS on Notes and Domino 8.5

DAOS for Notes and Domino 8.5

Exercise 4, Part 1: Simulate a missing .NLO file

How is the DAOS repository maintained in a safeguarded way?

DAOS for Notes and Domino 8.5

Exercise 4, Part 2: The tell DAOSMgr prune command

DAOS on Notes and Domino 8.5

DAOS for Notes and Domino 8.5

Exercise 4, Part 3: DAOS and corruption

DAOS on Notes and Domino 8.5

DAOS for Notes and Domino 8.5

DAOS on Notes and Domino 8.5

Exercise 5, Part 2: Replicate a database from a DAOS enabled server to local

DAOS for Notes and Domino 8.5

DAOS on Notes and Domino 8.5

Exercise 6, Part 1: Using different compression formats

DAOS for Notes and Domino 8.5

Exercise 6, Part 2: Sending mail from one DAOS server to another

DAOS on Notes and Domino 8.5

DAOS for Notes and Domino 8.5

DAOS on Notes and Domino 8.5

Exercise 7, Part 1: Copying through the Administrator client

DAOS for Notes and Domino 8.5

DAOS on Notes and Domino 8.5

Exercise 7, Part 2: Identifying and restoring a missing .NLO file

DAOS Quick Start Guide

DAOS for Notes and Domino 8.5

Enabling a Notes Database

DAOS for Notes and Domino 8.5

DAOS Best Practices

DAOS for Notes and Domino 8.5