I have three questions related to DAOS and its functionality.
-
When documents(with attachments) present in a DAOS enabled database is locally archived, are the actual attachments copied into the local archive db.If so,does it happen smoothly.I guess if there is only one reference to an attachment(NLO file) then after archiving the NLO/attachment file will also be removed from server repository.Is it true.
-
When we have the users in an organization spread over several mail servers how advantageous is DAOS.Consider a situation wherein a user belonging to particular MailServer sends an attachment to 5 users whose mail files are located on five different MailServers.I believe in this case,the NLO file/attachment is saved in the repository of all five+1(sender’s) MailServers.In this case we don’t achieve disk space savings.What is the advantage of DAOS in this kind of a situation.
-
Is their something which might come up in later releases of Domino that can be termed cross server DAOS.It could be something that addresses my second question above.
Subject: Very good
- When documents(with attachments) present in a DAOS enabled database is locally archived, are the actual attachments copied into the local archive db.If so,does it happen smoothly.I guess if there is only one reference to an attachment(NLO file) then after archiving the NLO/attachment file will also be removed from server repository.Is it true.
Yes to both. The client does not know that the replica on the server is DAOS-enabled, so all replication operations between a local copy (and an archive as well) continue to work normally. Once the reference count for a NLO goes to 0, it will be a candidate for deletion. How quickly that happens depends on the deferred deletion interval for your server.
- When we have the users in an organization spread over several mail servers how advantageous is DAOS.Consider a situation wherein a user belonging to particular MailServer sends an attachment to 5 users whose mail files are located on five different MailServers.I believe in this case,the NLO file/attachment is saved in the repository of all five+1(sender’s) MailServers.In this case we don’t achieve disk space savings.What is the advantage of DAOS in this kind of a situation.
The advantage of DAOS is twofold. There is very often a savings in overall disk footprint by eliminating duplicate copies of an attachment. In the situation you describe however, that would not be the case. The OTHER benefit of DAOS (and quite possibly the more valuable one) is that the NSF data is being segregated into ‘static’ and ‘dynamic’ data. There are operational benefits that come from having this data stored separately.
Take a mail environment for example: typically attachment data is not referenced very often (compared with the subject/date/sender//body data from the document), and modified even less often than that. Until now it all had to be stored on top performing disk, and backed up every backup cycle. Even if there is no disk footprint savings (which is unlikely given typical email traffic) DAOS would provide benefits in disk requirements, backup processing, as well as other maintenance operations,
-
Because the attachment (NLO) data has a lower traffic rate, it can be stored on cheaper disk, such as NAS.
-
NLO files are never modified by DAOS after their initial creation, except to delete the unused ones. That means incremental backups can eliminate a huge chunk of the backup data volume.
-
Other maintenance operations such as compact have less data in the NSF to shift around, which makes them faster.
The reduction in backup data volume is approximately the same as the reduction in the data directory footprint. That’s because the volume of new attachments is tiny in comparison to the total data footprint. For example, if you had 1000Gb of NSF data, and then enabled DAOS, you might end up with 500Gb of NSF data and 200Gb of NLO data. That means instead of backing up 1000Gb every cycle, you back up 200Gb of NLO data once, and then only need to back up 500Gb of NSF data, plus whatever new attachment data was created since the last backup, maybe 2Gb.
old: 1000Gb every cycle
new: 500Gb + 2Gb every cycle
Even if you assume NO footprint savings with DAOS (500Gb of NSF data and 500Gb of NLO data) you still eliminate needing to back up the static attachment data every cycle, and end up with the same ‘502’ answer as above.
- Is their something which might come up in later releases of Domino that can be termed cross server DAOS.It could be something that addresses my second question above.
We’ve considered it, but there are no promises currently.
Subject: Thank You
Thanks Pat,Ben and Ulrich for the responses.It would definitely help me by taking these new inputs from you to my customer as a new proposal.
Subject: I would not be in for that request for this single point of failure.
Subject: out of my memory …
-
Correct - Once the last reference to the attachment is gone, the attachment disappears on the server, too (I think by default after 4 weeks or so - this allows easier backup).
-
Correct - the current Version of DAOS is run by server. The main advantage would be that
- there is no disadvantage, the secondary advantage is that the system allready will know that there is a copy of this file and will have it allready detached when the second one arrives.
(If you thinkt there is no doubles of the vast majority of your attachments, you should look into compression enhancments of 8 or 8.5, too)
- At Lotusphere it was stated that the DAOS repository tends to be with less activity than what you would expect for the NSFs including the files (Things get written once, not too much reads little changes only). - Slower disks might be fine here. Less Data to move around e.g. when compacting on the nsf side. (No big wins but at least no losses either).
hope this helps. - You don’t have to use it, it is optional, but I sure love the concept, especially the fact that one can restore for weeks without having to care for the nlos, as they are simply still there.
Feedback number WEBB7QNA6Q created by Melwin Paul on 31.03.2009