Hi Darren, how are you backing up your data with DAOS ?

tks, sean

Per the IBM link above:

< snip >

1. 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 eight days for the setting "Defer deletion of DAOS objects n days" in the server document.

2. 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 Lotus Domino C API Toolkit.

3. Back up the DAOSCAT.NSF and DAOS.CFG files. These files are located in the data directory.

4. 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.

5. After the first backup of the DAOS repository, perform incremental backups as desired of both NSF and NLO files.

6. (Optional) 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.

< / snip >

We have a cluster server that is still 8.0.2 and that is what we backup until I verify that Backup Exec 12.5 can indeed backup and restore DAOS.

Note, NLO files are encrypted by the server they are stored on via the server ID file. This means you can only restore the NLO files to a server running the same ID file.

Hi Darren

Does DAOS work in a clustering environment? Since the files are encrypted with the server id do you need to back up all servers in a cluster? If I want to copy over a database on a server that does not have DAOS, does it work? If I would like to change back a DAOS database to a non DAOS how easy is it?

thanks

vlad

vlad - each member of the cluster will have DAOS enabled (or not) independently of other cluster members.

As each server had it's own DAOS storage folder (which is file level, and therefore not clustered) and as each server uses it's own ID file for encryption it can be said to be a per server setting. The non-DAOS cluster members don't know or care about this as to Domino, Notes, C-API and anything else it "looks" like the attachments are still in the Notes DBs.

As for turning it off, from the help it looks like it cannot really be turned off, but can be "disabled":

< snip >

Read Only - DAOS is currently disabled on this server. Because DAOS was previously enabled, file attachments exist in the DAOS repository, and are read when documents containing them are retrieved. New copies of any attachments, whether or not the originals are already stored in DAOS, are stored in documents instead of in the DAOS repository.

< /snip >

So it looks like when it is disabled, attachments are now left in the document but all documents prior to disablement are left in DAOS.

You could "revert" by creating a new server (with DAOS disabled) and replicating all the dbs across.

Note, I HAVE NOT TESTED ANY OF THIS. PROCEED AT YOUR OWN RISK.

Sometimes when creating new servers (and this is not the "preferred" way) you can copy the NFS files across via a file copy. With DAOS enabled you CAN NO LONGER DO THIS.

You will have to use Domino replication to pull the NSF files to the new server (and this is the "preferred" way anyway).

Hi Darren

It makes sense what you says... After re-reading how DAOS works it seems that:

-it is mostly designed for emails and occurs when an email is broadcasted... What would happen with the existing attachments (before you enable the DAOS)? Are they saved once or multiple times?

-would a regular application benefit from DAOS?

-personally I do not see any advantage from encrypting the file with the server id. Is it possible to choose to not use the encryption?

Any idea?

Thanks

vlad

Lets see...

1) Prior to enabling DAOS the attachment would be stored once per mail file. After DAOS the attachment is saved only once. Note, that this also looks to be true for replies to the original email that have the exact same attachment but I can't vouch for this yet. Do the math and this is powerful stuff. 1.5MB attachment to 10 people = 15MB of attachment data without DAOS. Post DAOS the server only stores 1.5MB attachment. Now, (and if replies work like I think they do) someone does a "reply to all with history and attachments".......

2) Probably not. Unless you have the same attachment in multiple documents.

3) I don't think encryption can be turned off. As to the reason why, I guess it is so that admins (or users) can't go snooping for personal, private or secret data in the NLO files. I'd rather it be encrypted than not.

browsing through notes ini settings at { http://www.ibm.com/developerworks/lotus/documentation/notes-ini/ I have noticed "DAOS_Encrypt_NLO" setting which "Specifies whether encryption is enabled or disabled for subsequently created .NLO files in the Domino Attachment and Object Service (DAOS) repository"... } I have noticed "DAOS_Encrypt_NLO" setting which "Specifies whether encryption is enabled or disabled for subsequently created .NLO files in the Domino Attachment and Object Service (DAOS) repository"...

It is really helpful for a clustered environment and not only (imagine that you would like to change the server's name). I would not worry about the admins. If a user email is encrypted, the attachment would be encrypted and protected when saved... still admins already have access to the databases and to the users' id as well.

vlad

Obviously as the default is enabled you'll want to add this ini setting before you convert any databases.

If the OS is compromised.....

At least with Domino even if the OS is compromised Domino and the email file "should" still be safe depending on the setup and OS. But unencrypted NLO files are at risk.

The big advantage I see from NOT enabling encryption is that you can now do (5) again.

I recently observed that using replication as the "preferred" method of transfer .nsf's to a new server has some risks... if any documents are in a truncated status, they won't be copied to the new server and will be effectively lost (the same documents work fine on the old server, though, so even though they say they're "truncated", they're still useful and need to be kept). This caused a number of end user complaints during one of my server upgrades. To remedy it, I found there were 2 possible solutions:

(1) write an agent to compare the document counts of each nsf between the old server and the new one, and if the document counts don't match, compare all UNID's between the two and fire a "document.CopyAllItems" at each one that's missing, and sync the UNID value on the new doc in the destination db.

(2) perform a compact -c -daos off <nsfpath> and then perform an operating system copy, and then afterwards perform a compact -c -daos on <nsfpath> on the new server.

I use solution (1) more often because it's easily mass automated in a notes agent (Set it and forget it), however sometimes I have to use solution (2) because the # of UNID's in the nsf is too large for an agent to handle (I have the agent email me when that happens). I don't like solution 2 though because it requires manual interaction with the server console and the compact takes foooooooreeeeeeeverrrrrr.