Резервная копия после сбоя: неизменяемость, проверка данных и настоящее восстановление
Чем отличаются запрет удаления, soft delete, проверка структуры архива и извлечение файлов: конкретные механизмы AWS Backup, Azure Backup, restic и Borg.
Носитель и доверие к данным — разные вопросы
Восстановление после разрушительного события касается не только наличия файлов. NIST SP 1800-11 рассматривает целостность данных после ransomware, вредоносных действий, внутренних нарушений и обычных ошибок. Важны одновременно возвращение работоспособности и доверие к точности восстановленной информации. Документ опубликован в 2020 году; это не сообщение о новом инциденте или сегодняшней атаке.
Внешний диск, сетевое хранилище и ленточная библиотека описывают способ размещения данных, но сами по себе не подтверждают исправность конкретной копии. Иллюстрации показывают именно эти типы оборудования, а не сертификацию показанных моделей для какой-либо политики. Отдельно существуют правила сохранения, возможность удаления, доступность ключей и процедура извлечения. Даже технически читаемый архив может относиться к моменту, когда исходные данные уже были повреждены. Поэтому термины «копия существует», «копия не удаляется» и «получены пригодные данные» обозначают разные состояния. Ниже они разобраны на механизмах нескольких систем без предположения, что один продукт автоматически обеспечивает весь процесс.
Vault Lock ограничивает удаление
AWS Backup Vault Lock добавляет режим WORM для recovery points хранилища. Governance mode допускает снятие блокировки пользователями с достаточными IAM-правами. Compliance mode после завершения grace time становится неизменяемым: конфигурацию нельзя изменить или удалить, пока в vault остаются recovery points. Это более сильное условие, чем запрет кнопки удаления для обычного оператора.
Grace time задаёт период, когда параметры ещё можно исправить; минимальное значение — трое суток. После него блокировка не является настройкой, которую администратор просто выключит при неудобном результате. Сроки конкретных backup lifecycle также имеют значение. Минимальная и максимальная retention-политика vault не переписывает задним числом сроки уже существующих recovery points. Новые задания с несовместимыми сроками могут завершаться неуспешно. Защита от преждевременного удаления поэтому требует согласования с жизненным циклом данных. Она сохраняет копию, но не доказывает её содержательную корректность и не отменяет стоимость хранения до завершения удержания.
| Режим | Кто может снять блокировку | После grace time |
|---|---|---|
| Governance | Пользователь с достаточными IAM-правами | Не применяется compliance-неизменяемость |
| Compliance | В течение grace time изменение возможно | Блокировка неизменяема при наличии recovery points |
Источник: AWS: Vault lock modes
Soft delete сохраняет окно возврата
Azure Backup описывает soft delete как задержку окончательного удаления резервных данных. По умолчанию срок составляет четырнадцать дней; его можно расширить до ста восьмидесяти. После истечения применимого срока удаление становится окончательным. Это не та же модель, что бессрочная неизменяемость: механизм создаёт ограниченное время для возврата удалённого объекта.
Восстановление soft-deleted backup item возвращает его в состояние остановленной защиты с сохранёнными данными. После этого возможны дальнейшие restore-операции либо возобновление резервирования. Само возвращение объекта не означает, что приложение уже запущено из его содержимого. Документация отдельно разделяет Recovery Services vault и Backup vault, регионы общей доступности и preview; поэтому условия нельзя одинаково переносить на любой регион и тип хранилища. Для удержания сверх стандартного периода применяются дополнительные расходы. Срок, действовавший при удалении, определяет удержание данного объекта. Изменение настройки позже не следует воспринимать как автоматический пересчёт уже начавшегося периода для каждой старой записи.
Что именно проверяет restic check
У restic проверка репозитория по умолчанию не читает все pack files для подтверждения неизменности их содержимого. Опция read-data добавляет такую проверку. Это принципиальная разница между быстрым контролем структуры и полным чтением массива данных: сообщение об успешной обычной проверке нельзя расширять до утверждения, что каждый сохранённый блок был заново прочитан.
Полное чтение требует времени и, при удалённом репозитории, сетевого трафика. Для частичного контроля предусмотрен read-data-subset. Подмножество можно задать как одну из логических долей либо выбрать случайную часть по объёму или проценту. Последовательный обход заранее определённых долей и многократная случайная выборка имеют разные свойства покрытия. Документация прямо отмечает, что случайные выборки не гарантируют проверки каждого файла даже после многих запусков. Это не делает выборочный контроль бесполезным, но ограничивает смысл результата. Проверка конкретного подмножества свидетельствует о проверенных объектах, а не создаёт доказательство целостности всей истории репозитория.
Borg различает репозиторий, архив и содержимое
borg check проверяет согласованность репозитория и архивов. Первый уровень рассматривает сегменты, размеры и контрольные суммы; другой — метаданные архивов и существование объектов, на которые они ссылаются. Для криптографической проверки содержимого используется verify-data, требующая чтения, расшифровки и распаковки данных.
При удалённом репозитории место выполнения тоже различается. Проверка репозитория работает на сервере, а проверка архивов выполняется клиентом, поскольку требует расшифровки и ключа. Ограничение max-duration позволяет разбивать часть работы на несколько запусков, но такие частичные проверки не равнозначны полному набору проверок архивных данных. Документация отдельно ограничивает совместимость режимов. По умолчанию check является операцией чтения; repair уже пытается менять повреждённые структуры. Borg прямо предупреждает о потенциальной потере дополнительных данных при repair. Следовательно, диагностическое сообщение и восстановительная мутация — не одна команда с разной степенью подробности. Автоматическое добавление режима исправления существенно меняет риск операции и возможный результат для исходного репозитория.
Извлечение файлов — ещё один самостоятельный этап
restic restore выбирает snapshot и целевое расположение. Восстановление поверх существующего каталога имеет собственную политику overwrite. По умолчанию уже существующие файлы могут перезаписываться; доступны варианты, ориентированные на изменение, более новое время или полный запрет перезаписи. Эти режимы описывают конфликт в целевом каталоге, а не качество самого snapshot.
Документация предупреждает, что прерванное in-place-восстановление способно оставить частично изменённое состояние. Dry run показывает предполагаемые действия без выполнения полного restore, но не заменяет само извлечение данных. Отдельная delete-настройка относится к объектам, которых нет в выбранном snapshot, и потому меняет смысл операции: это уже не простое добавление найденных файлов. Наличие читаемого архива, успешная диагностика репозитория и полученный каталог с восстановленным содержимым являются отдельными результатами. После извлечения остаётся вопрос соответствия выбранной версии нужному моменту и структуры файлов ожиданиям конкретного приложения. Универсального подтверждения этого прикладного соответствия одна команда проверки хранилища не выдаёт.
Восстановление допускает выбор отдельных путей и фильтров содержимого. Это позволяет описать ограниченный набор извлекаемых файлов, а не обязательно разворачивать весь снимок. Но даже небольшой выбранный набор сохраняет собственные условия конфликта с уже существующим содержимым целевого каталога.
