Резервная копия контейнера или файлов внутри? Решайте по форме восстановления

Можно сделать резервную копию зашифрованного контейнера как одного объекта, а можно смонтировать его и скопировать файлы внутри. Оба варианта спокойно проходят через VPN, и на этом сходство заканчивается. Они восстанавливают разное, зависят от разных ключей, занимают разный объём и отказывают по-разному, когда кому-то нужны данные обратно. Сначала выберите объект восстановления, затем транспорт, затем шифрование сохранённой копии. Чек-лист ниже идёт в этом порядке, потому что почти любой спор о резервных копиях — на самом деле спор о том, какое из этих трёх решений приняли первым.

Два объекта, две формы восстановления

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

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

Проверка 1: что восстановление должно реконструировать?

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

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

Решите и кто выполняет восстановление. Хранилище на уровне файлов, которое может смонтировать любой оператор, — иная модель доступа, чем образ, требующий присутствия владельца ключа, и ни одно из них не лучше автоматически. Важно, чтобы выбор был осознанным и записанным.

Проверка 2: что защищает сохранённую копию?

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

Для образа это значит защищать ключевой материал контейнера отдельно от самого образа. Потеря заголовка — потеря тома, поэтому делайте копию заголовка там, где образа нет:

cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20

Для хранилища на уровне файлов проверьте, что инструмент шифрует и аутентифицирует содержимое и метаданные до того, как они покинут хост, и выясните, у кого ключи. Документация по проектированию Restic прямо говорит, что предполагает доверенный исходный хост и что шифрование не мешает тому, у кого есть доступ к хранилищу, удалять копии. Обе оговорки важны: хранилище может быть конфиденциальным и при этом уничтоженным.

Проверка 3: согласована ли копия?

Копия, снятая с изменяющейся файловой системы, — это копия, а не точка восстановления. Для образа используйте поддерживаемый способ инструмента томов получить стабильный снимок, что обычно означает операцию снимка или отмонтирование, а не чтение большого файла, пока он меняется:

lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonly

Для смонтированных файлов используйте поддерживаемую приложением процедуру согласованности для работающих баз данных и других координируемых данных. Копия на уровне файловой системы и согласованная с приложением точка восстановления — разные описания, и разница становится заметной только когда вы пытаетесь запустить приложение из восстановленной копии.

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

Проверка 4: работает ли обнаружение изменений для этого объекта?

Зашифрованный контейнер выглядит для большинства инструментов передачи как один большой непрозрачный файл, поэтому небольшая правка открытого текста может вызвать большое повторное чтение или полную повторную загрузку в зависимости от инструмента и формата. Блочное деление переменного размера и дедупликация, как документирует restic, могут это уменьшить, но это свойство того инструмента, а не зашифрованных контейнеров вообще.

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

Затем завершите список единственным тестом, который имеет значение: восстановлением без исходной машины. Откройте восстановленный контейнер или восстановите выбранные файлы вместе с их метаданными и подтвердите, что приложение или пользователь может воспользоваться результатом. Быстрая и хорошо зашифрованная передача, которая не отвечает на этот тест, — копия ваших данных, а не их резервная копия.