Есть ситуация, которая сложилась у нашего клиента, и я хотел бы лучше разобраться.
Вот что произошло:
Подробностей о поставщиках оборудования у меня нет.
Похоже, что на ленточном накопителе произошел сброс, который вызвал перемотку ленты, но эта ситуация не была сообщена как ошибка в драйвере и программном обеспечении, поэтому программное обеспечение предполагало, что запись была успешной.
Я читал много документации, чтобы понять, почему это произошло, но я не могу сделать окончательных выводов, чтобы помочь заказчику.
Буду очень благодарен, если кто-нибудь подскажет, как продолжить.
Это известная проблема с ленточными накопителями и способ, которым их тривиально - легко перемотать, просто взглянув на устройство сбоку (т. Е. Открыв его неправильно - через перематывающее устройство - просто, например, для проверки статуса).
По крайней мере, одна важная часть программного обеспечения резервного копирования UNIX настолько обеспокоена этим, что просто отказывается записывать на ленту во второй раз, пока эта лента не будет готова к стиранию; это от FAQ Аманды (в котором конкретно упоминается сброс шины как проблемная область):
Почему Аманда не добавляет к ленте?
Один запуск Аманды = один (набор) лент. Аманда открывает ленточное устройство один раз, записывает все изображения и метки файлов и один раз закрывает устройство. Используя эту последовательность, нет никакой возможности, чтобы другие программы прервали последовательность и перемотали ленту, чтобы Аманда не заметила.
Может быть достаточно "mt -f / dev / st0 status" или даже "amcheck daily". Также ошибка типа сброса шины scsi подразумевает перемотку назад.
Если Аманда закроет и снова откроет ленточный накопитель для каждого образа резервной копии, появится окно уязвимости, когда лента случайно перемотается, и следующий образ перезапишет все хорошие резервные копии на ленте. И вы бы не узнали, если бы не попытались восстановить с ленты.
При добавлении к ленте существует вероятность того, что между моментом, когда Аманда позиционирует последнее изображение (что уже нетривиально!) И открытием устройства для записи, произойдет перемотка ленты, и в этом случае Аманда будет Удачно сотрите ВСЮ ленту, содержащую, возможно, многодневную резервную копию.
Bacula также решает проблему, никогда не закрывая ленточное устройство, чтобы никто другой не мог открыть его по ошибке, пока лента загружена. Но это не решает проблему сброса шины.
По сути, это является проблема, и это трудная. Я могу утверждать, что ваше оборудование для резервного копирования должно быть достаточно надежным, чтобы это происходило не часто; если FC кажется особенно склонным к этим, пора вместо этого получить ленточный накопитель SAS или, по крайней мере, напрямую подключить ленточное устройство к серверу резервного копирования, чтобы удалить оптоволоконные переключатели и т. д. с пути. Кроме этого, я не понимаю, как вы можете сделать гораздо больше, чем у вас есть, поскольку вы обнаружили проблему раньше обычного момента, т.е. "наши восстановления не работают, мы облажались".