С логическим бэкапом (например, pg_dump) всё проще: данные расшифровываются при выгрузке. Если такой дамп сразу уходит с сервера, он останется рабочим, даже если потом шифровальщик срабаотает и расшифровку отключат. Моя агент не сможет обнаружить проблему заранее, но зато гарантирует работоспособность копии на момент атаки. То есть, вы не получите раннее предупреждение, но обеспечите непрерывность работы.

А вот с физическим бэкапом (pg_basebackup, снимки диска) вы абсолютно правы. Сырые данные копируются как есть, включая шифрование. Восстановление на заражённом сервере или его копии ничего не покажет, а проблема проявится только после отключения шифрования. В этом случае спасёт только восстановление на чистом сервере, отдельно от источника, а также отдельный контроль целостности данных.

Что касается шифровальщика, есть два сценария, и они решаются по-разному:

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

2. Бэкапы уничтожают во время атаки. Здесь никакая проверка накануне не поможет. Спасут только неизменяемые и изолированные копии: S3 Object Lock, оффлайн-носители, отдельный аккаунт с другими ключами. Это дополнительная защита, которая нужна всегда, независимо от проверок.

Таким образом, проверка восстановлением помогает, когда «бэкап просто умер» (в том числе из-за злоумышленников), но не когда «всю инфраструктуру захватили». От этого защищают неизменяемость копий и сами тестовые прогоны .