我们的备份“解决scheme”包括将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-to-SATA塑料shell中的标准SATA驱动器。
我对磁盘的经验法则，特别是在备份方面，是：如果有疑问，请把它扔掉。
要排除USB基础架构，可以在另一台计算机上广泛运行磁盘，但实际上并不能解决您的问题，因为您仍然需要备份计算机。
上面David Mackintosh的更多信息（他的回答非常好）。 文件系统本身可以select告诉内核在遇到错误时重新挂载它。
从mount（8）手册页：
errors = continue / errors = remount-ro / errors = panic
定义遇到错误时的行为。 （或者忽略错误，只是将文件系统标记为错误并继续，或者以只读方式重新挂载文件系统，或者恐慌并暂停系统。）缺省设置在文件系统超级块中，可以使用tune2fs（8 ）。
我保证，如果你没有安装errors = remount-ro，那么文件系统会把它设置为一个选项（从我的dumpe2fs下面的示例）
# dumpe2fs /dev/md0 | grep Error dumpe2fs 1.41.3 (12-Oct-2008) Errors behavior: Continue
通过运行smartctl，您可能能够找出SMART认为错误的驱动器
smartctl -a /dev/<your drive>
我会同意大卫，认真考虑更换驱动器。 没有什么比只有恢复所有数据才发现不可读的更糟。