The issue can be experienced with sogo-tool on large LDAP directories.
Message from James Ray on his:
=== SNIP ===
All
I think the sogo-tool backup is failing for my installation due to its
size...
$ /usr/GNUstep/System/Tools/Admin/sogo-tool backup ./ ALL
<0x0x20e032b8[SOGoCache]> Cache cleanup interval set every 300.000000
seconds for memcached
<0x0x20e032b8[SOGoCache]> memcached error: unable to cache values with
subtype attributes for user z. .x.yyyy@maildomain.tld
2009-12-14 11:37:07.022 sogo-tool[444] Failed to recurse into directory
'/usr/GNUstep/System/Library/Libraries/gnustep-base/Versions/1.16/Resources/NSTimeZones'
-
- Too many open files
2009-12-14 11:37:07.021 sogo-tool[444] Could not bind to the LDAP server
auth-dir.domain.tld (389) using the bind DN:
2009-12-14 11:37:07.022 sogo-tool[444] Could not bind to the LDAP server
auth-dir.domain.tld (389) using the bind DN:
2009-12-14 11:37:07.026 sogo-tool[444] File NSData.m: 922. In
[NSDataMalloc -writeToFile:atomically:] Open (./userxyz) failed - Too
many open files
The LDAP server stopped working after 1000 connects in a min due to the
bad internal workings of the sogo-tool I think. From what I can tell it
searches the directory and then connects to query each user individually
causing a connection flood and poor performance.
Anyone able to offer assistance in the best way I can back up SOGo? I am
currently just doing full database dumps every night.
=== SNIP ===
If the issue is exposed using sogo-tool, the issue should also be present when sogod runs as usual. | 
