Резервна копія контейнера чи файлів у ньому? Вирішуйте за формою відновлення

Можна зробити резервну копію зашифрованого контейнера як одного об'єкта, а можна змонтувати його й скопіювати файли всередині. Обидва варіанти спокійно проходять через 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, можуть це зменшити, але це властивість того інструмента, а не зашифрованих контейнерів загалом.

Міряйте, а не припускайте. Порівняйте перший прогін із другим після невеликої нешкідливої зміни та запишіть передані байти і витрачений час. Збережіть відомо добру копію під час експериментів, щоб тест не витратив вашу єдину точку відновлення.

Потім завершіть список єдиним тестом, що має значення: відновленням без початкової машини. Відкрийте відновлений контейнер або відновіть вибрані файли разом із їхніми метаданими й підтвердьте, що застосунок або користувач може скористатися результатом. Швидке й добре зашифроване передавання, яке не відповідає на цей тест, — копія ваших даних, а не їхня резервна копія.