1Charles Rayer  4/20/2010 5:50:42 PM  Not so fast

We have been operating a DAOS 8.5.1, +FP1, +FP2 environment for 400+ users and the primary mail server DAOS catalogue needs resyncing every 2 hours or so and takes up to 1.5 hours to do it. On our DR server it only loses sync once every couple of days. We were left with 155GB of mail occupying 245GB of disk including the DAOS files!

We have nearly completed the de DAOSing and the server is running much better. We used the excellent built in archiving instead on the DR server to save the space and the users and finance dept. are now both happy!

  2Darren Duke  4/22/2010 8:41:15 AM  Not so fast

@1, while I can't comment on your particular situation, I have seen occasions where the catalog needs resyncing often (far too often). In these situations we just ignore it and run a weekly (or monthly) command to resync it. There were some fixes in 8.5.1 FP1 IF1 that purported to address some of these issues, but I have yet to see proof and there should be an 8.5.1 FP2 IF1 pretty soon to migrate these fixes to FP2.

Some items I "think" may cause this issue are:

1) DAOS being on the same drive as Domino AND high mail volumes

2) TX Logs not being big enough (100MB default? Really IBM?)

3) TX Logs not being on a separate drive.

You must have a huge throughput of email (new email, large number of attachments, large amounts of deleted email) if a "needs syncroinizing" DAOS catalog causing an OVERALL increase of mail sizes. Now that I have not seen, but I've not seen a lot of things. Still, you live and learn.

  3Charles Rayer  4/22/2010 9:32:33 AM  I think you might be right

The attachment sizes and volume thereof are fairly large AND the DAOS store was on the same drive as the Domino data. Combined with jornalling on the server you might have hit the nail on the head there. We also used 4K+ as the DAOS starting point which was probably too low...

If we try again we will use 64k+ and a different RAIDset for the DAOS data files.

The TX logs were on their own RAID 10 set with plenty of space

Thanks,

Charles

  4Darren Duke  4/22/2010 10:00:12 AM  I think you might be right

You may want to run the DAOS estimator on the server to see the best min-size to savings ratio. On huge attachments counts it could even be upped to 128KB. Also if you are on an i5, the min should be 1MB.

  5Rashid malik  4/30/2010 10:27:39 AM  Backup and Restores

We've a huge archive server with over 1000 archives mailboxes with average size of around 10 gigs. The total server storage is over 3 TB and we are running out of storage fast. We could add more disk but looking for a solution that would cut the backup time as well as the storage. We can't delete old emails just yet.

We started to pilot with DAOS but one draw back we see if that if we were to restore a nsf file that has been deleted for sometime, the restoration of the nlo files would be extremely difficult unless we restore the entire DAOS directory. In one test, we enabled DAOS on a 25 gig nsf file. After the compact completed, the nsf went down to 3.5 gigs but we ended up with ~ 17 gigs of NLO files totaling just over 38,000. Setting the nlo size to 2 megs didn't result in much saving. Next I'll be testing with 1 meg nlo file size.

Any thoughts or recommendation on file restores?

  6Darren Duke  4/30/2010 11:39:32 AM  Backup and Restores

@5, DAOS on a single mail file on a given server will not yeild much in the way of significant disk savings. This is obvious if you think about, how many of the exact same attachment do I have in a single mail file? Maybe 3 to 6 copies, most of the time 1 or 2. Where the real space savings in DAOS come from doing 100's or 1000's of mail files on the same server. That is where you will see 45-65% savings per server, but this is overall, not per NSF file.

For backup I don't see an issue. If you restore an NSF, you can have DAOS tell you what NLO files are missing, then pipe this into your choosen backup program. See this post on how to restore - http://blog.darrenduke.net/Darren/DDBZ.nsf/dx/daos-my-2-cents-and-a-possible-future-and-how-to-back-it-up.htm?opendocument&comments

  7Rashid Malik  4/30/2010 3:04:48 PM  Backup and Restores

@6, I read your post on the backup & restore... good information there.

Concern I've is, if I'm restoring a nsf file that has few thousand nlo files, it would be a very tedious process to locate and restore them from the backup tape. It would be nice to have a separate folder for each nsf where nlo files would be kept, unless those nlo's are shared among multiple nsf files. I guess they could then go under a shared folder.