← Назад к базе знаний

Резервные копии: почему их наличие ничего не значит

Резервные копии: почему их наличие ничего не значит

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

Почему копии есть, а восстановления нет

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

Копируется не то. Настроили когда-то один сервер, с тех пор появились три новых, и в расписание их никто не добавил. Проверяется за десять минут, обнаруживается годами позже.

Копия сделана «на живую». База, скопированная во время записи, разворачивается в противоречивом состоянии. Файлы есть, размер правильный, восстановление не запускается.

Копия лежит рядом. На соседнем диске того же сервера или в той же сети. Шифровальщик доберётся до неё вместе с оригиналом, пожар — тоже.

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

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

Правило трёх копий и что оно значит на практике

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

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

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

Как об этом говорить с клиентом

Не «у вас есть бэкапы?», а «за сколько вы восстановитесь и сколько данных потеряете». Два числа — время восстановления и допустимая потеря — переводят разговор из технического в управленческий, и на них уже можно считать деньги.

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

Не «резервное копирование», а «проверяемое восстановление». Смещение акцента с процесса на результат — главное, что отличает предметный разговор от продажи объёма хранилища.

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

Где вендоры преувеличивают

«Мгновенное восстановление». Обычно означает запуск системы прямо из хранилища копий в сниженном режиме. Полезно, но работает медленнее обычного и не всегда подходит для нагруженных систем. Уточнять надо, что именно происходит и с какой производительностью.

«Проверка целостности». Часто это проверка контрольных сумм файлов, а не запуск системы. Файл цел — приложение может не подняться. Спрашивать надо про автоматический запуск восстановленной копии, а не про целостность.

«Неизменяемое хранение». Существует в разных исполнениях, и часть из них отключается администратором с достаточными правами — то есть ровно тем, чью учётную запись и захватывают при атаке. Вопрос: можно ли отключить и что для этого нужно.

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

Что спросить у своего инженера перед встречей

  1. Что именно попадает в копию у клиента и что гарантированно не попадает?
  2. Как мы обеспечиваем согласованное состояние баз данных при копировании?
  3. Что у нас с неизменяемым хранением и можно ли его отключить изнутри?
  4. Сколько по нашему опыту занимает полное восстановление системы такого размера?
  5. Как выглядит регулярная проверка восстановления и кто её проводит после внедрения?

Красные флаги на стороне клиента

  • Восстановление ни разу не проверялось. Формально защита есть, фактически её нет. Это и есть первая продаваемая работа, независимо от вашего продукта.
  • Все копии в одной сети. Один инцидент уносит и данные, и копии. Закрывается недорого и даёт видимый результат быстро.
  • За копии отвечает тот же администратор, что и за системы. Разделение ролей здесь не бюрократия: при захвате его учётной записи теряется всё сразу.
  • Хранят всё и вечно. Признак, что политику никто не формулировал. Счёт растёт, а нужные данные всё равно ищутся долго.

Вопросы, которые задаст технический директор

«Сколько времени займёт восстановление всего, а не одного сервера?» — восстановление по очереди складывается, и сумма обычно неприятно удивляет. Честный ответ ценится.

«Что с копиями облачных сервисов?» — распространённое заблуждение, что данные в облачном сервисе защищены поставщиком автоматически. Ответственность за содержимое почти всегда остаётся на клиенте.

«Как быстро мы найдём один удалённый документ?» — восстановление целиком и поиск одного файла — разные сценарии, и второй встречается в сто раз чаще.

«Кто имеет право удалить копии?» — вопрос про разделение прав. Если ответ «администратор», защита от шифровальщика неполная.

Что забрать с собой

  • Наличие копий не значит ничего; значение имеет дата последнего успешного восстановления.
  • Три копии, два типа носителей, одна вне площадки, одна неизменяемая, ноль ошибок при проверке.
  • Современные атаки начинаются с уничтожения копий — неизменяемость обесценивает эту схему.
  • Разговор ведётся двумя числами: время восстановления и допустимая потеря данных.
  • Учебное восстановление одной системы — небольшая работа, которая продаёт всё остальное.

Клиент говорит: «у нас всё копируется автоматически». Что дальше?

Спросить, что именно входит в расписание и когда список обновлялся. Обычно выясняется, что за последние два года появились системы, которых в расписании нет. Это проверяется быстро и почти всегда что-то находит.

Данные в облачном сервисе нужно копировать отдельно?

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

Как часто проверять восстановление?

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

Что отвечать на «это дорого»?

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

С чего начать, если у клиента нет вообще ничего?

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

Рамки по теме

Разобранное выше опирается на эти рабочие рамки — их можно открыть отдельно.

Руслан ОмаровFull-Stack Business Architect · Облако и ИИОб авторе
Материал оказался полезным?

Отпечаток текста 1937bf4de7c0… · проверить подлинность