我一直在考虑数据完整性，目前我备份了大约2TB的数据，并且总是有一年前的数据备份。 我担心的是，如果一个文件在我们的生产文件服务器上变得腐败，没有人会注意到，因为一些文件不被访问多年，如果发生损坏，我会备份一个损坏的文件。 我不知道我应该如何处理这个问题，有没有办法来检测数据损坏？ 或者是唯一的解决scheme来存储较旧的备份，以防万一某些东西被损坏，不被注意到？
我有一个服务器报告与NTFS损坏相关的一些错误消息。 它报告d：\ $ mft内可能有腐败 不过，我还没有遇到任何腐败，或无法读取的文件等 我的问题是，如何检测$ mft腐败，它的潜在影响是什么？ 我的猜测是以下几点： $ MFT本质上是一个包含文件和权限等的关系数据库 如果我们将$ MFT腐败视为每个logging级别的腐败，那么$ MFT腐败只会影响具有相关的$ MFTlogging损坏的文件的阅读和编辑。 （显然简化以帮助理解） 当碰巧尝试打开/编辑$ MFT中的“指针”损坏的文件时，我只会碰到不可读的文件。 （ 因此回答我的问题如何检测MFT腐败 ）。 如果这个文件对我来说不重要，我可以高兴地忽略这个$ MFT腐败？ 例如，如果它不是一个关键的数据库文件等 我问这个问题的原因是，我看过CHKDSK经常可能无法修复这些错误，我想知道我是否可以安全地“忽略”这个错误，并且有时间采取其他措施，或者安全地忽略这些错误？ 至于所有的腐败，我需要排除一个潜在的磁盘问题，而不是“逻辑级”腐败。
我们正在客户现场遇到一个奇怪的错误。 我们已经设法缩小到只能使用Management Studio和SQL Server复制行为的程度。 我们有两台机器，A和B： + ———— + + ——————– + | [A] | | [B] | | pipe理| ————–> | SQL Server 2008 R2 | | 工作室| | 企业x64 | + ———— + + ——————– + 我们在计算机A的Management Studio上运行一个SQL脚本，对着计算机B上的SQL Server实例。 我们实际上并没有执行脚本，只是parsing它。 大多数情况下，parsing操作正常。 偶尔（看似随机），parsing操作失败，语法错误。 该错误消息显示了脚本中出现错误的部分，该部分显示为原始脚本中的一些SQL已被截断并附加了随机字符。 一个例子： 原始的SQL： SELECT DISTINCT ST.TABLE_NAME as TableName FROM INFORMATION_SCHEMA.TABLES AS ST […]
在Windows服务器上有几个文件出现在目录列表中，但无法访问。 我可以获取文件的所有权，并且ACL显示每个人都具有读取/写入/执行访问权限; 但我无法打开文件。 chkdsk在卷上找不到任何问题。 该服务器是64位Win 2008 R2 Standard SP1。 我们最近在这个服务器上有一个蓝屏死机，而且这些文件在崩溃前不久就被修改了。 崩溃不是与文件系统有关的任何事情，但我认为它损坏了内核内存中的东西，并损坏了文件系统。 下面是一些当我试图访问文件“com2.log”时看到的： D:\Logs\Application>dir com2* Volume in drive D is Data Volume Serial Number is 84D5-FD84 Directory of D:\Logs\Application 09/07/2011 06:57 PM 169,025 com2.log 1 File(s) 169,025 bytes 0 Dir(s) 39,320,612,864 bytes free D:\Logs\Application>dir com2.log Directory of \\. File Not Found D:\Logs\Application>dir com2.* Directory of \\. […]
有没有人遇到过这个问题？ 在远程桌面连接浏览资源pipe理器中的文件夹时，有时文件名string将被损坏，所以它们在Windows资源pipe理器中显示不正确。 远程桌面（或terminal服务）必须有某种forms的stringgraphicscaching，几乎随机地破坏特定的string，特别是在Windows资源pipe理器中的文件名。 我不能复制按需错误，但一旦发生，您可以复制文件名string并将其粘贴到资源pipe理器中的其他位置，例如地址栏，“运行”对话框等等。string也会在那里被破坏。 如果你手工inputstring，即使你input了string的第一部分，最后一部分，并添加了最后一个字符，最后的结果也一样，只要你添加了最后一个字符，它也会被破坏。一旦被破坏的string被重新build立，可视化显示是错误的（它变成空白或者具有错误的字符）。 这完全是一个视觉缺陷。 我仍然可以编辑string。 如果我删除一个字符，整个string显示正常（因为它是一个不同的string）。 如果我添加一个不同的字符，它也显示正常，但只要我添加原始字符，恢复原始（损坏）的string，string的显示是空的或乱码。 谁可以报告..这显然是一个讨厌的错误。 编辑：一个损坏的string似乎通过从文件属性对话框，如IDstring，像“权限”或“允许”，和文件path的单词stringreplace可视化显示自己： 也许这个bug与显示文件属性窗口有关。 编辑：添加下面的图像。 如果我调整分隔符的大小，string将会改变（它们以“…”结尾，所以它是一个不同的，没有损坏的string，显示效果很好。实际上，你甚至不能从远程捕获这个全屏图像桌面上，因为它回来没有显示毛刺！只有通过将远程桌面窗口恢复到窗口化状态，并打开远程桌面窗口打开客户端桌面的图片，才有可能看到这个腐败…所以也许它是一个客户端string呈现问题。 远程桌面损坏示例http://i29.tinypic.com/2dihh0l.png
有没有人需要处理存储网关卷上的损坏的文件系统？ 我的一本书现在告诉我，它已经损坏或不可读。 我试过运行一个chkdsk / r，它花了几天（10TB卷）。 一旦完成，我得到了同样的错误信息。 我没有快照计划，所以我没有这些文件的以前的版本。 我目前正在使用AWS支持，他们让我用几种不同的方式运行chkdsk。 有没有人曾经处理过呢？ PS：顺便说一句，不要在存储网关卷上运行chkdsk，它会把你的caching搞砸，运行速度很慢
看起来像我的USB硬盘是老的和损坏的： rsync: read errors mapping "path/to/file.jpg": Input/output error (5) 系统日志： kernel: [58927.940676] sd 6:0:0:0: [sdb] Unhandled sense code kernel: [58927.940683] sd 6:0:0:0: [sdb] Result: hostbyte=invalid driverbyte=DRIVER_SENSE kernel: [58927.940690] sd 6:0:0:0: [sdb] Sense Key : Medium Error [current] kernel: [58927.940696] sd 6:0:0:0: [sdb] Add. Sense: Unrecovered read error kernel: [58927.940703] sd 6:0:0:0: [sdb] CDB: Read(10): 28 […]
昨天我们有一个实例，其中超过5,000个用户对象中的大约130个突然被损坏。 除了sAMAccountName和cn之外，您可以设置的每个属性都被擦除干净，包括密码，尽pipe策略禁止less于8个字符。 修改过的时间戳是彼此相隔的秒数。 他们的帐户也被禁用。 我怀疑是因为密码的空白。 当我们去重新启用帐户，我们会得到一个错误，说密码不符合要求。 所以，我们必须重置所有的密码。 这些帐户也与Exchange邮箱断开连接，我们必须重新连接它们。 即使他们所有的小组成员都被删除了。 奇怪的是，我们注意到，它们都是按字母顺序排列的cn ，在OU容器中的第一个到第三个用户之间。 除此之外，没有任何模式被发现。 起初，我认为这可能是有人写剧本并搞砸了。 但是，密码设置为空白的事实导致我相信，不能通过脚本来完成。 不幸的是，由于我不会进入的原因，我们没有审计打开。 有没有人见过这个？ 你知道可能造成了什么吗？
我正在备份存储在由2个硬盘的单个raidz vdev组成的zpool中的数据。 在这个操作中，我得到校验和错误，现在状态如下所示： pool: tmp_zpool state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://zfsonlinux.org/msg/ZFS-8000-8A scan: none requested config: NAME STATE READ WRITE CKSUM tmp_zpool ONLINE 0 0 2 […]
我们的其中一台服务器最近经历了一些文件系统损坏，我们的根文件系统被自动重新安装为只读。 我采取的步骤是： 试图remount > mount -n -o remount /失败 重新启动服务器 被提示执行手动fsck ，有5个孤立的inode需要修复。 执行完这些步骤之后，我能够获得访问权限，并且文件系统可以再次写入。 不幸的是，我没有任何信息logging，因为没有任何logging，或者我会包括这些logging。 原因之一是我们的数据库太忙，无法正确地将数据写入磁盘，这就造成了这个问题，高水平的高速caching被用来表明这可能是这种情况。 不过，我不确定这是因为虽然caching很高，我们根本不使用交换（下面的free输出）。 $ free -m total used free shared buffers cached Mem: 2041 1879 162 0 62 1599 -/+ buffers/cache: 216 1825 Swap: 471 0 471 发生故障后有什么办法可以诊断？ MySQL看起来像一个可能的候选人吗？ 如果没有的话，如果再发生这种情况，我还有什么要做的？