将零复制到我的外部驱动器,报告错误,日常 rsync 仍然安全吗?哪些文件系统更安全?

将零复制到我的外部驱动器,报告错误,日常 rsync 仍然安全吗?哪些文件系统更安全?

我有一个损坏的文件,我怀疑是由老化的外部机械便携式 HDD 之间的 rsync 引起的。

我做了备份,决定写零,看看是否有写入错误。果然,我得到了一些,但不是很多。见下文。

我想知道这是否可以安全地用于我的 Linux 计算机和我的 Linux 笔记本电脑之间的日常 rsync。哪些文件系统对此是安全的?与 ext4 相比,NTFS 本质上不安全吗?

$ sudo dd if=/dev/zero of=/dev/sdc1 bs=1024
dd: error writing '/dev/sdc1': Input/output error
960119073+0 records in
960119072+0 records out
983161929728 bytes (983 GB, 916 GiB) copied, 51641 s, 19,0 MB/s

$ sudo smartctl -a /dev/sdc1  
smartctl 6.5
2016-01-24 r4214 [x86_64-linux-4.4.0-109-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke,
www.smartmontools.org

=== START OF INFORMATION SECTION === Vendor:               WD Product:              My Passport 0748 Revision:             1019 Compliance:          
SPC-4 User Capacity:        1 000 170 586 112 bytes [1,00 TB] Logical
block size:   512 bytes Rotation Rate:        5400 rpm Serial number: 
WX81A7242861 Device type:          disk Local Time is:        Thu Jan
18 11:30:41 2018 CET SMART support is:     Unavailable - device lacks
SMART capability.

=== START OF READ SMART DATA SECTION ===

Error Counter logging not supported

No self-tests have been logged


$ dmesg | grep sdc1 
[ 8279.937899]  sdc: sdc1 [21382.527511] Buffer
I/O error on dev sdc1, logical block 240030162, lost async page write
[21382.527516] Buffer I/O error on dev sdc1, logical block 240030163,
lost async page write [21382.527518] Buffer I/O error on dev sdc1,
logical block 240030164, lost async page write [21382.527524] Buffer
I/O error on dev sdc1, logical block 240030165, lost async page write
[21382.527526] Buffer I/O error on dev sdc1, logical block 240030166,
lost async page write [21382.527528] Buffer I/O error on dev sdc1,
logical block 240030167, lost async page write [21382.527530] Buffer
I/O error on dev sdc1, logical block 240030168, lost async page write
[21382.527532] Buffer I/O error on dev sdc1, logical block 240030169,
lost async page write [21382.527534] Buffer I/O error on dev sdc1,
logical block 240030170, lost async page write [21382.527535] Buffer
I/O error on dev sdc1, logical block 240030171, lost async page write
[21387.552539] VFS: Dirty inode writeback failed for block device sdc1
(err=-5). [21398.777810]  sdc: sdc1 [21550.843225] EXT4-fs (sdc1):
mounted filesystem with ordered data mode. Opts: (null)

答案1

您已经有一个损坏的文件,并且磁盘存在已知问题。问题要么保持不变,要么变得更糟:“治愈”的可能性极小。所以,不,这不安全。

然而,已知不可靠的备份仍然(稍微)比没有备份好:如果您丢失了笔记本电脑,它可以让您至少恢复部分数据。

如果您继续使用此磁盘,您应该尝试读回所有已备份的文件:也许不是每天,但肯定是每周。

无论如何,你应该问自己:

  • 这些数据对您来说值多少钱?比新磁盘的成本还高吗?大约还有多少倍?
  • 那多少钱时间需要从对您来说有价值的失败备份中恢复数据吗?您的笔记本电脑已经丢失或损坏吗?这会导致您错过重要的业务吗?这会造成多少压力和焦虑?值得冒这个风险吗?

您似乎已经制定了相当不错的备份方案(与普通笔记本电脑所有者相比)。您设置它是有原因的。不要破坏它。

更新:

每条logical block NNNNN, lost async page write消息都意味着操作系统告诉磁盘将一个数据块写入磁盘,并I failed to do it properly从磁盘取回一个数据块。

从理论上讲,这可能意味着写入输出中只有一位被翻转,或者整个块现在是随机的乱码。现实可能介于这两个极端之间。

现代磁盘通常通过将块标记为失败并使用备用块来透明地处理写入失败。事实上,磁盘实际上正在报告故障,这意味着该备用容量已经耗尽:这意味着磁盘上已经有相当多的故障块。

由于您的smartctl命令报告:

SMART support is:     Unavailable - device lacks SMART capability.

除了尝试读回所有数据、将其与原始数据进行比较并计算错误之外,没有办法了解更多细节。

NTFS 和 ext4 都是非常有弹性的文件系统类型,但如果物理存储介质不可靠,它们都无法无限期地生存:如果某些关键文件系统元数据的位置发生故障,整个文件或目录可能会变得无法访问。

如果这些丢失文件的数据恰好位于尚未发生故障的块上,则这些数据可能仍然物理存在于磁盘上,但如果没有文件系统元数据,您需要一些数据恢复软件来找到与每个丢失对应的正确块文件。即使这样,如果文件是碎片化的,或者使用恢复软件未知的文件格式,则不能 100% 保证恢复软件能够准确找到正确的块并将它们重新组装成完整的文件。

有人说:“磁盘本质上是会发生故障的机器——数据存储只是一个副作用。”最终,任何旋转的磁盘都会因机械磨损而发生故障。与安装在台式机或服务器系统中的硬盘相比,便携式硬盘还遭受更多的碰撞和碰撞。

相关内容