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
