我们的一个 AWS 卷的快照已损坏。我们使用这些快照作为备份，过去它们帮了大忙。（注意：这不是我们唯一的备份方法！）但是损坏的快照毫无用处。
我想知道如何处理这个问题，如何预先检测这个问题等等。
情况
我们有一个 AWS Web 服务器，它有一个大型 ext3 卷 (DATA)，其中许多图像都放在一个文件夹中。我们每天都会对所有卷进行快照，由于我们会保留这些快照四周，因此这个快照的成本太高了。我只需要一张图像快照以备不时之需，对于其余卷，我希望保持正常数量。这就是我想要做的：
- 从卷 DATA 创建快照
- 从快照创建新的 ext4 卷映像
- 挂载卷 IMAGES，删除除 Images 文件夹之外的所有文件和文件夹
- 将原始文件夹移动到卷 DATA 的根目录
- 从 DATA 上的原始位置到 IMAGES 上的新图像文件夹的符号链接
- 将所有其他数据 Rsync 到新的较小的 ext4 卷：网站
- 将 DATA 卷替换为 WEBSITE 卷，并链接到 IMAGES 卷
步骤 3 不起作用。我收到以下错误：
sudo mount /dev/xvdf /images
mount：在 /images 上挂载 /dev/xvdf 失败：结构需要清理
在 Google 上搜索这个错误时，我发现建议执行 xfs_check，但文件系统是 ext3，所以我尝试了 e2fsck。这导致了无数的错误和似乎不起作用的修复。
sudo xfs_check /dev/xvdf
sudo e2fsck -f /dev/xvdf
我创建了一个新的卷 IMAGES，并使用 rsync 复制了所有内容，因为 cp 导致崩溃。我立即创建了新卷的快照，并恢复了它以查看是否正常工作，结果确实如此。
然后我继续拆分卷，并用两个新卷替换旧卷。这一切都成功了，问题也解决了。
亚马逊支持
我仍然想知道这里发生了什么，以及如何防止将来发生这种情况，所以我联系了亚马逊支持。他们告诉我快照已损坏，可能是因为快照是在卷正在使用时拍摄的。我们一直这样做，已经对这些快照（但不是这个卷）进行了多次恢复，从来没有出现问题。这个卷已连接，但在拍摄快照时没有写入任何内容。
我决定听从建议，分离卷，制作快照，然后看看会发生什么。分离后，原始数据卷无法再连接。由于我已经更换了此卷，所以没有后果，所以这不是一个大问题，但显然这并不像宣传的那样有效。
快照可以附加和安装，我可以打开打开的文件夹等。当我执行 e2fsck 时，我再次收到错误。回想起来，我忘了在原始 DATA 卷上执行此 e2fsck，真可惜。我想那也会报告错误。
这次亚马逊的支持低于平均水平，这很遗憾。
问题
- 我如何才能检测出这些问题而不需要时不时地手动测试每个卷/快照？
- 我可以暂时将卷设置为只写吗？我该怎么做？
- 我读过有关
badblocks此类问题（结构需要清理）的命令。当我将快照还原到新的（虚拟）卷时，检查该卷似乎毫无用处，因为它位于不同的物理位置。在这种情况下，坏块有用吗？ - Fsck 似乎会更改磁盘内容。有什么安全的方法可以测试此类有问题的磁盘？
答案1
快照没有损坏。快照包含的文件系统已损坏。这是有区别的。
如果在文件系统写入数据的过程中拍摄快照，则快照中的文件系统可能会损坏。如果在启动快照时只写入了一组全有或全无的块中的部分块，则可能会发生这种情况。
以前，如果您的旧快照是在卷正在使用时拍摄的，并且恢复正常，那只是运气不好：在启动快照时文件系统没有被写入。您的好运现在已经用完了，您已经遇到了这种情况可能带来的后果。
1. 预防问题
处理此问题最简单的方法就是从一开始就防止其发生。为避免此类问题，AWS 建议：
- 暂停文件系统（例如
fsfreeze）， - 卸载文件系统（例如
umount），或 - 停止 EC2 实例（例如
aws ec2 stop-instances）。
看：http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
2. 解决问题
由于您发现文件系统已损坏，因此最好的做法是在执行任何其他操作之前修复文件系统。
xfs_check使用 Linux 工具，例如e2fsck修复文件系统上任何损坏的块。- 创建一个新的 EBS 卷并尝试将文件复制到其中。
一旦你的文件系统被修复，就采取措施来防止问题的发生（参见第 1 节）。
补充笔记
- 活动 EBS 卷的文件系统不会因拍摄快照而损坏。只有当您从写入过程中启动的快照恢复卷时，您才会得到损坏的文件系统。
- 当您在步骤 1 中创建快照时，文件系统可能已损坏。或者，如果您的卷是从旧快照恢复的，则它可能已经损坏。