这两年接到的自建邮箱咨询有个共同点：预算单上写得清清楚楚——几核 CPU、多少 G 内存、几块硬盘，但上线三个月后出问题的地方，几乎从来不在那张单子上。卡的是 Web 端登录要转圈，是搜索一封半年内的邮件等七八秒，是某天早上队列里堆了两千封没发出去，是老板的手机收不到新邮件。这些症状背后其实是同一件事：Zimbra 的资源消耗是分层的，而多数人按"一个邮件软件"的思路去估。
我把自建 Zimbra 的选型拆成三本账来算：内存账、存储账、反垃圾账。三本账各自独立，又互相抢同一台机器的资源。算错的代价不是"跑不动"这么直白，而是"能跑，但慢得让人怀疑人生"，等你想改的时候，数据已经在那台机器上了，迁移窗口比当初装机还难排。这篇就按这三本账往下讲，中间穿插投递成功率、拆分时机、备份粒度这些容易被跳过的事。
先把架构说清楚，不然后面的账没法算。Zimbra Collaboration 不是单一进程，安装器一次性装进去的软件栈大致分这么几层：代理层是 nginx，占着 80、443、143、993、110、995 这些端口，做 TLS 终结和后端路由；MTA 层是 Postfix，配 amavisd-new 做内容过滤、SpamAssassin 做垃圾评分、ClamAV 做病毒扫描、OpenDKIM 做外发签名，收进来的信经 LMTP（默认 7025）投给后端；存储层是 mailboxd，一个跑在 Jetty 上的 Java 应用，管邮件正文 blob、IMAP/POP 后端、Web 客户端、SOAP/REST 接口和管理后台（7071）；再往下是 MariaDB，存的是元数据——哪个邮箱 ID 对应哪个账号、文件夹结构、邮件已读未读状态、标签、日历条目；搜索索引是 Lucene，每个邮箱一套独立索引文件；目录服务是 OpenLDAP，账号、域名、服务等级（COS）、服务器配置和全局配置全在里面，是整套系统的"真相源"；剩下的 logger、snmp、memcached 是辅助角色。
关键点在于：这六七组进程默认全装在一台机器上，装完 zmcontrol status 能看到一列 Running。它们吃的资源类型完全不同。Java 吃的是连续的大块内存和 GC 停顿；MariaDB 吃的是缓冲池和随机写 IO；Lucene 吃的是大量小文件的随机读写；amavisd 的每个子进程是独立的 Perl 进程，吃的是瞬时内存和 CPU；ClamAV 吃的是常驻签名库内存；Postfix 队列吃的是磁盘空间和文件句柄。你在租用页面看到的"8 核 16G"是一个总数，真正决定体验的是这个总数怎么被这几组进程分掉。
还有一条容易被忽略：Zimbra 自带并"占领"了整台机器。它把 Postfix、OpenLDAP、Jetty、MariaDB 全都装在 /opt/zimbra 下，并且有自己的配置守护进程 zmconfigd 会按 LDAP 里的属性重新生成配置文件——你手工改 Postfix 的 main.cf 或者 nginx 的 conf，下次重新生成就被覆盖掉了。所以别在同一台机器上再装别的服务，尤其是别留着系统自带的 Postfix，端口冲突能让你白白耗掉一个下午。这个约束反过来也意味着：这台机器最好专用。
内存这块我一般按"三分法"给客户做初稿，然后再按实测调。Zimbra 装机时会按当时物理内存的比例自动设两个值：Java 堆（mailboxd_java_heap_size）默认取系统内存的 30% 左右，MariaDB 的 innodb_buffer_pool_size 取 25% 左右。这两个默认值是 installer 一次性算出来的，之后你加了内存它不会自己跟着涨，这是第一个坑——很多人把机器从 16G 升到 64G，堆还是当年的 4.8G。
经验配比大致是这样：16G 内存的机器，堆给 4 到 6G；32G 给 6 到 8G；64G 给 8 到 12G。超过大约 6G 之后，堆再往上加的收益明显递减，多出来的内存给 MariaDB 缓冲池更划算。缓冲池的粗判方法是让它略大于数据库的实际体积（有说法是 1.2 倍上下），你可以用 mysqltuner 这类工具对比 /opt/zimbra/db 的实际大小和缓冲池配置，缓冲池小于库体积就会出现内存和磁盘互相折腾的情况。这两个数字公开资料的口径并不统一，各家的负载形态差别太大，我建议以自己跑两三周的实际占用为准。
Java 堆不是 Java 进程的全部占用。JVM 还要留给线程栈、元空间、堆外内存和代码缓存，Zimbra 是重多线程的应用，光线程栈就能吃掉几百 MB（官方文档建议把栈调到 256k 并监控 StackOverflowError）。所以"堆 6G"在一台 16G 机器上意味着 Java 进程整体可能接近 8G，再叠加 MariaDB 缓冲池、ClamAV 签名库、amavisd 子进程、操作系统页缓存，16G 其实相当紧。我自己的分界线是：只要开了 ClamAV 且要跑全文索引，起步就上 32G。
还有一个必须写进方案的判断：Zimbra 一旦开始 swap，性能是断崖式的，不是"慢一点"。Java 堆被换出到磁盘再换回来，GC 停顿会从毫秒级变成秒级，用户看到的就是点一下等十秒。所以宁可把堆和缓冲池调小一点，也绝不能让它们加起来逼近物理内存。配置完之后盯一段时间，确认 si/so 长期为 0，再考虑往上加。
这个现象我见过太多次了。内存不够的时候，Zimbra 很少直接给你一个 OOM 崩溃，它会先进入一种"谁都没坏、但都很慢"的状态——这恰恰是最难排查的。
链条是这样的：堆紧张，GC 频率升高，每次 Full GC 都会 stop-the-world，Web 端请求排队；同时 MariaDB 缓冲池命中率下降，元数据查询开始走磁盘；同一时刻 amavisd 在收信高峰派生了几个子进程，内存被进一步挤占；操作系统开始回收页缓存，Lucene 索引读也变成真磁盘 IO。四个环节同时变慢，用户感受到的是"邮箱卡了"，但你看 zmcontrol status 全是 Running，看服务端口全通，看 CPU 可能才 40%。
判断方法有几个具体抓手。看 /opt/zimbra/log/zmmailboxd.out 里有没有 "To-space exhausted"，或者 GC 日志里的回收前后数字是不是长期贴着堆上限跑；看 gc.log 里的 Pause 时间有没有成串地超过几百毫秒；看 Postfix 队列长度，正常应该在十几封以内，突然涨到几百说明投递链路被堵住了；看系统的 si/so 和 MariaDB 的 Innodb_buffer_pool_reads（物理读次数）是不是在涨。这四个指标我都建议做进监控，比看内存占用百分比有用得多。
反过来，如果堆配得太大而机器内存不够，你会看到的是另一种卡法：进程 RSS 涨到接近物理内存，然后 OOM killer 挑一个进程杀掉，mailboxd 被杀后由守护进程拉起来，用户感觉是"邮箱刚才掉线了两分钟"。这属于典型的一开始就把 mailboxd_java_heap_size 设成 30% 上限、后来又在同一台机器上加了别的东西导致的结果。
多数人算存储的方式是：每人 10G 配额 × 100 人 = 1T，然后去买一块 2T 的盘。这个算式错在它只算了邮件正文的 blob，而 /opt/zimbra 下面至少还有四样东西在同步长大。
第一是搜索索引。Lucene 给每个邮箱维护独立索引，会随邮件量增长，公开的经验值大致是正文存储的百分之几，具体比例各家口径不一（我见过 3% 到 8% 的说法），得看你开没开附件内容索引、中文分词怎么配。第二是 MariaDB 的元数据。每封邮件、每个文件夹、每条日历项都有行，库体积通常是正文存储的百分之一到百分之几，但它对 IO 的敏感度远高于体积占比。第三是日志：mailbox.log、gc.log、nginx 访问日志、Postfix 日志，光 GC 日志一天就能有一两兆，日志不轮转的话撑爆根分区是常有的事。第四是备份副本和二级存储：一份本地备份至少等于一份数据量，再加一份异地副本，实际占用直接翻倍；如果开了 HSM 做冷热分层，还要算上二级卷。
还有一个隐性项是删除保留期。用户删掉邮件不等于空间立刻释放，回收站（dumpster）会按策略保留若干天，合规要求严的单位保留期更长，这部分空间要按"最坏情况"预留，不能按"用户实际占用"估算。
有个公开的万人级单实例部署数据可以参考：正文存储 8T 左右、索引 400G 上下、数据库 110G 上下，跑在一台 8 vCPU、64G 内存的虚拟机上，稳定跑了多年。这个比例关系比绝对数字有用——索引和数据库加起来大概是正文的百分之几，但它们的 IO 压力远超这个比例。按年估增长的话，我一般让客户按"人数增长 × 单账号年均增量 × (1 + 索引和数据库系数) × (1 + 备份副本系数)"来算，示例场景：200 人的单位，单账号年均增 1.5G，两年就是 600G 正文，加系数和一份备份副本，1.5T 起步比较稳。
存储这块最容易被低估的不是容量，是 IO 形态。邮件系统的 IO 画像非常难看：一封邮件在磁盘上就是一两个小文件，索引是大量几十 KB 到几 MB 的段文件，元数据是成千上万条小记录。用户的每一次 IMAP 同步、每一次搜索、每一次打开 Web 端，都在触发大量随机小读；每一封进来的信都在触发几次随机小写加索引追加写。
机械盘在这种负载下的问题不是带宽不够，是随机 IOPS 太少——单块企业级 HDD 的 4K 随机读能力只有几十到一两百 IOPS 这个量级（具体数值看型号和队列深度，公开资料口径不一，建议自己用 fio 实测）。几百个活跃用户同时用 Web 端，IOPS 需求轻松破千，机械盘立刻成为瓶颈，表现就是搜索转圈、文件夹切换慢，而 CPU 和内存都很闲。所以我给客户的结论很直接：Zimbra 的存储一律上 SSD，正文和索引放 NVMe。容量不够可以外挂，IO 不够只能换盘。
冗余方面，早期的官方性能建议里明确提到账号数超过 100 就不建议用 RAID5，原因是写惩罚加上重建时间——大容量盘的 RAID5 重建窗口内再来一块盘出问题，数据就没了。现在更常见的做法是 SSD/NVMe 做 RAID1 或 RAID10，再把备份单独放到另一套存储上。这里有个常被忽略的点：写密集型负载要关注 SSD 的写入寿命（DWPD/TBW），邮件系统加上每日备份的读取、索引重写的写入，年写入量并不小，消费级盘的保修条款可能不覆盖这种用法。
文件系统层面，挂载加 noatime 是低风险收益明确的一项，能省掉大量访问时间更新的小写。另外把 /opt/zimbra 单独分区或单独挂盘，避免日志或备份把根分区写满导致服务异常——这条我见过太多次，真的是小事拖成大事故。
第三本账是很多人装机时完全没算的。amavisd-new 是预派生模型的 Perl 服务，每个子进程常驻一份 SpamAssassin 环境；ClamAV 的 clamd 要把病毒特征库整库加载进内存。这俩加起来是除 Java 之外的第二大内存支出，也是 CPU 的主要消耗者。
amavisd 的子进程数（max_servers）直接决定并发处理能力和峰值内存。按常见的经验表：8G 内存配 3 个，16G 配 5 个，24G 配 6 个，32G 配 8 个。单个子进程的常驻内存，不同资料给的数字从 100–200MB 到 250–300MB 都有，差别在 SpamAssassin 规则和 Perl 版本，我建议装完直接 ps 看 RSS 实测。那么峰值内存就是"子进程数 × 单进程占用"，再叠加 clamd 的签名库常驻——ClamAV 签名库的内存占用说法差异更大，从几百 MB 到数 GB 都有人写，这个必须以你自己的实际观测为准，别照抄。
CPU 方面，反垃圾是吞吐量瓶颈的主要来源。一封带附件的信要经过解压、规则匹配、病毒扫描、贝叶斯打分，CPU 时间是毫秒到百毫秒级。白天收信高峰如果队列开始积压，说明扫描吞吐跟不上，要么加核、要么调参（比如限制扫描体积上限，超过一定大小的附件不做全文扫描——实际中大附件携带垃圾特征的概率本来就低）、要么把 MTA 拆出去单独给核。
维护成本也不能不算：SpamAssassin 的规则要定期 sa-update 更新，最好配合 sa-compile 把规则编译成 Perl 二进制提速；ClamAV 的 freshclam 要保持病毒库新鲜；贝叶斯数据库要持续喂料学习。这三件事都是定时任务，也都会在某天悄悄失败——比如某个版本升级后 cron 里的命令路径变了，规则半年没更新，垃圾识别率肉眼可见地下降，而你看监控一切正常。
这是自建邮箱最真实的长期成本，且几乎不出现在任何预算表里。反垃圾的阈值调得越激进，误判（把正常邮件判成垃圾）就越多；而误判的处理是纯人工的——用户打电话说客户的报价单没收到，你去日志里翻、去隔离区里捞、加白名单、写规则例外。
Zimbra 的处置路径大致三种：放行、拒收、隔离。放行是评分没过线直接投递；拒收是在 SMTP 会话阶段就拒绝，好处是省资源，坏处是对方不知道、你也捞不回来，遇到重要客户的邮件被拒就是事故；隔离是把信扣在服务器上等管理员或用户自己处理，最安全但最费存储也最费人力。网络版提供了 Allow/Block/Quarantine（ABQ）这类按账号管理的机制，开源版/社区构建在这块的可用手段要少一些，这是两者在运维体验上差别很大的一处。
贝叶斯库是最容易被"装上就忘了"的东西。它要在真实语料上学习才能准，装完如果不做 ham/spam 的学习投喂，效果基本等于没开；做了投喂但喂错了（比如用户把大量正常通知拖进垃圾），库会被污染，误判率反而升高。我的建议是：上线前先定好"谁来喂、喂什么、多久检查一次"，最好让用户的"标记为垃圾/非垃圾"动作能回写到学习流程，同时配一条定期检查误判的例行工作。
还有一层是外部依赖：RBL 黑名单、URIBL 查询都依赖外部 DNS，你的 DNS 解析质量会直接影响判定结果。用公共递归 DNS 做大量 RBL 查询有被限流的风险，自建一个本地缓存解析器是更稳的做法。这些都是"反垃圾账"里的隐藏条目。
自建邮箱最难的部分其实不在服务器里，而在服务器外。对方收信方判断你这封信进收件箱还是垃圾箱，靠的是 DNS 记录和 IP 历史，跟你在 Zimbra 里做了多少优化基本无关。
四项基础工作：PTR（反向解析）必须做，且反向解析出来的名字要和你的 HELO 名、A 记录对得上，没有 PTR 的发信地址在大厂那里是高概率进垃圾箱甚至被拒；SPF 用 TXT 记录声明哪些 IP 可以为你的域名发信；DKIM 在 MTA 侧签名，关键是选择器要真的发布到 DNS 上——我见过太多"Zimbra 里显示已启用 DKIM，但 DNS 里没那条记录"的情况，结果是每封信签名验证都失败，还不如不开；DMARC 声明策略，从 p=none 观察开始，看报告确认没问题再往 quarantine、reject 收紧。这四项的检查工具有很多，mxtoolbox、mail-tester 这类在线工具够用了。
PTR 有个现实约束：只有 IP 段的拥有者才能设置反向解析，所以必须向机房或运营商提交申请。是否支持、多久生效、是否收费，一律以机房或运营商的实际政策为准，不同机房差别很大，这件事要在下单前就问清楚，别等装完系统才发现做不了。
25 端口是更大的现实约束。绝大多数公有云默认封锁出站 25 端口（AWS 可申请解除、GCP 和 Azure 更倾向于引导用户用自家邮件服务、DigitalOcean 按个案处理），国内主流云厂商多数默认封禁、部分支持工单申请解封。具体到你手上的这台机器，是封是放、能不能申请，以机房与运营商政策为准，下单前先实测：装个 netcat 去连外部邮件服务器的 25 端口，超时就是被封。如果被封，现实路径只有两条——申请解封（要企业资质、用途说明，且不保证长期稳定），或者把发信交给中继服务（Smarthost），自建只保留收信能力。后者是更常见的选择，但它意味着你的投递信誉部分取决于中继服务商。
最后一条是 IP 预热和黑名单检查。新拿到的 IP 没有历史记录，大厂会谨慎对待，前几周要控制发信量逐步爬升；如果是机房分配的 IP，接手当天就该去主流黑名单查一遍——从别人用过的地址段里分到一个"脏"IP 并不罕见，这个也要在开通时就查，别等发了半个月才发现一直进垃圾箱。
拆分是有明确触发条件的，不是"人多了就该拆"。我先说该拆的三种情况：一是邮件量涨到单机扛不住，尤其是收信高峰时反垃圾扫描把 CPU 吃满、队列开始积压；二是合规或审计要求把对外暴露的那一层和存数据的那一层物理分开——MTA 是唯一直接面对互联网的组件，也是被扫描、被攻击最多的组件，把它和邮件存储隔离是有实际安全意义的；三是维护窗口扛不住，邮箱服务器要停机打补丁或者升级，但公司半小时都断不起邮件。
典型的拆分路径是这样：先拆 MTA，把 Postfix + amavisd 那一套挪到独立节点，两个 MTA 做主备 MX；再拆代理层，两台 nginx 前面挂一个虚拟 IP；目录服务做成一主一备（LDAP master 加 replica），各层都去查只读副本；最后才是横向加 mailbox 存储节点——每个邮箱在任一时刻只属于一个 store，靠 zmmboxmove 在节点间搬账号。
再说说不该拆的情况。人数在三五百以内、有正常备份、有人值班的场景下，我一般建议先单机，把省下来的预算投到内存、NVMe 和备份上。原因很实在：拆成多节点之后，你要维护的东西是成倍增加的——证书要在每台机器上发和续、监控项从一套变成四套、备份要在多个节点之间保持时间点一致（这是最容易出事的，各节点备份时间差个几十分钟，恢复出来就是不一致的数据）、升级顺序也变成硬约束（先升 LDAP、代理、MTA，再升 store，滚动升级期间新旧版本的 store 混跑还有一堆注意事项）。见过太多单位拆完之后维护质量反而下降，因为人手根本没变。一台做好的服务器，胜过四台做坏的服务器。
还有一点要提前讲清楚：Zimbra 的存储节点没有 active-active 的邮箱级故障切换。丢一台 MTA，对外发信会在存活的那台上排队，收信方会重试第二优先级 MX，数据不丢；丢一台代理，虚拟 IP 漂过去，用户会话重连，秒级恢复；丢 LDAP 主节点，登录靠副本还能工作，但改账号改配置会失败；丢一个 mailbox 存储节点，那上面的邮箱就是离线状态，直到恢复或者搬走。这个事实决定了你的高可用设计重心应该放在哪——备份和快速恢复，比堆冗余节点更实际。
备份这件事，90% 的团队做到"每天跑一次、日志显示成功"就停了。真正要命的问题是另外三个：能不能恢复到单封邮件？恢复要多久？最近一次演练是什么时候？
先说粒度。整库恢复（把整个 store 恢复回来）是最容易实现的，但现实中最常发生的是"某个用户三天前误删了一封重要邮件"或者"某个账号被误删了"——这两种情况你不可能为了一封邮件把整台机器回滚。Zimbra 网络版在 10.x 里集成了备份恢复和所谓的 Message Reclaim（与被删除邮件保留机制打通，用于找回误删内容），可以按全局、服务器、COS、域名、账号等级别做备份和恢复，也支持先恢复元数据和账号、再恢复 blob 的高级恢复模式——因为 blob 恢复占了恢复时间的大头，先把账号恢复上线能显著缩短不可用时间。开源版和社区构建没有这套内置能力，得自己搭备份方案并把粒度问题想清楚，这是两者在运维上的核心差距之一。
再说一致性。邮件系统是个持续写入的系统，直接对运行中的 /opt/zimbra 做文件级拷贝，拿到的很可能是不一致的副本（数据库和 blob 对不上）。稳妥做法是停机做快照、或者用支持一致性的存储快照、或者先停 mailboxd 再备份。这个"停机窗口"就是备份窗口，它决定了你的备份策略能不能真的落地——如果一天的数据量在备份窗口内拷不完，你就得改成全量加增量的组合。10.x 的备份方案提供了自动分组和全量加增量日志两种模式，前者更适合单 store 上账号数很多的大规模环境。
最后说演练。我给客户的最低要求是每季度做一次真实恢复演练，并且计时：从触发恢复到账号可用要多久、到 blob 全部恢复可用要多久。这两个数字决定了你的 RTO 目标是不是现实的。演练要覆盖三种场景——单封邮件恢复、单账号恢复、整机重建。只做第三种，前两种出问题的时候你会发现方案根本不支持。备份副本本身也要有一份异地，跟生产机不在同一台物理设备、最好不在同一个机房。
版本选择这块我尽量讲事实，不做推荐。Zimbra 目前由 Synacor 拥有，主线版本在 10.1.x 系列，分商业的网络版（Network Edition）和开源版（OSE）。10.x 之后官方不再发布免费的开源版二进制包，源码仍然公开，社区有自行构建发布的项目（比如 GitHub 上的 maldua/zimbra-foss），这类构建是非官方的，按第三方软件的标准去评估它。另外 Zextras 维护的 Carbonio 是另一个常见的同源分支选择。版本演进的具体细节以官方 Release Notes 为准。
功能差别集中在几件具体的事上，按公开的版本对比资料：实时备份与恢复、分层存储管理（HSM）、卷压缩、卷去重、邮件归档与 eDiscovery、委托管理、活动报告、审计日志浏览，这些是网络版才有；移动侧的 ActiveSync 推送同步、移动设备策略管理、ABQ 放行/阻止/隔离、Outlook 的 MAPI 连接器，也在商业版的范畴里。基础能力——邮件/通讯录/日历、Web 客户端、POP/IMAP、CalDAV/CardDAV、集成的反垃圾反病毒、多域名、LDAP 与 AD 集成，两边都有。
所以真正的选择点是三个具体问题：你们要不要官方的支持渠道？你们有没有能力自己做备份和单邮件恢复？手机上要不要推送？三个问题里只要有任何一个答案是"要/没有"，开源版的总体成本就不见得低——省下的授权费会以运维人力的形式花出去，而且花得更隐蔽。反过来说，如果你们有 Linux 运维能力、能接受自建备份方案、手机上用 IMAP 收就够了，开源版是完全能跑生产的，社区里万人级的实例也确实存在。
硬件门槛上，公开的安装资料给的最小配置大致是 4 vCPU、8G 内存、/ 分区留 50G（数据都在 /opt/zimbra 下），开了杀毒和搜索索引的建议 16G 起步，生产环境普遍建议 16G 以上。这个"最小值"和"能跑得好"之间差距不小，别拿它当选型依据。
安装器会解析主机名，hostname -f 必须返回完整的 FQDN，/etc/hosts 里要把服务器的真实 IP（不是 127.0.0.1）映射到这个 FQDN，MX 记录要指向它。这条不满足，install.sh 可能直接中止，或者装完 MTA 静默不工作。判断方法很简单：装机前先 hostname -f 看返回值，再 host -t mx 你的域名 看解析结果。避免方法就是把 DNS 的 A、MX、PTR 三条在下单和装机之前就准备好，别"先装起来再说"。
这是自建邮箱最大的单点风险。原因前面讲过，云厂商普遍默认封出站 25。判断方法：在候选机房的测试机上用 nc 去连外部邮件服务器的 25 端口，超时就是被封；同时问清楚 PTR 能不能做、多久生效。避免方法是把它当成选机房的硬指标，写在采购条件里。真的被封又不能解，就老实走中继。
installer 只会按装机那一刻的内存算一次比例，之后扩内存它不会同步。判断方法：zmlocalconfig 看 mailboxd_java_heap_size，再看 my.cnf 里的 innodb_buffer_pool_size，对比现在的物理内存。避免方法是把这两个值纳入变更清单，每次扩完内存重新评估，并且盯 swap 和 GC 日志确认没有过度分配。
最常见的恢复需求是误删单封邮件和误删单个账号，但最常被演练的是整机恢复。判断方法：直接问你们的备份方案"能不能把某个账号三天前删掉的一封邮件找回来"，答不上来就是不支持。避免方法是在选型阶段就把这个需求写死，并且每季度演练一次并计时。
/opt/zimbra 和系统分区混在一起，日志轮转没配好或者备份落在同一个卷上，磁盘写满之后服务表现是各种诡异的失败而不是干净的报错。判断方法：把 df 的告警阈值设到 80%，并且分开看数据和日志两个挂载点。避免方法是 /opt/zimbra 独立分区、备份放到独立的存储、日志配好轮转和保留期。
| 规模档位（示例场景） | 组件拆分方式 | 内存配比思路 | 存储类型与冗余 | 主要瓶颈 |
|---|---|---|---|---|
| 30 人以内 · 单域名 | 全角色一台，代理/MTA/store/LDAP 同居 | 16G 起：堆 3–4G，缓冲池 4G 左右，留足给 clamd | 单块 NVMe 或 SSD RAID1，备份外挂 | 内存余量与 25 端口可用性 |
| 100–300 人 · 活跃度中等 | 仍是一台，但反垃圾参数单独调，max_servers 按内存给 | 32G：堆 6–8G，缓冲池 8–10G，盯 swap | NVMe RAID1，/opt/zimbra 独立分区 | 收信高峰的反垃圾 CPU 峰值 |
| 500–1000 人 · 有合规要求 | MTA 独立成节点，store 保留单台并做只读目录副本 | 32–64G：堆 8G 上下，缓冲池按库体积 1.2 倍估 | NVMe RAID10 + 独立备份卷 + 异地副本 | 索引随机 IO 与备份窗口 |
| 1000–5000 人 · 多域名 | 双 MTA + 双代理（VIP）+ 多 store，目录一主多备 | 每台 store 64G：堆 8–12G，其余给缓冲池与页缓存 | NVMe RAID10 主存储 + HSM 二级卷冷热分层 | 目录复制延迟与账号迁移窗口 |
| 万人以上 · 多站点 | 按站点横向扩 store，账号靠 zmmboxmove 在线搬迁 | 按 store 横向扩，单机 64G 以上，堆不再线性加 | 集中存储或对象存储分层，备份独立集群 | 单 store 无邮箱级主备切换，靠备份与恢复速度兜底 |
这张表怎么读：先看第二列，它决定的是你要维护几台机器，不是第一列的人数——人数只是触发条件。我的判读顺序通常是这样的：先确认第三列的"内存配比思路"能不能落到你选的具体机型上（有些机型的内存是焊死的，后期加不了，那就一步到位）；再看第四列，存储这里最容易被砍预算，但砍存储的后果是最难补救的，因为换盘意味着数据迁移；最后看第五列的瓶颈，把它变成监控项——瓶颈项没进监控，等于没做规划。第一列的人数只是参考，同样的 500 人，做外贸每天几百封外发邮件的，和内部系统账号为主的，资源画像完全不同。表里所有数字都是示例场景的估算起点，真实配置请以压测结果为准。
邮件服务器的网络要求和 Web 服务器不一样，这一点常被忽略。它不要求大带宽——几百人的单位一天的邮件流量可能也就几十 GB 量级——但对出口 IP 的"干净程度"和可管理性要求很高：IP 不能是被人用滥过的脏段（开通当天就该查黑名单），反向解析要能做，25 端口政策要明确，IP 最好是固定的、独享的。
地域选择上，看你的邮件往来对象在哪。往来对象集中在国内，服务器放境内节点延迟更低、解析更稳，但域名要备案、25 端口政策更需要提前确认；往来对象以海外为主，中国香港、新加坡、日本这类节点在连通性上是常见的折中选择，中国台湾、中国澳门节点也有各自的适用场景，具体要看你的收发分布。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付，这类多地域节点资源的价值在邮件场景里主要体现在"能挑到一个干净且政策明确的 IP"上；具体机型、带宽与报价以官网实时信息或咨询确认为准。
还有一条实际经验：如果是发信量较大的场景，最好一开始就问清楚能不能做 rDNS、能不能申请解封 25、IP 是独享还是共享、同段有没有被投诉的历史。这四个问题不同机房的答案差别极大，而它们对投递成功率的影响，比你在服务器上做的任何优化都大。在一万网络的交付流程里，这类与邮件相关的前置确认通常建议在下单阶段就提出来，避免装机后返工。
说了这么多怎么配，也得说说什么时候别自建。这不是唱反调，是省钱。
第一类是没有专职运维的单位。自建邮箱不是装完就完事，它是一项长期服务：系统补丁、Zimbra 版本升级、证书续期、反垃圾调参、黑名单监测、备份演练、误判处理。这些事加起来，一个几百人的单位每周至少要投入几个小时。没有专人负责，结果就是版本停在三年前、证书过期、备份从没验证过。
第二类是人数很少、需求很简单的单位。二三十个邮箱，用托管邮箱的人均成本大概率低于一台合格配置的服务器加运维时间——注意"合格配置"这四个字，前面说过开杀毒和索引就该 16G 起步，这类机器不是最便宜那档能扛的。
第三类是合规留存要求很严、但没有归档方案的单位。金融、医疗、政务这类场景常有长期留存和 eDiscovery 需求，这些能力在 Zimbra 里属于商业版的范畴，要单独规划和付费。如果你们没有预算也没有人力做归档，自建反而会变成合规风险点。
第四类是业务高度依赖外发投递、但拿不到干净 IP 或 25 端口的单位。比如做外贸开发信这类场景（这里说的是正常的商务往来邮件，不是群发推广），投递成功率就是业务生命线，而这恰恰是自建最不擅长的部分——它取决于 IP 信誉、域名历史和发送行为的长期经营。这类单位更适合把发信交给专业的投递服务，自建只做收信和归档，或者直接选托管方案。
1. 一台机器到底能撑多少个邮箱账号？
人数不是好指标，活跃度和邮件量才是。公开的官方 FAQ 口径是 Zimbra 支持从 25 个邮箱到百万级以上的部署，社区里也有单实例跑一万账号、正文存储 8T 左右的真实案例（8 vCPU、64G 内存、SAN 存储）。但这不意味着你的 500 人能用同样配置——那套一万账号的环境里绝大多数账号配额被限制在 1G 左右。我判断的标准是并发会话数和日均收发量：几百个活跃会话、日均几千封收发，一台配好的机器够用；并发上千、日均几万封，就该考虑拆 MTA 和横向加存储节点了。具体数字请按自己的实际负载压测。
2. 内存是不是越大越好，8G 能不能跑？
8G 是公开安装资料里的最小起步值，能装起来、小规模能用，但只要开了 ClamAV 和全文索引就很勉强——光 clamd 的签名库加上 amavisd 的几个子进程就能占掉相当一部分，剩下给 Java 堆和 MariaDB 缓冲池的空间会挤到触发 swap，而 Zimbra 一 swap 就是断崖式变慢。我的建议是生产环境 16G 起步，开杀毒加索引就直接上 32G。内存也不是越大越好，堆超过 6G 之后收益递减，多出来的内存给缓冲池和页缓存更划算，关键是配比而不是总量。
3. 开源版能直接上生产吗？
能，但有前提。10.x 之后官方不再发布免费的开源版二进制，实际使用的是社区自行构建的包（如 maldua/zimbra-foss），属于非官方产物，要按第三方软件的标准评估：谁在维护、多久出一次、有没有人真的在生产环境跑。功能上开源版缺的是实时备份恢复、HSM 分层存储、归档与 eDiscovery、ActiveSync 移动推送这些，基础邮件能力都在。所以前提是你们有 Linux 运维能力、能自己搭备份方案并做到单邮件恢复、手机上用 IMAP 就能接受。三条里缺一条，总体成本未必更低。
4. 25 端口被封了还能不能自建？
能，但要分清收和发。收信依赖入站 25，这个端口通常是对外开放的，被封的多是出站 25。出站被封的情况下有两条路：一是向机房或运营商申请解封，需要企业资质、用途说明和反垃圾承诺，能不能通过、多久生效、是否稳定，完全取决于机房与运营商政策；二是走中继（Smarthost），自建的 Postfix 把邮件交给 587/465 端口的专业投递服务代投，自己只保留收信和存储能力。第二条更常见也更稳，代价是投递信誉部分依赖中继商。测试很简单：用 nc 连外部邮件服务器的 25 端口，超时就是被封，下单前就该测。
5. 反垃圾是不是调得越狠越好？
不是。阈值调高、规则加多，漏进来的垃圾确实变少，但误判会同步上升，而每一次误判都是一次人工介入——用户报没收到客户的邮件，你去翻日志、捞隔离区、加白名单。这个人力成本不会体现在任何账单上，但会实实在在吃掉运维时间。我的做法是先定一个中等阈值跑两周，统计误判和漏判的比例，再决定往哪边调；同时把贝叶斯学习流程建起来，让用户标记垃圾的动作回写到学习里。另外记得给 sa-update、sa-compile、freshclam 三个定时任务加监控，它们悄悄失败是很常见的事。
6. 备份该多频繁，能不能恢复到单封邮件？
频率取决于你能接受丢多少数据——按这个反推，而不是按"每天一次挺合理"。更关键的是粒度：最常发生的恢复需求是"某个用户三天前误删了一封邮件"和"某个账号被误删"，这两种场景如果只能整库回滚，方案就是不达标的。网络版在 10.x 里集成了备份恢复和 Message Reclaim，支持按全局、服务器、COS、域名、账号多级恢复，也支持先恢复元数据和账号、再恢复 blob 的高级模式；开源版要自己解决。另外备份必须考虑一致性——对运行中的系统做文件级拷贝可能拿到数据库和 blob 对不上的副本，稳妥做法是停机快照或一致性快照。
7. 机械硬盘能不能跑 Zimbra？
技术上能，体验上不建议。邮件系统的 IO 是海量随机小读写：一封邮件就是一两个小文件，索引是大量几十 KB 到几 MB 的段，元数据是成千上万条小记录。机械盘的随机 IOPS 只有几十到一两百量级（具体看型号和队列深度，公开资料口径不一，建议自己用 fio 实测），几百个活跃用户同时用 Web 端就顶不住了，表现是搜索转圈、文件夹切换慢，而 CPU 和内存都很闲。结论是正文和索引放 SSD/NVMe，机械盘最多用来放备份副本。冗余上超过 100 账号就不建议 RAID5，写惩罚加重建窗口风险太高。
8. 什么时候必须拆成多台？
三个触发条件：一是单机资源扛不住，收信高峰反垃圾把 CPU 吃满、队列开始积压；二是合规或审计要求把对外暴露层和存储层物理分开；三是维护窗口扛不住，邮箱服务器停机半小时业务就受不了。反过来，人数在三五百以内、有正常备份和值班的，我建议先单机，把预算投到内存、NVMe 和备份上。拆分会把维护成本成倍放大——证书、监控、跨节点备份一致性、升级顺序（先 LDAP/代理/MTA 再 store）都变成硬约束，人手没变的情况下拆完维护质量往往下降。还有一点要提前接受：存储节点没有邮箱级的主备切换，高可用得靠备份和快速恢复兜底。
1. Zimbra 官方 Wiki《Zimbra Server Roles Overview》——各角色（MTA、Proxy、Mailstore、LDAP Master/Replica）的组件构成与职责划分，含 Postfix、Amavis、ClamAV、SpamAssassin、MariaDB、Lucene 的组合关系。
2. Zimbra 官方 Wiki《Performance Tuning Guidelines for Large Deployments》——Java 堆默认按系统内存 30% 分配、innodb_buffer_pool_size 约 25%、堆超过 4–6G 后收益递减、线程栈与 swap 的风险说明。
3. Zimbra 官方 Wiki《Zimbra Releases/10.0.0》与官方下载页——Daffodil v10 的组件整合、备份与恢复机制（auto-grouping、Standard、Message Reclaim、分级恢复）、10.1 支持的操作系统列表。
4. Zimbra 官方 FAQ（Zimbra :: Tech Center）——对单实例支持规模与邮箱配额的官方口径（支持 25 到百万级邮箱、平台本身不设物理存储上限、RAID5 在超过 100 账号时不推荐）。
5. Mission Critical Email《Zimbra Mailboxd Java Tuning For Large Environments》（2026 年 2 月）——不同物理内存下的 mailboxd_java_heap_size 建议区间、G1 GC 相关参数与 To-space exhausted 的判读方法。
6. Andrew Mercer《Zimbra: Architecture and Administration》文档（2026）——10.1.x 系列的版本与授权现状、开源版二进制停止发布后社区构建（maldua/zimbra-foss）的情况、端口与目录结构说明。
7. LinuxPro《Installing Zimbra 10.1 FOSS on Ubuntu》（2026 年 9 月）——社区 FOSS 构建的安装前置条件、最小硬件口径（4 vCPU、8G 内存、50G 可用空间，开杀毒与索引建议 16G）、DNS 与端口冲突注意事项。
8. Danami 知识库《How can I speed up how fast Amavis processes email》——amavisd max_servers 按系统内存的默认取值表（8G/12G/16G/24G/32G 对应 3/4/5/6/8）与单子进程内存占用口径。
9. CloudSpinx《Zimbra Mail Server Setup and Support》服务文档——多节点参考架构（MTA 双节点、代理 VIP、目录主从、多 mailbox store）、各层故障行为与迁移方式。
10. Sender.net《SMTP Ports Explained》（2026）、SMTPedia《SMTP Setup Guide》（2026）——主流云平台对出站 25 端口的默认策略差异、25/465/587 的用途区分，用于说明端口政策需以机房与运营商实际政策为准。
11. Zimbra 官方论坛公开讨论帖（单实例万人级部署的资源占用数据：store 约 8T、index 约 400G、db 约 110G，8 vCPU/64G 内存）——用于说明各数据目录的比例关系，属社区经验值，具体数值请以自身实测为准。
12. 一万网络官网（idc10000.net）服务器租用与机房节点公开信息——节点分布、机型与带宽口径；具体价格与可用性以官网实时信息或咨询确认为准。
上一篇：2026 服务器租用做 Bacula 备份架构怎么设计：Director/存储守护/恢复演练 对比 + 避坑手册
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
