Учебная тревога по восстановлению
Как мы устроили клиенту проверку «а поднимемся ли из бэкапа» и что нашли неприятного, пока ничего не горело.
объёмы данных растут, встаёт вопрос - а восстановится ли система из резервной копии
Бэкапы у клиента были. Лента ежедневно, скрипт по расписанию, кассеты в обороте. По всем признакам - порядок. Мы сами же и настраивали год назад, и на сопровождении всё это время. И тем не менее, когда мы предложили сделать учебное восстановление - просто проверить, а вдруг что, - руководство сначала удивилось. «Зачем? Бэкап же пишется». Вот именно.
Разговор о проверке восстановления мы затеяли не от скуки. Данных у клиента заметно прибавилось за год: к файловой шаре добавилась 1С, почта переехала на свой сервер, вырос склад документов. Объём на лентах вырос вдвое, время записи ночного бэкапа - тоже. И появился тихий вопрос: а sla на восстановление - это сколько реально? Не в теории, а вот прямо сейчас, если завтра сервер умрёт?
Ответа не было ни у кого. Потому что никто не пробовал.
Как мы договорились
Убедить удалось через простую формулировку: «Страховка без проверки - это бумага». Копия, которую ни разу не разворачивали, может быть рабочей, а может нет - вы не знаете. Проверка ничего не стоит в пересчёте на то, что узнаёте.
Договорились сделать в спокойный день, не в конец квартала и не в отчётный период. Взяли субботу. Задача была сформулирована конкретно: поднять 1С и файловую шару на резервной машине из последней ленты, замерить время, зафиксировать что не так.
Взяли старый сервер, который стоял в углу после апгрейда основного. Поставили чистую систему. Достали пятничную ленту. Поехали.
Что нашли
Неприятностей оказалось несколько, и ни одна из них не была катастрофой по отдельности. Вместе они складывались в картину, которую полезно было увидеть заранее.
Первое - лента читалась медленнее, чем писалась. Это нормально для стримера, но мы не учли это в оценке времени. Запись ночного бэкапа занимала около трёх часов. Полное чтение обратно - пять с лишним. Никто не считал это заранее.
Второе - бэкап базы 1С был, но без одного каталога. Скрипт копировал папку с базой, но в последнем релизе 1С появился вложенный каталог с временными файлами транзакций, который оказался за пределами маски. Формально бэкап шёл, фактически - неполный. Базу мы восстановили, но при запуске 1С выдала ошибку и потребовала переиндексации. Потеряли ещё час.
Третье - пароли и настройки. Принтеры, сетевые пути, настройки почтового клиента на тестовой машине - всё это пришлось восстанавливать руками. Документации не было. Часть ключей для принтерных драйверов нашлась только потому, что их помнил один из наших людей.
Четвёртое - резервная машина тянула медленнее. Процессор старый, памяти меньше. 1С работала, но со скрипом. При реальной аварии люди бы работали в таком режиме до починки основного сервера - вопрос в том, как долго это приемлемо.
В итоге от момента «начали восстановление» до «1С запущена и работает» прошло больше восьми часов. Это суббота, один инженер, никакой спешки. В реальной аварии в рабочий день - давление другое, спешка другая, и восемь часов простоя - это деньги.
Что поменяли
Переписали скрипт бэкапа - с явным перечнем каталогов вместо маски. Добавили проверку: после каждого ночного бэкапа скрипт пишет в лог размер архива и количество файлов, и если цифры упали больше чем на десять процентов - флаг на утро.
Завели документ с паролями и настройками - не в голове у инженера, а в конверте у директора и у нас в зашифрованном архиве. Банально, но не было.
Оценили sla на восстановление честно: восемь часов при хорошем раскладе, двенадцать при плохом. Клиент это принял к сведению. Разговор о втором сервере в горячем резерве пока отложили - это другой бюджет, другой разговор. Но хотя бы знаем, от чего отталкиваться.
Регламент на проверку написали сразу: раз в полгода, плановое восстановление на резервную машину, фиксировать время и замечания. Это единственный способ не обнаружить сюрпризы в день, когда они меньше всего нужны.
Итог
Мы давно говорили, что бэкап без проверки - не бэкап. Здесь убедились в этом ещё раз, только с другой стороны: копия писалась честно, железо работало, а всё равно нашлось три вещи, которые в реальной аварии добавили бы боли. Не смертельно ни одна, но вместе - неприятно.
Хорошая новость: всё это нашлось в спокойный субботний день, а не в среду утром, когда директор стоит за спиной и спрашивает, когда же наконец заработает.
- Резервные копии и миф о RAID · 8 ноября 2001