Назад | Перейти на главную страницу

Нужно ли мне выполнять проверку резервных копий на ленте LTO, даже если сами накопители выполняют проверку во время записи?

У нас есть ленточный накопитель LTO-3 в медиатеке Dell, который мы используем для резервного копирования на магнитную ленту. В статья о LTO в Википедии говорится, что:

LTO использует технологию автоматической проверки после записи для немедленной проверки данных по мере их записи, но некоторые системы резервного копирования явно выполняют полностью отдельную операцию чтения ленты, чтобы убедиться, что лента была записана правильно. Эта отдельная операция проверки удваивает количество сквозных проходов для каждого запланированного резервного копирования и вдвое сокращает срок службы ленты.

Я хотел бы знать, нужно ли мне мое программное обеспечение для резервного копирования (в данном случае Backup Exec) для проверки этих лент или достаточно ли технологии проверки после записи, присущей накопителям LTO?

Мне также было бы любопытно, понимает ли Backup Exec технологию проверки после записи в достаточной степени, чтобы предупредить меня, если эта технология не может обработать данные или просто проигнорирует их, что сделает их бесполезными, поскольку даже если диск обнаружит проблему, я никогда не знать об этом.

Отличный вопрос!

Хотя я бы сказал, что да, вы должны их протестировать, я бы сказал, что тестирование самих лент / дисков важно, что гораздо важнее, так это тестирование полного восстановления. обработать.

Я не могу порекомендовать достаточно регулярных полных восстановлений системы и сервисного тестирования, это единственный способ узнать для уверенности что вся система делает то, для чего вы ее купили. Вам не нужно далеко заглядывать на этот сайт, чтобы увидеть людей, которые изо всех сил пытаются восстановить свои услуги, даже если они думали, что прошли все шаги индивидуально.

Надеюсь это поможет.

Во-первых, эта автоматическая проверка не может заменить сквозную проверку. Я видел диски, поставляемые с ошибкой микропрограммы, из-за которой чтение восстановления было менее надежным, чем чтение проверки.

В результате вы могли записывать ленты без каких-либо сообщений об ошибках, но при попытке восстановления вы бы увидели, что при чтении возникают ошибки или скорость падает на несколько порядков.

Большинство клиентов никогда не замечали эту ошибку прошивки. По словам производителя, потому что клиенты фактически не выполняли тестовое восстановление. Эта конкретная ошибка исправлена. Но я уверен, что мы не видели последней ошибки прошивки, и некоторые ошибки прошивки будут обнаружены только в том случае, если вы действительно протестируете реальные чтения.

Что происходит при неудачной проверке, так это то, что микропрограмма автоматически записывает вторую копию (а во время восстановления микропрограммное обеспечение прозрачно для хоста возвращает только одну из двух копий). Это означает, что доступная емкость зависит от состояния диска и качества носителя.

Если слишком много попыток записи терпят неудачу при проверочном чтении, на уровне SCSI сообщается об ошибке. Можно подумать, что ошибку, сообщенную таким образом, трудно пропустить на программном уровне, но ошибки в путях кода, которые запускаются только ненадежным оборудованием, как известно, трудно проверить.