Ленточные бекапы и ротация дед-отец-сын: почему нельзя делать на авось

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

История конкретная. Клиент - торговая компания, 20 с чем-то человек, файловый сервер с базой 1С и документами. Active Directory уже развернули, сервер стоит на ИБП, всё чин чинарём. Купили стример DAT72, три кассеты, решили делать ротацию дед-отец-сын: ежедневные инкременты на сына, полный бекап по пятницам на отца, в конце месяца отец становится дедом и откладывается на полку.

Схема правильная. Реализация подвела. Причём не в одном месте, а сразу в нескольких.

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

Разобрались. Причин оказалось несколько, и все банальные.

Первое - кассеты хранились не там. Две кассеты лежали рядом со стримером на верхней полке стойки. Стойка в серверной комнате, которая не серверная, а чулан с кондиционером на окне. Летом там был перегрев. Магнитная лента не любит температурных качелей, и записи деградировали. Кассеты надо хранить отдельно, в нормальных условиях, а ещё лучше - одну копию вообще выносить из здания.

Второе - головка стримера не чистилась. За три месяца ни разу. У DAT-стримеров рекомендация - чистящая кассета раз в 25-30 часов работы. Если делаешь бекап каждую ночь, это примерно раз в три-четыре недели. Загрязнение головки ведёт к ошибкам записи, которые программа бекапа не всегда честно докладывает в лог.

Третье - проверку после записи никто не включал. В настройках Backup Exec стоял режим «написать и забыть». Verify after backup был выключен - ради скорости. Экономия - минут сорок. Цена - неизвестно, читается ли то, что записали.

Четвёртое - кассеты были дешёвые. Не левые, с полки местного магазина, но не того производителя, что рекомендован к стримеру. На хороших носителях это часто прокатывает, но когда условия хранения уже не идеальные, разница в качестве ленты начинает играть.

Что мы поменяли по итогу: включили verify, добавили в регламент чистку головки раз в месяц, заменили кассеты на рекомендованные производителем, и главное - договорились, что пятничную кассету сотрудник каждую неделю забирает домой. Примитивно, но работает. Для компании без отдельного хранилища это нормальная практика.

Ещё одно наблюдение по самой ротации дед-отец-сын. Схема хорошая, но у неё есть подводный камень: если ошибка в данных обнаружилась не сразу, а через три-четыре недели, «дед» к тому моменту может уже перезаписаться. Минимальный набор для реального использования - три ежедневных кассеты, четыре недельных, два или три месячных. Итого девять-десять кассет. Те, кто берёт три кассеты на всю ротацию, фактически держат глубину восстановления не больше нескольких дней.

Цена ошибки здесь несимметрична. Стример стоит денег, кассеты стоят денег, регламент занимает время. Но всё это несравнимо с тем, что бывает, когда данных за последний месяц нет, а хозяйственный учёт в 1С надо восстанавливать из бумаги.

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

Первая проверка восстановления - не формальность. Это единственный способ узнать, есть ли у вас бекап или только ощущение бекапа.