Бэкапы, которые никто не восстанавливал, бэкапами не являются 

На вопрос «есть ли у вас резервные копии» почти все отвечают утвердительно. На вопрос «когда вы последний раз из них восстанавливались» уверенных ответов заметно меньше. Разница между этими двумя вопросами и есть предмет разговора.

Копия, из которой ни разу не поднимали систему, — это предположение о том, что все будет хорошо. Проверяется оно ровно один раз, в самый неподходящий момент, и цена ошибки измеряется рабочими днями всего предприятия.

Два параметра, с которых все начинается

Прежде чем выбирать инструменты и расписания, надо ответить на два вопроса на языке бизнеса.

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

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

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

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

Копия на том же сервере копией не является

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

Она не защищает от отказа сервера, от выхода из строя дискового массива, от шифровальщика, который дойдет до соседнего диска за секунды, от затопления серверной и от изъятия оборудования.

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

Что именно надо копировать

Учетная база — очевидная часть. Забывают обычно все остальное, и на восстановлении это выясняется в самый неудобный момент.

Последняя строка — классическая причина многочасовой задержки: база восстановлена, а войти в систему невозможно, потому что ключ защиты остался в сгоревшем сервере, а документы на лицензии никто не может найти.

Три уровня защиты и что они стоят

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

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

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

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

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

Регламент тестового восстановления

Главная мысль всей статьи. Копия считается рабочей только после того, как из нее подняли систему и убедились, что она работает.

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

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

Отдельно проверяется восстановление на другое железо. Копия, которая разворачивается только на исходном сервере, бесполезна в сценарии, ради которого все и делалось.

Пять способов обнаружить, что копий нет

Все случаи из практики, и все обнаруживаются только в момент аварии.

Задание давно падает. Копирование настроено, но месяц назад кончилось место или сменился пароль учетной записи, а уведомления об ошибках никто не читает.

Копируется не то. База переехала на другой сервер или сменила имя, а задание продолжает копировать старую, давно неактуальную.

Архив поврежден. Файл создается, но не открывается: сбои хранилища, обрыв при записи, нехватка места в конце процесса.

Копия зашифрована вместе с остальным. Шифровальщик добрался до сетевой папки с архивами, потому что она была доступна на запись из рабочей сети.

Нет ключей и паролей. Архив зашифрован, а пароль знал уволившийся администратор. Или лежит в системе, которая тоже недоступна.

Первый час аварии

Порядок действий должен существовать на бумаге и лежать вне восстанавливаемых систем: распечатка в сейфе или файл на телефоне ответственного.

1. Зафиксировать состояние. Не начинать чинить сгоряча: поспешные действия часто уничтожают возможность восстановления.
2. Определить масштаб. Что именно недоступно: одна база, сервер целиком, вся сеть.
3. Изолировать. При подозрении на шифровальщик — отключить пораженные машины от сети до разбора.
4. Оповестить. Руководство и ключевых пользователей: что случилось, чего ждать, когда следующее обновление статуса.
5. Выбрать точку восстановления. Самая свежая копия, которая заведомо не содержит проблему.
6. Восстанавливать на отдельное оборудование. Исходное оставляют нетронутым до выяснения причины.
7. Проверить данные до открытия доступа. Контрольные отчеты и остатки, чтобы люди не начали работать в неверной копии.
8. Записать хронологию. Пригодится и для разбора, и для страховой, и для того, чтобы это не повторилось.

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

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

Отдельно про облачные сервисы и почту

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

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

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

Тот же принцип касается сервисов, которыми вы пользуетесь по подписке: учетных, кадровых, складских. Возможность выгрузить свои данные в понятном формате стоит проверять до того, как она понадобится. В момент спора с поставщиком услуги проверять будет поздно.

Сколько хранить и где

Глубина хранения определяется двумя соображениями: техническим сбоем и поздним обнаружением проблемы.

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

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

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

Что входит в наше администрирование

Резервное копирование — часть подписки на администрирование серверов: 35 000 ₽ в месяц для небольшого контура, 70 000 ₽ для среднего, 180 000 ₽ для распределенного с несколькими площадками.

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

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

Кто и когда узнает о проблеме

Мониторинг копирования устроен проще, чем кажется, и отсутствует чаще, чем можно предположить.

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

Уведомления должны приходить человеку, а не в общий ящик, и содержать понятный текст. Сообщение «код ошибки 0x8007» без расшифровки будет проигнорировано трижды, а на четвертый раз перестанет читаться вовсе.

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

Частые вопросы

Достаточно ли облачного хранилища? Как одна из копий — да, как единственная — нет. Проверьте, что доступ к ней не зависит от скомпрометированной учетной записи и что скорость восстановления укладывается в ваши требования: выкачивание сотен гигабайт занимает время.

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

Как часто проверять восстановление? Раз в квартал для обычного бизнеса. После любого крупного изменения инфраструктуры — обязательно, не дожидаясь графика: смена сервера, переезд, обновление платформы, изменение схемы хранения. Каждое такое событие способно тихо сломать копирование, и обнаружиться это должно на проверке.

Восстановление части данных

Полная авария — редкий сценарий. Гораздо чаще требуется вернуть небольшой кусок: удаленный документ, испорченный справочник, данные одного участка за конкретный день.

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

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

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

Чек-лист на сегодня

1. Названы допустимая потеря данных и допустимое время простоя, в часах, письменно.
2. Копии лежат минимум в двух местах, одно из них вне здания.
3. Хотя бы одна копия недоступна для изменения из рабочей сети.
4. В копию входят конфигурация, внешние обработки, присоединенные файлы, ключи и настройки.
5. Об ошибках копирования приходит уведомление живому человеку.
6. Проведено и записано тестовое восстановление за последние три месяца.
7. Известно фактическое время восстановления по замеру.
8. Порядок действий при аварии существует на бумаге вне систем.
9. Пароли к архивам знает больше одного человека и они лежат в защищенном хранилище.

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