Наше "решение" резервного копирования включает в себя подключение USB-накопителя к серверу резервного копирования и запуск специального сценария, который rsyncs данные на 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-накопителей не имеют специальной защиты от падений / ударов или тепловых изменений, это просто стандартный накопитель SATA в пластиковом корпусе USB-to-SATA.
Мое практическое правило для дисков, особенно когда речь идет о резервных копиях, гласит: если есть сомнения, выбросьте их.
Чтобы исключить USB-инфраструктуру, вы можете активно запускать диск на другом компьютере, что на самом деле не решает вашу проблему, поскольку вам все равно нужно создавать резервную копию компьютера.
Дополнительная информация приведена выше у Дэвида Макинтоша (его ответ очень хорош). Сама файловая система имеет возможность указать ядру перемонтировать ее в режиме «только для чтения» при обнаружении ошибки.
На странице руководства mount (8):
ошибки = продолжить / ошибки = remount-ro / errors = паника
Определите поведение при обнаружении ошибки. (Либо игнорируйте ошибки и просто отметьте файловую систему как ошибочную и продолжайте, либо перемонтируйте файловую систему только для чтения, либо паникуйте и остановите систему.) Значение по умолчанию устанавливается в суперблоке файловой системы и может быть изменено с помощью tune2fs (8 ).
Я гарантирую, что если вы не монтируете с ошибками = remount-ro, тогда файловая система имеет этот параметр в качестве опции (образец из моего dumpe2fs ниже)
# dumpe2fs /dev/md0 | grep Error
dumpe2fs 1.41.3 (12-Oct-2008)
Errors behavior: Continue
Вы можете узнать, что SMART считает неправильным с накопителем, запустив smartctl.
smartctl -a /dev/<your drive>
Я бы согласился с Дэвидом, серьезно подумаю о замене привода. Нет ничего хуже, чем восстанавливать все ваши данные только для того, чтобы обнаружить, что они не читаются.