Чек-лист аварийного восстановления для МСБ

Надежда — это не план восстановления

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

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

Шаг 1: Знайте, что вы защищаете

Нельзя защитить то, что вы не перечислили. Начните с инвентаризации:

• Какие системы и приложения критичны для ежедневной работы? (ERP, бухгалтерия, почта, CRM, сайт, обработка платежей.)
• Где на самом деле живут ваши важные данные — облако, локальные серверы, отдельные ноутбуки, SaaS-инструменты, за которые вы, возможно, забыли, что платите?
• Какие сторонние сервисы остановили бы бизнес, если бы вышли из строя? (Портал вашего банка, система логистического партнёра, провайдер аутентификации.)
• Кто зависит от каждой системы и каков ручной обходной путь, если её не будет в течение часа?

Ранжируйте всё по тому, насколько сильно навредит его потеря. Хорошо работает простое разбиение на уровни: Уровень 1 (без этого бизнес останавливается — восстановить за часы), Уровень 2 (болезненно, но можно пережить день), Уровень 3 (приятно иметь, может подождать). Это ранжирование определяет каждое последующее решение, включая то, куда тратить бюджет на резервное копирование.

Шаг 2: Определите два числа — RTO и RPO

В основе любого плана резервного копирования и аварийного восстановления лежат две цели:

• RTO (целевое время восстановления). Как долго система может быть недоступна, прежде чем это серьёзно навредит? Минуты? Часы? День?
• RPO (целевая точка восстановления). Сколько данных вы можете позволить себе потерять? Если вы делаете резервную копию каждую ночь, сбой в середине дня означает потерю данных за целый день работы.

Установите их для каждой системы. Вашей бухгалтерской платформе и архиву старых маркетинговых файлов не нужны одинаковые цели. Разобранный пример: если у базы данных заказов вашего интернет-магазина RPO в один час, ночных бэкапов не хватит — вы потеряете целый день заказов, что недопустимо, поэтому вам нужны бэкапы каждый час или непрерывная репликация. Если у общего диска со старыми брошюрами RPO в неделю, еженедельной резервной копии вполне достаточно. Соответствие цели системе — это то, как вы избегаете и опасных пробелов, и расточительного перерасхода.

Шаг 3: Следуйте правилу резервного копирования 3-2-1

Стандарт резервного копирования, который выжил, потому что работает:

• 3 копии ваших данных (рабочая копия плюс две резервные).
• 2 разных типа носителей или хранилищ (например, локальный NAS и облачное хранилище).
• 1 копия вне площадки (и в идеале одна офлайн или неизменяемая, чтобы пережить программу-вымогатель).

Единственная резервная копия, лежащая в той же сети, что и ваши рабочие данные, — это не резервная копия, это вторая мишень. Современные программы-вымогатели активно охотятся за подключёнными бэкапами и шифруют их — именно поэтому копия вне площадки и неизменяемая копия так важны. Неизменяемую резервную копию нельзя изменить или удалить в течение заданного срока хранения, даже тому, у кого есть учётные данные администратора, — поэтому, даже если злоумышленники скомпрометируют вашу сеть, эта копия уцелеет. Многие команды теперь расширяют правило до 3-2-1-1-0: дополнительная «1» — это офлайн/неизменяемая копия, а «0» означает ноль ошибок при вашем последнем проверенном восстановлении. Этот финальный ноль чаще всего пропускают, что подводит нас к следующему шагу.

Шаг 4: Тестируйте свои бэкапы (по-настоящему)

Именно здесь большинство планов тихо проваливаются. Резервная копия, которую ни разу не восстанавливали, — это допущение, а не страховка. Бэкапы постоянно отказывают молча — задание, которое каждую ночь сообщает об «успехе», всё равно может резервировать повреждённый файл, неполный набор данных или зашифрованный том, от которого ни у кого нет ключа.

