有没有人需要处理存储网关卷上的损坏的文件系统？ 我的一本书现在告诉我，它已经损坏或不可读。 我试过运行一个chkdsk / r，它花了几天（10TB卷）。 一旦完成，我得到了同样的错误信息。 我没有快照计划，所以我没有这些文件的以前的版本。 我目前正在使用AWS支持，他们让我用几种不同的方式运行chkdsk。 有没有人曾经处理过呢？
PS：顺便说一句，不要在存储网关卷上运行chkdsk，它会把你的caching搞砸，运行速度很慢
我们解决了这个问题，把文件拿回来了。 在AWS支持的build议下，我创build了存储网关卷的EBS快照，将其恢复为EBS卷，将其附加到相当健壮的EC2实例，并从那里运行chkdsk。 因为这是一个直接连接到计算机的EBS卷，而不是通过存储网关或WAN来执行chkdsk，所以它的运行速度比其他方式要快得多（仍然需要花费数天的时间在10TB卷上运行6TB数据上的chkdsk） 。 当chkdsk完成，我们确认我们可以访问EC2实例的文件时，我们对卷进行了快照，并将其恢复到我们的本地存储网关。
这个故事的寓意 – 如果您使用的是存储网关，那么知道云中的文件系统可能会被损坏，并且在卷发生时计划快照。