ADG Оставить заявку
Блог Управление и процессы 4 мин чтения

Учебная тревога по восстановлению

Как мы устроили клиенту проверку «а поднимемся ли из бэкапа» и что нашли неприятного, пока ничего не горело.

Контекст момента

объёмы данных растут, встаёт вопрос - а восстановится ли система из резервной копии

Бэкапы у клиента были. Лента ежедневно, скрипт по расписанию, кассеты в обороте. По всем признакам - порядок. Мы сами же и настраивали год назад, и на сопровождении всё это время. И тем не менее, когда мы предложили сделать учебное восстановление - просто проверить, а вдруг что, - руководство сначала удивилось. «Зачем? Бэкап же пишется». Вот именно.

Разговор о проверке восстановления мы затеяли не от скуки. Данных у клиента заметно прибавилось за год: к файловой шаре добавилась 1С, почта переехала на свой сервер, вырос склад документов. Объём на лентах вырос вдвое, время записи ночного бэкапа - тоже. И появился тихий вопрос: а sla на восстановление - это сколько реально? Не в теории, а вот прямо сейчас, если завтра сервер умрёт?

Ответа не было ни у кого. Потому что никто не пробовал.

Как мы договорились

Убедить удалось через простую формулировку: «Страховка без проверки - это бумага». Копия, которую ни разу не разворачивали, может быть рабочей, а может нет - вы не знаете. Проверка ничего не стоит в пересчёте на то, что узнаёте.

Договорились сделать в спокойный день, не в конец квартала и не в отчётный период. Взяли субботу. Задача была сформулирована конкретно: поднять 1С и файловую шару на резервной машине из последней ленты, замерить время, зафиксировать что не так.

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

Что нашли

Неприятностей оказалось несколько, и ни одна из них не была катастрофой по отдельности. Вместе они складывались в картину, которую полезно было увидеть заранее.

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

Второе - бэкап базы 1С был, но без одного каталога. Скрипт копировал папку с базой, но в последнем релизе 1С появился вложенный каталог с временными файлами транзакций, который оказался за пределами маски. Формально бэкап шёл, фактически - неполный. Базу мы восстановили, но при запуске 1С выдала ошибку и потребовала переиндексации. Потеряли ещё час.

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

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

В итоге от момента «начали восстановление» до «1С запущена и работает» прошло больше восьми часов. Это суббота, один инженер, никакой спешки. В реальной аварии в рабочий день - давление другое, спешка другая, и восемь часов простоя - это деньги.

Что поменяли

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

Завели документ с паролями и настройками - не в голове у инженера, а в конверте у директора и у нас в зашифрованном архиве. Банально, но не было.

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

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

Итог

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

Хорошая новость: всё это нашлось в спокойный субботний день, а не в среду утром, когда директор стоит за спиной и спрашивает, когда же наконец заработает.

Ранее по теме
Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.