Бэкап на флешке админа: почему это не стратегия восстановления

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

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

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

Когда «бэкап есть» оказывается враньём

Сценарий кражи или потери носителя. На диске персональные данные и коммерческая переписка без шифрования. Теперь у вас инцидент ИБ поверх инцидента доступности.

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

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

Грабли резервного копирования

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

Как сделать так, чтобы бэкап умел восстанавливать

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

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

Разнести копии. Локально для скорости и удалённо для катастрофы площадки. Отдельный контур, куда нет постоянного-write-доступа у того же аккаунта, что у прода.

Шифрование и учёт носителей. Особенно если речь о переносных дисках — иначе бэкап становится утечкой.

Автоматика и мониторинг. Падение задания должно быть инцидентом, а не сюрпризом в день аварии.

Регулярный-test-восстановление. Раз в период поднимать кусок системы из копии. Это единственная проверка, которая имеет значение.

Практика бэкапов и восстановления здесь — про проверяемый контур, а не про флешку в сейфе.

Минимальный план замены «USB админа»

1. Составить список критичных систем и данных.
2. Назначить допустимая потеря данных и время восстановления вместе с бизнесом.
3. Настроить автоматические копии с выносом и алертами.
4. Зашифровать архивы и убрать единственную точку знания «как восстановить».
5. Провести тестовое восстановление и записать регламент.

Итог для руководителя

Бэкап существует только в момент успешного восстановления. Всё остальное — надежда. USB в ящике почти никогда не проходит этот тест на сроке жизни компании.

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

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

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

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

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

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