Почему не делать проверку винта непосредственно перед бекапом?
2014-12-28 9:54 GMT+02:00 Victor Wagner vi...@wagner.pp.ru:
On 2014.12.28 at 03:10:10 +0400, Alex Kicelew wrote:
Hi.
Вопрос скорее идеологический, чем дебиановский, но просто не знаю,
куда его еще задать.
А существуют ли способы мониторинга в домашних условиях физического
состояния USB-винта (не SSD), который хотя и подключается обычно на
одно и то же логическое устройство, но кроме него на это устройство
изредка попадают и другие девайсы?
smartctl с USB-дисками рабоает. Следовательно вопрос всего лишь в том,
чтобы запускать его каждый раз, когда это устройство подключается к
системе и не запускать, когда подключается какое-то другое.
Как уже подсказали в соседнем письме, есть в /dev путь, который
принадлежит только этому усройству и никакому другому.
Поэтмоу возможен такой вариант - раз в пять минут по крону проверяем,
когда последний раз было снято состояние с этого диска (просто по
таймштампу файла, куда мы его пишем), и если более суток назад, проверям
есть ли в /dev/disk/by-id интересующий нас симлинк. Если есть, запускаем
smartctl и предпринимаем необходимые меры, если результат не совпадает
с предыдущим сохраненным (пишем письмо админу).
В качестве альтернативы можно из udev правила при подключении этого
диска запускать тот же самый скрипт со сравнением результатов smartctl с
сохраненными. Но вариант с cron-ом лучше тем, что в случае если диск на
неделю оставили подключенным к машине, он будет продолжать мониториться.
Хотелось бы хотя бы в будущем иметь возможность предвидеть смерть
бэкапного винта до того, как он хряпнется. Ибо после того потребен
некоторый лаг на то, чтобы купить новый (особенно в наше
предпраздничное время, отягощенное курсом доллара) и записать на него
изначальный бэкап немалого размера, и все это время основная машины
пребывает без бэкапа, а закон подлости никто не отменял.
В данном случае, я бы порекомендовал по сусекам поскрести и завести
второй бэкапный винт. И бэкапить на них по очереди. Тогда меры можно
будет предпринимать после того, как первый хряпнется.
Хотя на самом деле, лучше применить оба решения одновременно.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive: https://lists.debian.org/20141228075453.ga27...@wagner.pp.ru
