Leveraging DAOS for storage optimization and backup
Daniel Nashed – 25 January 2026 15:07:32
Domino DAOS (Domino Attachment and Object Service) was introduced in HCL Domino 8.5, released in 2008.
It replaced the old approach "Single Copy Object Store which never really worked well.
In contrast DAOS is much simpler and robost approach where the server gernerates an unique hash for each backend object behind an attachment and creates a NLO file (Notes Large Object) storged outside the .nsf file.
But still not everyone is lerveraging DAOS -- It can have also have great benefit on backup.
Benefits:
- Deduplication can save ~ 30% dpending how attachments are spead
- Up to 60% - 70% of storage could be either deduplicated or storged in DAOS which leaves the .nsf file to like 30% - 40% of the original .nsf file.
- .nsf requires high perfomance disks and generates many small I/O operations
In contrast DAOS uses larger I/O operations and works well on standard disks -- which already is great optimization
- The smaller .nsf files are also easier to maintain. DBMT and other operations are working much faster on smaller databases
- DAOS .nlo files are written once and a reference count is maitained. in daoscat.nsf.
In contrast to .nsf this makes .nlo files the perfect ingremental backup candiate -- which doesn't require a Domino aware backup
- This means you can focus on the way smaller .nsf files for online backup
Consider DAOS also for backup purposes
If you never used DAOS, you should really consider looking into it and review your backup strategy.
When encryption is disabled the DAOS store is also a candidate for cross server deduplication.
You could point DAOS for multiple servers to a deduplicating storage provider to gain more storage benefits and central DAOS backup.
DAOS Tune
How to find out how DAOS would look like for your server?
The new DAOS Tune replaces the earlier DAOS Estimator.
It is completely rewritten, much faster and provides more details.
DAOS Tune can run without specifying and parmeters, but also supports more detailed analysis options.
Here is a sample scan for the DNUG production server -- which is not fully representative but shows the principle.
In our case we would only gain 15% deduplication.
But you can see that the remaining space in NSF is around 50% -- even on this small server..
When analayzine our DNUG server I noticed DAOS Tune wasn't yet in the container image.
You can now automatically add it to the container image via -daostune build option.
- Comments [3]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}
1Paolo 27.01.2026 22:53:54 Leveraging DAOS for storage optimization and backup
You are suggesting storage-side deduplication using ZFS.
But at what cost? How much RAM is actually required?
Read this thread:
https://www.truenas.com/community/resources/zfs-de-duplication-or-why-you-shouldnt-use-de-dup.205/
In the TrueNAS world, for those on a tight budget, deduplication means investing in a lot of RAM.
2Daniel Nashed 28.01.2026 7:18:33 Leveraging DAOS for storage optimization and backup
@Paolo, deduplication would be on the backup pool. Not at the live Domino data pool.
Deduplication takes performance and is not recommended for Domino.
But for backup deduplication makes a lot of sense.
Yes it needs RAM like 1 GB per 1 TB of deduplicated data (not logical data).That's perfectly fine.
The article comes back with more RAM requirements. But that also depends on block size.
The block size for Domino would be 16k to 32k. But for the backup pool it is perfectly fine to stay with the default 128K block size.
Yes you have to watch your RAM and CPU. But this isn't for normal operaitons. It's for backup only.
ZFS could be on the local host or a central appliance you can talk to over NFS -- like a TrueNAS or any other storage appliance.
We have customers running large HP Eysilon machines pointing terrabytes of data of DAOS storage to it for deduplicating live DAOS data.
Nothing is every free. You usally have to pay at some point. So dedup comes with RAM and a bit CPU overhead.
From CPU point of view the most important recommendation today is to use hardware that offloads SHA operations. That's more a challenge in the cloud than with modern local hardware.
Hardware in the cloud when not using high end is often using the older CPU generations without SHA hardware support.
That's something to look at for ZFS but also for TLS operatons. For smaller servers the difference isn't that big. But when looking into enterprise deployments the additional cost for a modern CPU is well invested.
3Mike Trost 28.01.2026 9:15:18 Leveraging DAOS for storage optimization and backup
@Daniel this whole ZFS topic is really, really interesting and honestly deserves a proper article.
We also have 4 Domino servers (in a cluster) running on different operating systems (IBM i, Windows, and RedHat Linux). They are effectively clustered together, and each of them has its own private key for NLO attachments, but essentially the NLO configuration for objects >64 KB is stored on local storage.
Now we’re at the point where we need to recover terabytes of NLO data from our storage, and it’s starting to hurt… we’re talking about roughly 8 TB per server, with several million NLOs.
As a low-cost solution, we were thinking about using TrueNAS (most likely as a VM) mainly for cost reasons (NetApp is really too expensive).
We ran some basic tests with TrueNAS SCALE, disabling encryption on the NLO side and, on TrueNAS, creating one dataset per machine (shared via CIFS for Windows, NFS for Linux, and SMB for IBM i). What we noticed is that by setting a 64 KB block size, deduplication works, but there is no compression at all.
Unfortunately, encryption does not work across different datasets, so we will probably end up using a shared key across the various servers.
According to your reasoning, TrueNAS would need about 8 GB of RAM, whereas we’ve read recommendations of about 5 GB per terabyte… which would mean around 40 GB of RAM in our case.
What’s your experience with this? Do you think it’s crazy to proceed this way?
We can’t move the data to AWS S3, otherwise we would have gone with a Tier 2 solution.