我们的备份“解决方案”包括将 USB 驱动器连接到备份服务器,并运行自定义脚本rsync
将数据存储到 USB 驱动器上。但是,一段时间后,驱动器变为只读。这是 dmesg 的输出:
[2502923.708171] sdb: sdb1
[2502923.742767] sd 36:0:0:0: [sdb] Attached SCSI disk
[2502980.368020] kjournald starting. Commit interval 5 seconds
[2502980.482705] EXT3 FS on sdb1, internal journal
[2502980.482705] EXT3-fs: recovery complete.
[2502980.488709] EXT3-fs: mounted filesystem with ordered data mode.
[2590744.432168] usb 1-2: USB disconnect, address 36
[2590744.432655] sd 36:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
[2590744.432784] end_request: I/O error, dev sdb, sector 795108447
[2590744.432857] Buffer I/O error on device sdb1, logical block 99388548
[2590744.432925] lost page write due to I/O error on sdb1
[2590744.433002] Buffer I/O error on device sdb1, logical block 99388549
[2590744.433070] lost page write due to I/O error on sdb1
[2590744.433139] Buffer I/O error on device sdb1, logical block 99388550
[2590744.433207] lost page write due to I/O error on sdb1
[2590744.433275] Buffer I/O error on device sdb1, logical block 99388551
[2590744.433343] lost page write due to I/O error on sdb1
[2590744.433410] Buffer I/O error on device sdb1, logical block 99388552
[2590744.433478] lost page write due to I/O error on sdb1
[2590744.433545] Buffer I/O error on device sdb1, logical block 99388553
[2590744.433613] lost page write due to I/O error on sdb1
[2590744.433681] Buffer I/O error on device sdb1, logical block 99388554
[2590744.433749] lost page write due to I/O error on sdb1
[2590744.433817] Buffer I/O error on device sdb1, logical block 99388555
[2590744.433884] lost page write due to I/O error on sdb1
[2590744.433953] Buffer I/O error on device sdb1, logical block 99388556
[2590744.434021] lost page write due to I/O error on sdb1
[2590744.434089] Buffer I/O error on device sdb1, logical block 99388557
[2590744.434157] lost page write due to I/O error on sdb1
[2590744.443942] sd 36:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
[2590744.447945] end_request: I/O error, dev sdb, sector 795108687
[2590744.452065] Aborting journal on device sdb1.
[2590744.452065] __journal_remove_journal_head: freeing b_committed_data
[2590744.452410] EXT3-fs error (device sdb1) in ext3_ordered_writepage: IO failure
[2590744.453795] __journal_remove_journal_head: freeing b_committed_data
[2590744.454481] ext3_abort called.
[2590744.454548] EXT3-fs error (device sdb1): ext3_journal_start_sb: Detected aborted journal
[2590744.454697] Remounting filesystem read-only
[2590744.457033] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #11968705 offset 0
[2590776.909451] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #122881 offset 0
[2590777.637030] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #30015490 offset 0
[2590949.026134] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0
[2591121.070802] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0
[2591211.109072] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0
[2591300.269439] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0
[2591357.322837] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0
[2591418.664452] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0
[2591572.792037] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0
[2591667.952082] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0
[2591669.639597] __ratelimit: 3981 messages suppressed
[2591669.639658] Buffer I/O error on device sdb1, logical block 61014530
[2591669.639698] lost page write due to I/O error on sdb1
我没有在我的脚本中卸载驱动器;任何人都可以提出什么会导致这种情况,所以我可以解决它?
当我使用固定磁盘发生这种情况时,这意味着磁盘正在死去。这很可能就是这里发生的事情。如果这是一个在位置之间反复连接/断开/传输的备份驱动器,则很可能是冲击或反复的热变化导致了缺陷。这些 USB 驱动器中的大多数都没有针对跌落/冲击或热变化进行特殊保护,它们只是 USB 到 SATA 塑料外壳中的标准 SATA 驱动器。
我对磁盘的经验法则,尤其是在备份方面,是:如果有疑问,就把它扔掉。
要排除 USB 基础设施,您可以在另一台计算机上广泛运行磁盘,这实际上并不能解决您的问题,因为您仍然需要备份计算机。
更多关于上面大卫麦金托什的信息(他的回答非常好)。文件系统本身可以选择告诉内核在遇到错误时以只读方式重新挂载它。
从 mount(8) 手册页:
我保证,如果您没有使用 errors=remount-ro 进行安装,那么文件系统会将其设置为选项(下面我的 dumpe2fs 中的示例)
您可以通过运行 smartctl 找出 SMART 认为驱动器有什么问题
我同意大卫的观点,认真考虑更换驱动器。没有什么比恢复所有数据却发现它不可读更糟糕的了。