• Планируйте регулярные учения по восстановлению — реально вытаскивайте данные назад, а не просто проверяйте, что задание прошло «зелёным».
• Засекайте время восстановления от начала до конца. Соответствует ли оно вашему RTO? Многие компании обнаруживают, что их «мгновенное» восстановление на самом деле занимает два дня, как только вы учтёте загрузку терабайтов по обычному интернет-каналу.
• Убедитесь, что восстановленные данные полны и пригодны к использованию, а не повреждены — откройте файлы, запустите приложение против восстановленной базы, попросите реального пользователя подтвердить, что всё работает.
• Тестируйте восстановление на другое железо или свежий облачный инстанс, поскольку при настоящей аварии оригинала может уже не быть.

Проводите полные учения не реже раза в квартал, а быструю выборочную проверку — чаще. Если вы ни разу не делали тестовое восстановление, считайте, что ваше восстановление не работает, пока не доказано обратное, — это не пессимизм, а то, чем заканчивается большинство историй «у нас же были бэкапы!».

Шаг 5: Запишите план

В реальном инциденте люди паникуют и забывают. Простой письменный регламент убирает гадание:

• Кто объявляет инцидент и кому он звонит?
• Пошаговый порядок восстановления, начиная с самых критичных систем.
• Контактные данные сотрудников, поставщиков и вашего ИТ-провайдера.
• Где (безопасно) хранятся учётные данные и ключи восстановления.

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

Шаг 6: Учтите человеческие и физические риски

Технологии — лишь часть. План аварийного восстановления, который касается только серверов, провалится на тех частях, которые он проигнорировал:

• Люди. Не позволяйте знаниям о восстановлении жить в голове одного человека. Если ваш единственный компетентный администратор недоступен во время инцидента, в остальном идеальный план застопорится. Обучите как минимум одного запасного и запишите шаги достаточно понятно, чтобы способный сторонний человек смог им следовать.
• Коммуникация. Как вы свяжетесь с сотрудниками и клиентами, если почта и телефоны не работают? Держите внеполосный канал — группу в WhatsApp, личные мобильные номера, страницу статуса — и заранее решите, кому разрешено говорить с клиентами и прессой.
• Физика. Потеря электричества, пожар, наводнение или просто недоступный офис всё равно требуют запасного варианта. Саудовским летом отказ кондиционирования в серверной может вывести из строя железо так же надёжно, как любая кибератака, — поэтому ИБП, термоконтроль и план удалённой работы тоже входят в зону охвата.

Отдельно о программах-вымогателях

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

Три привычки решают исход:

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

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

Быстрый самоаудит

Ответьте честно:

• Есть ли у нас актуальная инвентаризация критичных систем и данных?
• Определены ли RTO и RPO для каждой из них?
• Следуем ли мы правилу 3-2-1, включая копию вне площадки / неизменяемую?
• Действительно ли мы тестировали восстановление за последние 90 дней?
• Есть ли письменный, доступный регламент восстановления?
• Разделены ли знания о восстановлении более чем между одним человеком?

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

Распространённые ошибки, которых стоит избегать

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

• «Настроил и забыл». Бэкапы, настроенные два года назад, которые с тех пор никто не проверял. Хранилище заполняется, задания тихо отказывают, и пробел остаётся незамеченным до дня восстановления.
• Резервируют не то. Старательно резервируют файловый сервер, забывая о SaaS-данных в вашей CRM или почте, — многие облачные приложения не защищают вас от ваших же случайных удалений.
• Нет копии вне площадки или неизменяемой. Идеальный локальный бэкап, который вымогатель шифрует вместе со всем остальным.
• Путают высокую доступность с резервным копированием. Резервный сервер защищает от отказа железа, а не от повреждения, удаления или вымогателя — они исправно реплицируются и на резервную копию тоже.
• Никогда не тестируют. Разобрано выше, но это самая частая и самая дорогая ошибка, поэтому она заслуживает второго упоминания.

Где вписывается Techies

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

---

Хотите, чтобы мы стресс-тестировали вашу текущую схему резервного копирования и восстановления? Свяжитесь с нами.