Comments 13
Классика.
Люди делятся на три типа: те, кто еще не делает бэкапы; те, кто уже делает бэкапы; и те, кто проверяет, что бэкапы корректно восстанавливаются.
А если гдето в ОС и/или контейнере заселилась какая нибудь сущность типа шифровальщика? Всё будет нормально восстанавливаться и работать правда ровно до того момента когда вас решать взять за яйца. Нормальную проверку ничего не заменит. Помню в старые времена это называлось "учения по ИБ" когда ставили сервер с пустым винтом и терминал с пустым винтом брали свежий бэкап и восстанавливали всё до полной работоспособности.
Полностью согласен, нормальные прогоны с восстановлением — нужны, и я этого не отрицаю. Автоматическая проверка — это не замена ручным прогонам, а то, что делается между ними. Ручные прогоны проводят раз в квартал или год, а бэкап успевает испортиться за неделю. Главное, чтобы к моменту тренировки (или реальной аварии) бэкап гарантированно восстановливается, а не просто «должен».
Что касается шифровальщика, есть два сценария, и они решаются по-разному:
Бэкапы портятся заранее. Часто бывает так: сначала тихо портят резервные копии, а потом уже бьют по продакшену, чтобы нечем было восстанавливаться. Ежедневная проверка восстановления выявляет это почти сразу: дамп перестает восстанавливаться — срабатывает оповещение за дни или недели до «часа Х», а не в момент, когда уже поздно.
Бэкапы уничтожают во время атаки. Здесь никакая проверка накануне не поможет. Спасут только неизменяемые и изолированные копии: S3 Object Lock, оффлайн-носители, отдельный аккаунт с другими ключами. Это дополнительная защита, которая нужна всегда, независимо от проверок.
Таким образом, проверка восстановлением помогает, когда «бэкап просто умер» (в том числе из-за злоумышленников), но не когда «всю инфраструктуру захватили». От этого защищают неизменяемость копий и сами тестовые прогоны .
Одна неточность у Вас - шифровальщик не портит он шифрует при записи и расшифровывает при чтении. Поэтому может оказаться что уже давно всё зашифровано но всё прекрасно работает. Чтобы не светить производительностью он может шифровать одну страницу из например 10 всё равно каждая десятая испорченная страница это катастрофическая потеря данных.
Если я Вас правильно понимаю, то это хорошее замечание, но тут нужно различать логическое и физическое резервное копирование.
С логическим бэкапом (например, pg_dump) всё проще: данные расшифровываются при выгрузке. Если такой дамп сразу уходит с сервера, он останется рабочим, даже если потом шифровальщик срабаотает и расшифровку отключат. Моя агент не сможет обнаружить проблему заранее, но зато гарантирует работоспособность копии на момент атаки. То есть, вы не получите раннее предупреждение, но обеспечите непрерывность работы.
А вот с физическим бэкапом (pg_basebackup, снимки диска) вы абсолютно правы. Сырые данные копируются как есть, включая шифрование. Восстановление на заражённом сервере или его копии ничего не покажет, а проблема проявится только после отключения шифрования. В этом случае спасёт только восстановление на чистом сервере, отдельно от источника, а также отдельный контроль целостности данных.
Основная опасность исходит то вобщем даже не от шифровальщика на рабочем сервере. Страшно когда шифровальщик работает именно на устройствах хранения бэкапов. Тогда если какие либо повреждения рабочей базы имеют место, даже не по чьемуто злому умыслу а просто например по сбою железа, то можно оказаться у разбитого корыта. И обычно если проводится кибератака то она проводиться осознанно, комплексно и по всем направлениям и атакующие скорее всего знают где бэкапы и пытаются определить в каких случаях их расшифровывать а в каких нет. На самом деле судя по последним инцидентам в крупных компаниях, которые были под успешной атакой длительное время но смогли восстановить работу довольно таки оперативно, у хакеров пока не получается взять под контроль всю систему архивации но быть первым в списке тех кого всё таки развалили вдрызг как то не хочется)
PS недавно кстати гдето был пост про компании которые обанкротились и закрылись после атак но это было не в России а по моему в Германии и были они не очень большими
К слову, у borg есть встроенная возможность проверки.
.
С нетерпением жду возможности указывать локальный файл, чтобы можно было сразу после создания бэкапа его проверить на восстановление
pg_dump не спасает от ситуации описанной выше, когда архив был создан, а авария произошла спусти 6 часов. Случилась потеря данных. Почему нет непрерывного архивирования? Опять в статье указано, что есть реплика, с которой снимается dump. Если есть реплика, что мешает реализовать непрерывное архивирование?
Ага еще одна статья на тему важности бэкапа, риска потерь данных, которая рассказывает про .. pg_dump ) Минус автору
Вы правы: WAL архив и PITR уменьшают RPO, но не гарантируют что все восстановится. Повреждённый базовый бэкап или разорванный WAL делают всю схему бесполезной, поэтому правильный подход — регулярно автоматически поднимать базовый бэкап, накатывать WAL и проверять данные, что все ок.
Такая проверка у меня в планах, но сроков пока нет.
Ваш бэкап не восстановится. Вы просто ещё об этом не знаете