LTO-3: вдвое больше на картридж и резервная копия БД за ночь

У одного из клиентов накопилась проблема, которую удобно игнорировать ровно до момента, пока она не взрывается: архивный объём вырос до такой точки, что LTO-2 перестал справляться. Не в смысле «работает медленно» - в смысле «резервная копия базы данных не укладывается в ночное окно обслуживания и доедает утро».

Цифры были примерно такие: основная база - чуть больше 300 ГБ, плюс несколько файловых шар с историческими документами. Ежегодный прирост архива - около 2 ТБ. LTO-2 даёт 200 ГБ нативных на картридж и 35-40 МБ/с записи. При нормальном сжатии реальных данных клиента картридж тянул примерно 300-320 ГБ - то есть полный бэкап базы укладывался в один картридж впритык, а любой рост сразу ломал схему. Про скорость: 40 МБ/с на 300 ГБ - это больше двух часов только на запись, плюс дамп, плюс верификация.

Почему именно LTO-3

Переход на LTO-3 был очевидным шагом, а не выбором из нескольких вариантов. Нативная ёмкость картриджа - 400 ГБ, со сжатием производитель заявляет 800 ГБ. Скорость записи - 80 МБ/с нативных. На практике, с данными клиента (смешанный контент: SQL-дампы, офисные документы, PDF-архивы), сжатие даёт примерно 1.5x - то есть реальная ёмкость рабочего картриджа выходит в районе 550-600 ГБ.

Что это меняет в ночном окне:

• Скорость. 80 МБ/с против 40 МБ/с - база в 300 ГБ пишется менее чем за час вместо двух с лишним. Остаётся время на дамп перед записью и на верификацию после.
• Ёмкость. База и файловый архив за месяц умещаются на два-три картриджа вместо шести-восьми. Проще хранить, проще вести ротацию.
• Обратная совместимость. LTO-3-привод читает LTO-2 картриджи. Старые архивы никуда не делись, нет нужды перегонять историю.

Привод взяли внешний, подключаемый через SAS к резервному серверу. Для среднего бизнеса с одной резервной точкой это дешевле и понятнее, чем библиотека с автозагрузчиком.

Схема ротации: Grandfather-Father-Son

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

Настроили классический GFS (Grandfather-Father-Son) на месяц:

• Ежедневные (Son) - четыре картриджа на рабочую неделю, пишутся по кругу. Хранятся одну рабочую неделю, потом перезаписываются.
• Еженедельные (Father) - четыре картриджа на месяц, пятничный полный бэкап. Хранятся месяц.
• Ежемесячные (Grandfather) - последний пятничный бэкап месяца. Хранятся год, лежат отдельно.

Итого активных картриджей в ротации: около двенадцати штук плюс месячные. Это управляемо и физически, и логистически.

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

Что настраивали на стороне программного обеспечения

Использовали Bacula - open source решение, которое умеет GFS-ротацию через пулы картриджей и нормально работает с ленточными устройствами без библиотеки. Настройка не тривиальная: отдельный пул для каждого уровня ротации, политика хранения, расписание заданий.

Несколько нюансов, которые выяснились в процессе:

• Верификация. Bacula умеет верифицировать запись сразу после бэкапа, сравнивая контрольные суммы. Включили обязательно - это добавляет примерно 20-25% времени, но без этого лента - это «я надеюсь что записалось», а не «я знаю что записалось».
• Тест восстановления. Договорились с клиентом проводить тестовое восстановление раз в квартал: берём произвольный картридж, поднимаем базу на отдельном стенде, проверяем что она стартует и отвечает на запросы. Это не автоматика, это ручная процедура с часом работы инженера. Но без неё резервный картридж - это вера, не гарантия.
• Маркировка картриджей. Звучит банально, но на практике - это первое что ломается, когда схемой пользуются несколько человек. Сделали физическую маркировку с цветовым кодом по уровню (дневные/недельные/месячные) и журнал в табличке на стене серверной. Никаких умных систем - просто бумага и ручка.

Результат после первого месяца

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

Что осталось открытым: мониторинг состояния привода. Ленточные приводы имеют ресурс по головкам, и LTO-3 в этом смысле не исключение. Сейчас контролируем вручную через лог Bacula - если задание упало, приходит письмо. Нормального мониторинга ресурса привода пока нет, это отдельная задача.

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