我有一台使用 maildir 格式运行 dovecot 的服务器，该服务器具有相当大的用户群（10k 用户左右），每个用户都有大约 GB 的配额。
实际的邮件目录存储在我们的电子邮件服务器通过 NFS 挂载的单独存储系统上。
由于我们的存储系统出现性能问题，我们正在升级到新的存储系统。我们一直将数据从旧系统直接同步到新系统，但这个过程仍然需要相当长的时间（16+小时）。
我们的计划是连续运行 rsync，在第二个完成后，立即删除邮件服务器上的 dovecot/qmail/etc，将安装位置切换到新系统，然后恢复电子邮件。如果运气好的话，停机时间总共只有一两分钟。问题是最后一次 rsync 运行时传入的任何电子邮件仍然不会被复制。因此，为了缓解这种情况，在切换后我们将再次进行 rsync，而不使用我们通常使用的 --delete 标志。这存在一些问题，但从我的角度来看，最大的问题是用户无法访问他们在切换之前刚刚拥有的电子邮件。
有没有人建议如何在停机时间极短且不会丢失任何时间的情况下做到这一点？旧的存储系统是NetApp，新系统只是一个freebsd盒子，附加了一个大的san，电子邮件服务器是Ubuntu。
在我看来，应该有一种方法可以从用户的角度重叠存储系统，直到迁移完成，但我根本不知道如何做到这一点（如果可能的话）。
答案1
这两个文件系统都是“联合”文件系统。你会做一些诸如
- 将旧 NAS 安装在
/mnt/old - 将新 NAS 安装在
/mnt/new - 将联合文件系统挂载
/mnt/nas在/mnt/new之上/mnt/old。 - 任何对 的访问都
/mnt/nas/foo/bar将首先查找/mnt/new/foo/bar，如果不存在，则将回退到/mnt/old/foo/bar。如果修改文件，它将复制原始文件/mnt/old，/mnt/new然后修改/mnt/new版本。 - 挂载联合文件系统后，您可以运行
rsyncfrom/mnt/oldto/mnt/new。这可以在系统运行时完成。当 rsync 将文件放在那里时，访问/mnt/nas将开始拾取文件。/mnt/new
答案2
怎么样继续这样：
- 第一次同步
421 Service not available, closing transmission channel在横幅中制作qmail回复- 第二次同步
- 恢复qmail的原始配置（或切换到另一台服务器，我不确定我是否得到了那部分）
这样，您就可以相信客户稍后会重试发送电子邮件。
答案3
我认为您在更改存储后端时无法避免大量停机时间，但有一些选择。然而，最好的选择将根据您的需求和环境量身定制。
如果您不打算随机删除邮件，则必须通过响应 421、450 或 452 停止写入存储系统。我个人会选择 450“用户邮箱不可用”。
因此，我会进行 Rsync，然后返回 450，然后进行 rsync，最后存储更改。
请记住，电子邮件不应该是可靠的。我们只是应该这样看待它。无法接受消息意味着向您发送消息的服务器应该重试。通常，这将是 24 小时内每 4 小时一次，但这只是“正常”而不是规则。
顺便说一句，如果您没有使用 NFS（或者可以像这样访问 NFS 服务器），您可以尝试将存储放入某种集群中，然后只需将新存储添加到集群中并删除旧存储。这可以通过某种 RAID（如果在同一台机器上）或 DRBD 之类的东西来完成。想法是，您只需遵循向集群添加新服务器的正常服务器升级路径，给它时间“赶上”，然后删除旧服务器。