Lotus Domino NSF mailbox file size?

10 pts.
.NSF files
Domino 6.5
Domino Administrator
I'm a new Domino administrator and please forgive me if I make comparisons to Exchange because that's what I've mostly used in the past. Anywho, in Exchange I was generally taught not to let the users mailboex get over 2 GB for fear of corruption. I believe they can go bigger, but this was the practice. On our current Domino 6.5.5 server I have a number of mailboxes: 24 boxes ranging from 3GB to 9GB 13 boxes ranging from 10GB to 20 GB 2 boxes from 20 to 30 GB And 1 box that is whopping 33GB. I'm using the Domino Admin 7. Should I be worried about this? What are the limits of the nsf size? What is the best practices in regard to this?

Answer Wiki

Thanks. We'll let you know when a new response is added.

From an administrator that works with Domino for more than 15 years I would say:

Before Domino 5 the limit was 4 Go. after Sky is the limit. but their is best practice and also performance. a database that is biger than 4 Go can give the user some performance issue. but the worsk is when a server crash. If transaction log on not activate (server document / transLog) the server will do a consitency check on the database and it will take forever to restart the server. so it is best to archive the email in those database. and use quota so the email database will not go over 4 Go. that is verry big for email. It is also a good practice to delete attachement in the mail database.

Enjoy your new task. Administering domino is a very cool Job with some god Chalenge.

These limitations are tested, known limits. Pushing Notes databases to these limits would likely have performance impacts and would have to be carefully tested.

I am not a server administrator. However, I would expect that these huge maibox sizes should be managed. In the links below, you will see the tested upper limit in R6 is 64 gb. That doesn’t mean these large file sizes are not a problem.

I would expect a more complete answer, including some best practices, from administrators on this forum. Have you searched the IBM R6 forum for related questions?

IBM R6&7 Forum.

Discuss This Question: 5  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Mblazar
    All of the information from the previous answer is good, but the concern is really about you and what you want to do. There is nothing wrong with files that big, but they certainly can become unmanageable. The bigger the data, the bigger the views, indicies, etc. And if it corrupts, you have a major concern around restoral. I would personally look to break it up into archives (I always go with yearly ones) just so that I could manage the files easier. But it's completely up to you. The files are fine as is. It's a choice of risk management at this point.
    335 pointsBadges:
  • Fummy
    Huge nsf files cause some trouble. For Example, server crush, database corrpt, taking long time for maintenance, and so on. In my experience, size of database should be less than 2 GB. I took the trouble to maintain Huge nsf files.
    10 pointsBadges:
  • Davidkillingsworth
    I manage an environment with 700 mailboxes that are greater than 2GB. The physical limit is 64GB as listed in the links above. However, anything beyond 2GB becomes very difficult to manage. 1. Database become corrupt very often. 2. Running Fixup or Compact on a weekly basis as part of Domino routine maintenance becomes problematic because the server is always running the maintenance on the databases. In fact, you'll need to split up fixup and compact to run on specific directories during different evenings of the weeks. 3. Backups take forever. 4. Opening the mailboxes takes a very long time because it has to index the inbox every time you open it (if the user does not file messages to folders, which most don't). 5. You pretty much can't have full text indexing turned on because the full text indexing will be continuous around the clock on your server. 6. We've had some very strange things happen with Blackberry Enterprise Server accessing very large mailboxes and causing the BES servers to crash. 7. If users have local replicas of their mailboxes, sometimes their hard drive is not large enough, sometimes the local replica becomes corrupt on the hard drive because no maintenance is ever run on it. 8. Creating new replicas onto new servers can take a week. The list goes on. These are real world examples of issues that I come up against every week. The best practice is to have quota policies in place that the upper management supports. The second major thing to note here is that a proper archiving solution needs to be implemented. The local archiving that is built into Notes is often times not sufficient if you have so many huge mail files.
    175 pointsBadges:
  • divingdwarf
    As a Lotus Notes victim humble user, I can say nsf files above 1,5-2GB may be a bad idea. You may not lose emails, but their location (in folders) will not be the same,as they may be dislodged, if you allow me the term.
    Actually, having any size of nsf files is bad. NSF files are bad by definition. Lotus is evil. Worse than you can imagine and totally useless and worthless for average e-mail users. If you can, go for Outlook. Lotus's programmers have bizarre neuronal connections which makes them think in a different and ilogical way. Their brain pathology proofs they are no valid human spezimens for social life together with other individuals of average reasoning.
    Congrats to Lotus Notes Sales Team. If you sold that "artifact" to so many companies, you can sell me the Moon if you want it.
    Sorry for my English.
    10 pointsBadges:
  • Magie007
    Bigger the data, bigger the risk. Although the handling all comes to the performance that is beneath the database. If the performance of the server and the client and the network can manage, the database of a greater size should be handled well. But at a size near 64 GB the trouble comes in a package, once itget corrupt, most of the maintenance task (compact, fixup, updall) will not help, from this point DB can only get restored or replicated back from a working one.
    Running compact on weekly basis (e.g.Friday night) in your case for all mailboxes can impove the performance.
    215 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: