我有一个由第三方提供的 Xen domU，运行 Ubuntu（10.04，服务器版本，原版服务器内核）。该服务器运行 Dovecot 和 Exim4，邮件存储在 Maildirs 中，并运行一个相当典型的 LAMP 堆栈，其中大多数应用程序都使用 Perl，所有数据存储在充满 TIFF 文件的目录树或 MySQL DB 中。该服务器已运行约 3 个月，用于 LAMP 内容，并运行一个月用于邮件服务。所有文件系统（交换除外）都是 Ext3。
几周前，我们突然发现一大堆 TIFF 文件无法再访问，正如我们的备份脚本（使用 rsync）所指出的那样。rsync远程主机上报告了以下错误：
rsync: readlink_stat("/srv/data/documents/archive/pdf/2007/Aug/06/085717/00000002.TIF") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2007/Aug/06/085717/00000001.TIF") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2011/Jan/04/125227/XSMDESC.DAT") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2011/Jan/04/125227/DOC010.XST") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2011/Jan/04/125227/00000001.TIF") failed: Input/output error (5)
...等等。这些文件可能是在 12 月下旬或路径中指定的日期（以较晚者为准）创建的，因为我们去年年底将数据迁移到了这台机器上。据我所知，此后没有任何进程写入这些文件——只能读取它们。
那天整天，我们注意到受影响文件的数量在不断增加，所以那天晚上我们卸载了那个文件系统（Xen 虚拟块设备）并运行了fsck，它发现并修复了许多错误。受影响的文件现在消失了。但是，一旦 fsck 完成并且文件系统重新安装，损坏就停止蔓延了。
（顺便说一句，为了说明我们在这里有多幸运——保存着我们唯一备份数据的唯一磁盘在当天下午灾难性地坏了。是的，真的。我们唯一的其他备份是从 2010 年 12 月 10 日开始的......）
受影响的绝大多数文件都是在今年 1 月 4 日或 5 日创建的，这可能与此有关，也可能与此无关 - 但其中一些是 2006/7 年的文档，还有一些较新。
随着 fsck 完成并且机器现在显然很稳定，我们很担心——托管服务提供商找不到根本原因，我们也找不到——并且我们丢失了数据，但至少损坏已经停止了。
跳过几天，例程mysqldump拒绝转储 3 个表，因为它们被标记为崩溃。mysqlcheck确认了这一点，并REPAIR TABLE [foo]修复了所有 3 个表，在 2 个案例中报告事件后发现的行数比事件前少。供应商再次看不到根本原因，没有电源中断、磁盘访问或mysqld。问题似乎无关紧要，但——在这台服务器上托管 3 个月，我们已经丢失的数据比在各种不同（但绝不是虚拟的！）平台上运行这些应用程序的几年还要多。
最后，本周我们在 FS 上发现了 3 个文件，它们似乎已经变成了二进制垃圾——更具体地说，全是 1（或者\0xFF如果您愿意，可以全部是 1）。所有 3 个文件（2 个小文本配置文件，1 个 100 行左右的 perl 脚本）都是我们 Web 应用程序的一部分，并且会经常被读取，但只有在我们部署新版本时才会写入，其工作原理是更新本地“工作”副本，导出该工作副本以获得全新安装，并将符号链接指向该全新安装。文件在工作副本中被破坏并从那里传播，所有文件的修改时间都与它们在多个星期内没有更改一致（在此期间进行了几次部署，所有部署都进展顺利！），因此内容显然发生了变化，而修改时间没有更新。
这些事件中的任何一个都会让我从备份中恢复，挠头并继续我的生活，但是两周内发生的三起事件让我等待下一件事情发生。
我的问题很简单：这 3 起事件是否有可能存在关联？如果存在关联，我应该在哪里寻找根本原因？
（也欢迎有关解决方案的答案，但是我们已经在与同一供应商在 VMware 上设置运行 CentOS 的并行平台，以尝试排除分发、内核、虚拟机管理程序和虚拟块设备相关的问题。如果知道其中哪一个是问题所在，那就太好了，但如果我们没有诊断，并且替换整个堆栈有效，那将帮助我晚上睡个好觉……最终。）
与往常一样，如果任何额外的信息有帮助，请发表评论，我会进行相应更新！
答案1
看起来供应商的备份软件破坏了文件系统。
我们遇到过类似的情况，DomU 在使用我们标准备份客户端的未修补版本备份后开始出现故障。
尝试修复 fs 两次后，它仍然行为异常（无法读取文件...）
解决方案是完全重新设置文件系统（mkfs），安装标准备份客户端的最新修补版本，然后恢复最后的良好数据。
我们很幸运：数据分区 (/opt) 仍然完好无损，没有丢失任何内容。损坏的分区仅包含 / 和 /var。