我有一个由第三方提供的运行Ubuntu（10.04，服务器版，库存服务器内核）的Xen domU。 该服务器运行Dovecot和Exim4，邮件存储在Maildirs中，并运行一个相当典型的LAMP堆栈，其中大部分应用程序都在Perl中，所有的数据都存储在TIFF文件目录树或MySQL数据库中。 这个服务器已经运行了大约3个月的LAMP的东西，一个月的邮件服务。 所有的文件系统（swap除外）都是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月底或path中的date创build，以后者为准，因为我们去年年底把数据迁移到了这台机器上。 根据我的知识，没有任何过程会写入文件，因为只能从这些文件读取。
在那一整天，我们注意到受影响文件的列表不断增加，所以当天晚上我们卸载了这个文件系统（一个Xen虚拟块设备）并运行了一个fsck ，发现并修复了许多错误。 受影响的文件现在不见了。 但是，一旦fsck完成并重新安装文件系统，腐败就会停止。
（另外，为了说明我们在这里所遇到的那种幸运 – 在同一天下午我们唯一备份这个数据的单个磁盘就是灾难性地死去了，是的，真的，我们唯一的备份是从2010年12月10号开始的。 ）
绝大多数受影响的文件是在今年1月4日或5日创build的，但有些文件是从2006年7月7日开始的，其中一些更新。
随着fsck的完成和机器现在看起来很稳定，我们担心 – 托pipe服务提供商不能find根本原因，也不能 – 我们也丢失了数据，但至less腐败已经停止了。
向前跳过几天，并且例程mysqldump拒绝转储3个表，因为它们被标记为崩溃。 mysqlcheck证实了这一点， REPAIR TABLE [foo]修复了所有3个事件，在2个事件中报告事件之后发现的行数比之前less。 供应商再次看不到根本原因，电源，磁盘访问或mysqld没有中断。 这个问题似乎没有关系，但是在这个服务器托pipe的3个月内，我们已经失去了更多的数据，而不是在多种不同的（但从来不是虚拟的）平台上运行这些应用程序的几年。
最后，本周我们在FS上发现了三个似乎已经转向二进制gunk的文件 – 更具体地说，全是1（或者如果你愿意的话全部是\0xFF ）。 所有3个文件（2个小文本configuration文件，100个ish行perl脚本）都是我们web应用程序的一部分，并且会经常被读取，但是只有当我们部署了一个新版本时才会被读取，这个版本通过更新本地“工作”复制，导出该工作副本以获得全新的安装，并在全新安装中指向符号链接。 这些文件在工作副本中被破坏，并从那里传播，所有文件的修改时间与他们一直没有改变的时间一致（在这段时间里有好几次部署，所有这些都很顺利！）内容明显改变，而不更新mtime。
这些事件中的任何一件都会让我从备份中恢复过来，抓我的脑袋，继续我的生活，但是在两周的时间里，有三件事让我等待下一件事发生。
我的问题很简单：这三个事件甚至有可能连接起来，如果是的话，我应该在哪里寻找根源呢？
（关于解决scheme的答案也是受欢迎的，但是我们已经在使用同一个厂商在VMware上build立一个运行CentOS的并行平台来排除分发，内核，pipe理程序和虚拟块设备相关的问题。很高兴知道其中哪些是问题，但是如果我们没有诊断，并且取代整个堆栈工作，最终会帮助我在晚上睡觉…）。
像往常一样，如果有任何额外的信息将有所帮助，请评论，我会相应更新！
看起来像供应商的备份软件损坏了文件系统。
我们也遇到类似的情况，DomU在我们的标准备份客户端的一个未打补丁版本的支持下开始行事不端。
在试图修复fs两次后，它一直在行为不端（文件无法读取…）
解决scheme是完全重新设置文件系统（mkfs），安装最新的补丁版本的标准备份客户端，然后恢复最后的好数据。
我们在这里很幸运：数据分区（/ opt）仍然完好无损，从未丢失任何东西。 损坏的分区只包含/和/ var。