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