Сохранность и восстановление данных

В теме 2 был сформирован офлайн-профиль узла и рассмотрены физические типы носителей — от жестких дисков до твердотельных накопителей и оптических дисков M-DISC. В теме 7 развернута автономная операционная система и выстроена цепочка доверенных обновлений, а в теме 8 запущены базовые сервисы: локальный резолвер имен, офлайн-библиотека знаний Kiwix и версионный контроль. До сих пор предполагалось, что накопитель информации исправен, файловая система находится в согласованном состоянии, а файлы, записанные вчера, будут прочитаны сегодня. В условиях автономной эксплуатации это предположение ложно.

Автономный узел функционирует в неблагоприятной физической среде: питание от нестабилизированной шины постоянного тока или генератора (темы 3 и 5) чревато внезапными отключениями под нагрузкой; перепады температур и влажность ускоряют деградацию электронных компонентов; отсутствие запасных деталей исключает оперативную замену вышедшего из строя SSD или жесткого диска. При этом потеря данных в изоляции носит необратимый характер: здесь нет облачного хранилища, из которого можно заново загрузить репозиторий, и нет службы технической поддержки производителя.

В этой теме решаются три взаимосвязанные инженерные задачи. Во-первых, построение модели отказов данных: от механического износа и тихой порчи секторов до повреждения метаданных файловой системы и непреднамеренных ошибок оператора. Во-вторых, организация циклического резервного копирования с дедупликацией, шифрованием и обязательной процедурой инструментальной верификации архивов. В-третьих, освоение процедур низкоуровневого восстановления поврежденных накопителей: посекторное спасение через карту проходов ddrescue, реконструкция разметки диска, задействование резервных суперблоков ext4 и защита криптографических заголовков LUKS2.

Модель угроз и отказов данных

Механические и электронные отказы накопителей

Любой накопитель информации представляет собой совокупность механических узлов, полупроводниковых структур и микроконтроллера, исполняющего внутреннюю микропрограмму (прошивку, англ. firmware) ¹. Отказ накопителя может произойти на каждом из этих слоев.

В магнитных жестких дисках (англ. Hard Disk Drive, HDD) механические дефекты вызваны износом подшипников шпинделя или повреждением блока магнитных головок (англ. Head Stack Assembly, HSA). При внезапном падении ноутбука во время записи вращающегося диска головка, летящая над пластиной на высоте в единицы нанометров, соприкасается с магнитной поверхностью. Происходит физический запил пластины (англ. head crash), приводящий к лавинообразному истиранию магнитного слоя и физическому уничтожению данных в зоне соударения ². Электронная плата HDD (англ. Printed Circuit Board, PCB) уязвима к броскам напряжения: при аварии бортовой шины питания (тема 3) защитные TVS-диоды (англ. Transient Voltage Suppressor) пробиваются накоротко, предотвращая возгорание микросхем, но блокируя запуск накопителя.

В твердотельных накопителях (англ. Solid-State Drive, SSD) и картах microSD отсутствуют подвижные механические части, однако проявляются специфические физические ограничения полупроводниковой структуры NAND Flash ³. Хранение информации основано на удержании электрического заряда в плавающем затворе (англ. floating gate) или нитридной ловушке (англ. charge trap) транзистора. Изолирующий диэлектрический слой туннельного оксида деградирует с каждым циклом программирования и стирания (англ. Program/Erase cycle, P/E cycle). У многоуровневых ячеек TLC и QLC ресурс меньше, чем у SLC и MLC; для конкретного накопителя он задаётся в паспорте как допустимый объём записи (TBW) ³.

Второе фундаментальное ограничение Flash-памяти в условиях изоляции — деградация заряда при хранении в обесточенном состоянии (англ. data retention). Утечка заряда ускоряется с ростом температуры (модель Аррениуса) и с износом ячеек. Нормативная точка отсчёта — стандарт JEDEC JESD218: клиентский SSD, выработавший заявленный ресурс записи, должен сохранять данные без питания 1 год при +30 °C (C-09-07: 1 год) ¹³. Это требование к изношенному накопителю на границе ресурса; у нового накопителя запас больше, при хранении в тепле — меньше. Для автономного узла вывод прямой: SSD и флеш-карты, лежащие без питания как третья копия, раз в несколько месяцев подключают и полностью перечитывают (restic check --read-data или сверка SHA-256), чтобы контроллер обновил ослабевшие ячейки.

Логическая порча файловых систем и сбои питания

Даже при полностью исправном физическом носителе данные могут быть утрачены вследствие разрушения логической структуры файловой системы (ФС). Основной источник такой порчи в автономных системах — внезапное аварийное отключение электропитания (англ. power-cut event) в момент дисковой активности ⁴.

Операционная система не сбрасывает данные на носитель мгновенно: в целях оптимизации производительности ядро Linux кэширует операции записи в оперативной памяти (страничный кэш, англ. page cache), сбрасывая их пачками по таймауту фонового демона kworker (параметры dirty_expire_centisecs и dirty_writeback_centisecs). Если питание исчезает в момент, когда изменены таблицы размещения файлов, но сами блоки данных еще не записаны на диск, файловая система оказывается в несогласованном состоянии.

Современные файловые системы (ext4, XFS) используют механизм журналирования (англ. journaling). Перед внесением изменений в основные метаданные ядро записывает атомарную транзакцию в специальную область — журнал (в ext4 за это отвечает подсистема JBD2 — Journaling Block Device) ⁴. Интервал фиксации транзакций JBD2 в ядре Linux по умолчанию составляет 5 с (опция монтирования commit=5, утверждение C-09-01 [Ц]), что определяет окно уязвимости незафиксированных изменений при внезапном сбросе питания. Если система обесточивается во время транзакции, при следующем монтировании журнал воспроизводится (англ. journal replay), откатывая незавершенные операции. Однако журналирование защищает исключительно целостность метаданных (при стандартном режиме data=ordered), но не защищает содержимое самих файлов: открытый файл, в который производилась запись, может оказаться заполнен нулевыми байтами или содержать фрагменты старых блоков.

Более того, контроллеры потребительских дисков SSD и накопителей USB/microSD в целях поддержания высокой паспортной скорости подтверждают операционной системе выполнение системного вызова flush (fsync) до того, как заряд ячеек Flash физически зафиксирован в энергонезависимых массивах. При пропадании шины 12/5 В суперконденсаторы, обеспечивающие аварийный сброс буфера (англ. Power Loss Protection, PLP), присутствуют только в дорогостоящих серверных SSD; потребительские накопители при резком обесточивании теряют данные из внутренней DRAM контроллера, что приводит к повреждению внутренних таблиц трансляции адресов LBA-в-Flash (Flash Translation Layer, FTL). В результате SSD перестает распознаваться в BIOS либо отображает нулевую емкость ³.

Скрытая деградация секторов и лимиты износа flash-памяти

Коварная форма повреждения информации — так называемая тихая порча данных (англ. silent data corruption или bit rot) ⁵. Это явление выражается в спонтанном изменении значений отдельных бит в секторе накопителя без генерации ошибки со стороны контроллера в момент чтения или записи.

Причины тихой порчи:

1. Фоновая радиация и космические лучи, вызывающие переброс заряда в ячейках DRAM кэша накопителя или ячейках Flash.
2. Дефекты чтения соседних дорожек магнитных дисков (англ. track crosstalk) или перетекание заряда между соседними изолированными затворами в ячейках 3D NAND (англ. read disturb).
3. Ошибки прошивки контроллера при фоновом уплотнении блоков (англ. garbage collection).

При чтении сектора с битыми битами контроллер задействует алгоритмы помехоустойчивого кодирования (ECC — коды Рида-Соломона или LDPC). Если число ошибочных бит в секторе превышает корректирующую способность кода (у LDPC в современных SSD она зависит от конкретного контроллера и не публикуется в общем виде), контроллер возвращает ошибку ввода-вывода (англ. Uncorrectable ECC error, UNC sector). Если же ошибка попадает в редкую категорию ложного декодирования (англ. miscorrection), контроллер выдает поврежденные данные как валидные. Традиционные файловые системы (ext4, XFS) не хранят контрольных сумм блоков данных и не способны обнаружить факт порчи прикладного файла.

Распространенное заблуждение операторов заключается в убеждении, что аппаратный или программный RAID-массив (например, зеркало RAID-1) гарантирует сохранность данных. Это не так:

• RAID защищает от механического отказа одного из дисков, но не защищает от логической порчи: если ошибка транзакции или вирус стирает файл, команда удаления мгновенно транслируется на оба диска массива.
• RAID не предотвращает распространение поврежденных метаданных.
• При тихом искажении блока на одном из дисков RAID-1 без сквозных контрольных сумм контроллер не знает, какая из двух копий истинна, и может перезаписать валидный блок поврежденным. Следовательно, отказоустойчивые массивы обеспечивают исключительно высокую доступность сервиса (англ. availability), но не заменяют регулярного резервного копирования ⁶.

Человеческий фактор и ошибки оператора

Ошибка человека — отдельный класс отказа, от которого не защищают ни RAID, ни контрольные суммы: команда удаления выполняется так же надёжно, как любая другая ⁵. Доля таких потерь в чужой статистике здесь не приводится — на автономном узле она определяется усталостью и составом группы, а не отраслевым средним. В автономном узле оператор совмещает роли системного администратора, инженера по питанию и радиста.

Типовые критические ошибки оператора:

1. Выполнение деструктивных команд оболочки с повышенными привилегиями: непреднамеренное удаление рабочего каталога rm -rf /var/log/ .. вместо rm -rf /var/log/../*, опечатка в пути к целевому блочному устройству в утилите dd (of=/dev/sda вместо of=/dev/sdb), форматирование рабочего раздела командой mkfs.
2. Некорректное извлечение внешних накопителей информации: отсоединение USB-диска или microSD без предварительного размонтирования (umount) и синхронизации буферов ядра (sync).
3. Случайная перезапись криптографических заголовков при установке ОС или разметке новых дисков через parted/fdisk.
4. Игнорирование предупреждений системного журнала и показателей SMART о деградации носителя до момента полной потери доступа к данным.

Защита от человеческого фактора строится не на призывах к внимательности, а на технических барьерах: монтировании архивных разделов в режиме «только чтение», отказе от постоянной работы под учетной записью root, наличии обязательных паритетных архивов (par2, тема 2) и неизменяемых (англ. append-only) репозиториев резервных копий.

Классификация критичности и приоритизация восстановления

Три категории данных автономного узла

Ресурс накопителей, объем свободной емкости и суточный запас электроэнергии на изолированном узле жестко ограничены (темы 1 и 3). Попытка непрерывно резервировать абсолютно все файлы узла приведет к быстрому исчерпанию дискового пространства и повышенному расходу аккумуляторов на дисковый ввод-вывод. Необходима строгая дифференциация информации по степени критичности.

Все данные автономного узла разделяются на три непересекающиеся категории, образующие пирамиду приоритетов защиты:

Потеря данных категории 1 необратима: они сгенерированы локально на данном узле и не могут быть восстановлены ни из каких внешних источников. Потеря Категории 2 приводит к значительному увеличению времени восстановления системы (RTO), заставляя оператора вручную перенастраивать сервисы с нуля. Данные Категории 3 имеют максимальный физический объем (десятки и сотни гигабайт), однако при необходимости могут быть запрошены по радиоканалу в виде выжимок (тема 10) либо доставлены на физическом носителе с соседнего узла (тема 2).

Назначение RTO и RPO по классам данных

Как определено в теме 1, целевое время восстановления (RTO) задаёт допустимую длительность простоя сервиса, а целевая точка восстановления (RPO) — предельно допустимый возраст потерянных данных ⁶. RPO категорий привязаны к сценариям темы 1: в сценарии А (4 ч, связь есть) достаточно RPO категории 1 — часовой копии; в сценарии Б (72 ч, −20 °C) суточная копия категории 2 должна быть сделана до начала сценария; в сценарии В (336 ч автономии) месячный цикл категории 3 означает, что обновления архивов за время сценария не будет вовсе, и это допустимо; в сценарии Г копии на отчуждённом носителе — единственное, что переживает потерю узла.

В таблице представлено сопоставление категорий данных с параметрами непрерывности и требуемыми стратегиями резервирования для условий длительной автономии:

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

Изоляция повреждения и перевод в режим «только чтение»

Первое правило инженера при обнаружении признаков порчи данных: немедленно остановить любую запись на подозрительный накопитель ⁷. Продолжение работы штатной ОС на поврежденном носителе гарантирует усугубление аварии: фоновые процессы ядра, ротация логов systemd-journald и временные файлы каталога /tmp начнут перезаписывать метаданные, разрушая следы удаленных файлов и структуру поврежденных каталогов.

Процедура локализации сбоя:

# 1. Срочный перевод поврежденного раздела в режим read-only
mount -o remount,ro /dev/sdb1

# 2. Если файловая система заблокирована открытыми дескрипторами процессов:
lsof +D /mnt/storage
fuser -mk /mnt/storage
umount /mnt/storage

Если размонтировать раздел стандартным способом невозможно из-за зависания системных вызовов в ядре (состояние процесса D — uninterruptible sleep), прибегают к экстренному сбросу кэша и перемонтированию всех файловых систем через интерфейс Magic SysRq (Documentation/admin-guide/sysrq.rst в исходниках ядра) ⁷:

# Синхронизация буферов (Sync)
echo s > /proc/sysrq-trigger

# Перевод всех смонтированных ФС в режим read-only (uMount ro)
echo u > /proc/sysrq-trigger

После перевода накопителя в режим ro физический диск отключается от питания. Дальнейшие спасательные операции производятся исключительно на стендовой машине с использованием аппаратного блокиратора записи или монтирования виртуального образа через loop-устройство с флагом -r.

Стратегии резервного копирования на изолированном узле

Полные копии, инкременты и блочные снапшоты

Существуют три классических подхода к формированию резервных копий ⁶ (рисунок):

1. Полная копия (англ. full backup): создание исчерпывающего слепка всех выбранных файлов. Преимущество — максимальная простота и независимость восстановления: для развертывания требуется единственный архив. Недостатки — экстремальная избыточность, длительное время выполнения и высокий расход энергии на перезапись гигабайтов неизменившихся файлов.
2. Дифференциальная копия (англ. differential backup): сохранение только тех файлов, которые были созданы или изменены с момента создания последней полной копии. Объем архива растет линейно со временем, прошедшим с базового бэкапа.
3. Инкрементная копия (англ. incremental backup): сохранение только тех блоков или файлов, которые изменились с момента создания предыдущей (любой) резервной копии. Объем каждого инкремента минимален. Недостаток традиционного файлового инкремента — длина цепочки восстановления: при повреждении одного промежуточного инкремента все последующие становятся нечитаемыми.

В современных автономных системах файловый инкремент вытеснен блочными снапшотами с адресацией по содержимому (англ. content-addressable storage, CAS) ⁸. Каждый файл разбивается на блоки; имя каждого блока вычисляется как криптографический хэш (SHA-256) от его содержимого. Если блок с таким хэшем уже присутствует в репозитории, он не сохраняется повторно. В результате каждая резервная копия логически выглядит для пользователя как полная (доступно полное дерево каталогов на конкретный момент времени), но физически на диске сохраняются только новые уникальные блоки.

Дедупликация с переменным размером блока

Примитивные алгоритмы дедупликации разбивают файлы на блоки фиксированного размера (например, 64 КБ). Этот подход терпит крах при модификации потоковых данных: если в начало файла базы данных SQLite или конфигурационного файла вставить один байт, границы всех последующих 64-килобайтных блоков сдвинутся на 1 байт. Хэш каждого блока изменится, и дедупликация не сработает — весь файл будет сохранен повторно в полном объеме.

Продвинутые утилиты (restic, borgbackup) используют дедупликацию с плавающим окном и переменным размером блока (англ. variable-size chunking) на основе хэширования Рабина или скользящего полиномиального хэша (Buzhash / CDC — Content-Defined Chunking) ⁸.

Алгоритм перемещает скользящее окно фиксированной ширины (например, 64 байта) по потоку данных байт за байтом, вычисляя контрольное значение полинома:

H = \sum_{i=0}^{W-1} b_i \cdot p^{W-1-i} \pmod M

Граница блока объявляется в тот момент, когда младшие k бит вычисленного хэша H равны нулю (то есть H \pmod{2^k} = 0). Вероятность совпадения составляет 1/2^k, что обеспечивает средний целевой размер блока \bar{S} = 2^k (в restic блоки имеют размер от 512 КиБ до 8 МиБ, в среднем около 1 МиБ, по описанию формата репозитория ¹⁴). При вставке байта в начало файла сдвигается граница только первого блока; как только скользящее окно доходит до следующей характерной сигнатуры содержимого, синхронизация границ блоков восстанавливается, и все последующие блоки файла совпадают с уже сохранёнными и повторно не записываются ⁸.

Сравнение инструментов: restic, borg, rsync

В таблице представлен сравнительный анализ утилит резервного копирования применительно к ограничениям автономного узла (одноплатные компьютеры ARM, медленные накопители USB 2.0, отсутствие сетевого демона на стороне хранилища):

Сведения о шифровании и сжатии — по документации borg (borgbackup.readthedocs.io, раздел «Security») и restic ¹⁴. Различие версий borg существенно: репозиторий borg 2.x не читается borg 1.4, и версия инструмента записывается в паспорт копии вместе с паролем. Потребление памяти обоими инструментами растёт с числом блоков в репозитории (индекс блоков держится в памяти); для своего репозитория оно измеряется (/usr/bin/time -v restic backup …, строка «Maximum resident set size»), а не берётся из обзоров.

Вывод для автономного узла: restic удобен тем, что это один статический файл — его можно положить на тот же носитель, что и копию, и восстановить данные с живой системы без установки пакетов. Шифрование в нём не отключается, поэтому незашифрованную копию по ошибке не сделать; обратная сторона — потеря пароля означает потерю копии (раздел о ключах).

Неизменяемые репозитории и правило трёх копий в офлайне

Распространённое эмпирическое правило «3-2-1» требует три копии данных на двух разных типах носителей, одна из них — в другом месте. В автономии его приходится переводить на язык доступного:

• Копия 1 — рабочий накопитель узла.
• Копия 2 — локальный резервный носитель (внешний HDD, вторая карта памяти), подключённый постоянно или по таймеру.
• Копия 3 — отчуждаемый носитель, который после записи физически отключается и хранится в другом помещении (защита от пожара, воды, перенапряжения — тема 12), либо репозиторий на втором узле Полигона.

Копия, которую можно стереть с того же узла, не защищает от ошибки оператора и вредоносной программы на узле: удаление restic forget --prune с узла сотрёт и её. Защита — хранилище, которое принимает только добавление. Для restic это rest-server --append-only на другой машине: сервер принимает новые блоки и снимки, но отвергает удаление и перезапись, а очистку старых снимков выполняет администратор хранилища на самом хранилище ¹⁴. Флаг chattr +a на каталоге репозитория для этого не годится: он требует root, а restic при каждой операции создаёт и удаляет lock-файлы, поэтому с таким флагом репозиторий перестаёт работать. Опыт ЛР 9 (часть 4) проверяет, что forget --prune через append-only сервер действительно отвергается.

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

Синхронизация — не резервная копия

Синхронизация (Syncthing, rsync --delete, тема 11) поддерживает одинаковое состояние двух мест — и потому за секунды разносит удаление или порчу файла на все узлы. Резервная копия хранит состояние на моменты времени и позволяет вернуться назад. Механизмы родственные: Syncthing тоже делит файлы на блоки и передаёт только изменённые, но блоки у него фиксированного размера, привязанные к смещению в файле, а не к содержимому, как CDC у restic и borg; вставка байта в начало файла заставляет Syncthing передать файл заново, а restic — сохранить один новый блок. Синхронизация закрывает отказ узла (данные есть на соседнем), резервная копия — ошибку человека и порчу; на автономном Полигоне нужны обе. Резервное копирование баз данных (дампы, журналы транзакций, согласованные снимки) — курс «Базы данных», тема 13; здесь — файлы и носители.

Шифрование копий и хранение ключей

Копия, которая уносится из узла, шифруется: она может быть потеряна или украдена вместе с носителем. restic и borg шифруют сами. Для отдельных файлов и архивов tar используются age (ключи X25519, один короткий файл ключа, age -r <открытый ключ> -o arch.tar.age arch.tar) или GPG (gpg --encrypt -r <ключ>). Открытым ключом шифрует узел; закрытый ключ на узле не хранится, поэтому взлом узла не раскрывает старые копии.

Ключи хранятся отдельно от копий и отдельно друг от друга: пароль restic — в файле на узле и на бумаге в профиле (тема 2), закрытый ключ age — на отдельном носителе в опечатанном конверте. Восстановление ключей — отдельный объект проектирования: при отсутствии всех копий ключа расшифровка не предполагается, и это свойство шифрования, а не недостаток процедуры. Поэтому учебное восстановление (ниже) начинается с вопроса «где ключ» и проверяет, что ключ из профиля действительно открывает копию.

Полный снимок файловой системы: zfs send и tar

Для ZFS и Btrfs резервная копия может быть снимком всей файловой системы: zfs snapshot pool/data@d1, затем zfs send pool/data@d1 > /mnt/backup/data-d1.zfs (полный) или zfs send -i @d1 pool/data@d2 (приращение между снимками); на другой машине поток принимается zfs receive. Аналог в Btrfs — btrfs send/btrfs receive. Преимущество — согласованное состояние на один момент времени и скорость; недостаток — поток читается только той же файловой системой, а повреждение одного байта в файле потока делает его непринимаемым целиком, поэтому такие файлы хранят с par2 (тема 2). Самый переносимый формат — tar (с --xattrs --acls, если нужны права и атрибуты): он читается любой системой десятилетиями, но не дедуплицирует и не шифрует сам.

Процедура верификации и учебное восстановление

Принцип непроверенного бэкапа

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

Попытка опереться на факт успешного завершения команды restic backup без регулярной пробной распаковки данных приводит к катастрофическим последствиям:

1. Ключ шифрования может быть утерян или поврежден, делая расшифровку невозможной.
2. Файлы баз данных могут быть скопированы в момент незавершенной транзакции (грязное чтение), в результате чего поднятая СУБД откажется открывать поврежденный файл .db.
3. Резервный носитель может иметь скрытые повреждения секторов в области хранения свежих снапшотов.
4. Конфигурационные файлы могут восстанавливаться с нарушенными правами доступа (chmod 777 или смена владельца с uid 0 на uid 1000), из-за чего сервис не запустится.

Контрольные суммы, паритет и аудит репозитория

Верификация резервного хранилища подразделяется на структурную проверку целостности архива и поблочное контрольное чтение данных ⁸.

В restic регулярный аудит выполняется двухэтапно:

# Этап 1: структурная проверка индексов и деревьев снимков (секунды)
restic check --repo /mnt/backup_drive/repo

# Этап 2: чтение и проверка SHA-256 части блоков данных: n-я десятая часть
restic check --repo /mnt/backup_drive/repo --read-data-subset=3/10

Ключ --read-data-subset=n/10 проверяет n-ю из десяти фиксированных частей репозитория; если таймер при каждом запуске берёт следующую часть, за 10 запусков прочитан весь репозиторий ¹⁴. Вариант с процентом (--read-data-subset=10%) выбирает части случайно и полного обхода за 10 запусков не гарантирует. Для репозитория 50 ГБ на носителе со скоростью 80 МБ/с один запуск читает 5 ГБ и занимает 0,017 ч, около минуты (C-09-10: 0,017 ч; расчёт storage.py), — это нагрузка, которую можно планировать по энергобалансу темы 3, а не «пиковая».

Для монолитных файлов (образы ОС, ZIM-архивы) копии дополняются кодами Рида — Соломона утилитой par2 (тема 2). Арифметика par2 (par2cmdline 0.8): файл делится на 2000 исходных блоков, каждый блок восстановления заменяет один любой повреждённый исходный блок. Для файла 10 МБ при избыточности 5 % блок равен 5000 байт, и создаётся 100 блоков восстановления (C-09-08: 100 блоков; расчёт storage.py). Гарантированно исправим непрерывный повреждённый участок длиной до (100 − 1) · 5000 + 1 = 495 001 байт; участок длиннее при неудачном выравнивании задевает 101 блок и уже не исправим. Опыт «повреждение сверх паритета» — ЛР 2.

# Создание 5% паритета для аварийного архива
par2create -r5 -n1 emergency_archive.tar.gz.par2 emergency_archive.tar.gz

# Верификация и восстановление поврежденного файла
par2repair emergency_archive.tar.gz.par2

Регламент учебного восстановления (restore drill)

Учебное восстановление (англ. restore drill) — обязательная регулярная инженерная процедура, проводимая оператором по расписанию (раз в квартал в сценарии длительной автономии, тема 13) ⁶.

Цель учения — замерить фактический хронометраж полного восстановления узла «на холодную» и подтвердить выполнимость требований RTO.

Регламент проведения тренировки:

1. Развертывание в чистой виртуальной машине QEMU или в изолированном сетевом пространстве имен unshare -rnm (без доступа к рабочей системе).
2. Монтирование резервного репозитория restic.
3. Выполнение команды полного восстановления целевого снапшота:

   restic restore latest --repo /mnt/backup_drive/repo --target /tmp/drill_root
   

4. Запуск проверочного скрипта валидации контрольных сумм: sha256sum -c reference.sha256.
5. Тестовый запуск ключевых демонов (unbound, dnsmasq, HTTP-сервер Kiwix) внутри изолированного корня через chroot с проверкой генерации валидных ответов на сетевые запросы.
6. Фиксация результатов тренировки в журнале обслуживания узла: дата, идентификатор снапшота, затраченное время (минуты), объем восстановленных байт, подпись оператора.

Журнал ведётся и для неуспешных восстановлений, и они в нём важнее успешных. Каждая запись: дата, что восстанавливали, из какой копии, на каком шаге остановились, причина (нет ключа, копия не читается, восстановленный сервис не стартует из-за отсутствующего файла вне копии) и что изменено в процедуре. Неуспешное учебное восстановление — найденная ошибка в схеме копирования, обнаруженная тогда, когда её ещё можно исправить; запись о ней превращается в пункт регламента. Журнал хранится рядом с регламентом в профиле узла (тема 2) и пересматривается на учениях (тема 13).

Низкоуровневая диагностика и восстановление носителей

Диагностика SMART и скрытые дефекты

Технология самоконтроля, анализа и отчетности (англ. Self-Monitoring, Analysis and Reporting Technology, SMART) встроена в контроллеры всех современных жестких дисков и SSD ¹. Опрос регистров SMART утилитой smartctl пакета smartmontools позволяет зафиксировать деградацию носителя задолго до того, как он полностью перестанет определяться операционной системой.

Команда полного считывания журнала SMART:

smartctl -a /dev/sdb

В выводе утилиты критическое значение имеют пять нормализованных атрибутов HDD:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   0
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   12
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   12

Интерпретация критических счетчиков:

• 5 (Reallocated_Sector_Ct): количество секторов, признанных дефектными и переназначенных во внутреннюю резервную дорожку (англ. spare area). Если RAW_VALUE больше нуля, поверхность пластины начала разрушаться.
• 197 (Current_Pending_Sector): «сектора-кандидаты» — нестабильные блоки, ожидающие переназначения после неудачной попытки чтения. При чтении такого сектора контроллер диска зависает на 5–30 секунд, пытаясь применить многократные повторы чтения с микрошаговым смещением позиционера магнитных головок.
• 198 (Offline_Uncorrectable): число секторов, чтение которых завершилось фатальной нескорректированной ошибкой при фоновом сканировании поверхности.

Для SSD первостепенными метриками являются 05 (Reallocated Flash Blocks), 177 (Wear Range Delta) и 231 (SSD Life Left): если процент оставшегося ресурса приближается к нулю, ячейки теряют способность удерживать заряд, и накопитель подлежит немедленному выводу из эксплуатации.

Посекторное копирование ddrescue и карта mapfile

Когда диск начинает возвращать ошибки чтения (UNC) и зависать по тайм-аутам шины, обычные программы копирования не годятся ⁹. cp останавливается на первой ошибке. dd conv=noerror,sync продолжает, но читает по порядку и каждый сбойный сектор пробует столько раз, сколько повторит ядро, — накопитель тратит время на зоны, где данных уже не получить, вместо того чтобы сначала забрать исправное.

GNU ddrescue решает эту задачу иначе: читает сначала то, что читается легко, а к сбойным зонам возвращается потом, и ведёт карту (англ. mapfile), где для каждого участка записан его статус. Карта позволяет прервать работу (накопитель отвалился, кончилась энергия) и продолжить с того же места той же командой.

По руководству GNU ddrescue 1.30 (раздел «Algorithm») работа идёт в пять фаз ⁹:

1. Копирование (copying). До четырёх проходов крупными блоками по нечитанным участкам (?, non-tried). Блок, при чтении которого произошла ошибка, помечается * (non-trimmed, «края не обрезаны»), и ddrescue перескакивает дальше. Второй проход идёт в обратном направлении и очерчивает пропущенные участки с другой стороны. Цель фазы — быстро забрать основную массу исправных данных.
2. Обрезка (trimming). Для каждого блока * ddrescue читает по одному сектору от переднего края, пока не встретит сбойный, затем так же от заднего края. Найденные сбойные сектора получают статус - (bad-sector), середина блока — / (non-scraped).
3. Прочёсывание (sweeping). Нечитанные участки, пропущенные при копировании, читаются без пропусков. Отключается ключом -N (--no-sweep).
4. Выскабливание (scraping). Каждый блок / читается по одному сектору вперёд; несчитанные сектора становятся -. Фаза пропускается ключом -n (--no-scrape) — именно это, а не «копирование без деления блоков», означает -n.
5. Повторы (retrying). Только если задан -r N (--retry-passes): каждый сектор - пробуется ещё N раз, направление меняется после каждого прохода.

Прочитанные участки получают статус + (finished). Первая содержательная строка карты — статус всей работы: позиция, текущая фаза (? копирование, * обрезка, % прочёсывание, / выскабливание, - повторы, + готово) и номер прохода. Каждый сектор, по руководству, пробуется не больше двух раз до фазы повторов: в составе крупного блока и затем поодиночке.

Типовой порядок работы с неисправным диском — два запуска с одной картой:

# 1. Забрать исправное быстро: без выскабливания
ddrescue -d -n /dev/sdb rescued.img rescue.map
# 2. Если время и состояние диска позволяют: выскабливание и три прохода повторов
ddrescue -d -r3 /dev/sdb rescued.img rescue.map

Ключ -d (прямой доступ, мимо кэша ядра) нужен на настоящем блочном устройстве; на файле-образе он не применяется. Неисправный диск при этом подключается только для чтения и только к машине восстановления; всё дальнейшее делается с образом.

Числовой пример: время снятия образа

Оценим время снятия образа с диска 500 ГБ при скорости чтения 80 МБ/с и 120 сбойных секторах, собранных в 10 зон по 12 секторов. Каждая неудачная попытка чтения стоит 7 с — столько накопитель с настройкой SCT ERC 70 (так smartctl(8) описывает типичное значение для RAID) пытается прочитать сектор, прежде чем вернуть ошибку; у настольного диска без ERC эта величина больше и задаётся прошивкой.

Исправная поверхность читается за T = V / S = 500 · 10⁹ / 80 · 10⁶ = 6250 с, то есть 1,74 ч (C-09-02: 1,74 ч; расчёт storage.py). Добавку на сбойных зонах storage.py считает по фазам ddrescue:

С ключом -n работа заканчивается после обрезки: 6250 + 140 + 140 = 6530 с, или 1,81 ч (C-09-03: 1,81 ч), и при этом скопировано всё, кроме 120 · 512 = 61 440 байт сбойных зон. Полный проход с выскабливанием и тремя повторами — 9750 с, 2,71 ч (C-09-04: 2,71 ч): последние 0,9 ч тратятся на эти 60 КБ. Для сравнения, dd bs=512 conv=noerror читает сбойные сектора по порядку, и ядро на каждый делает до пяти повторов (SD_MAX_RETRIES в drivers/scsi/sd.h); добавка — 5040 с (C-09-05: 5040 с), причём исправные данные за сбойной зоной dd получает только после неё.

Вывод для автономного узла: если энергии или ресурса диска хватает на два часа, первый запуск с -n забирает практически всё за 1,81 ч, а решение тратить ли ещё 0,9 ч на 60 КБ принимается отдельно, зная, какие файлы в этих секторах лежат (ЛР 9, часть 2).

Восстановление таблиц разделов и поиск файлов по сигнатурам

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

Если разрушена таблица разделов (MBR или GPT), ядро не видит границ файловых систем, хотя сами они целы. Порядок действий — от простого к сложному.

1. Резервная копия таблицы. Если она сделана заранее (sfdisk --dump /dev/sdb > table.dump, для GPT — sgdisk --backup=table.gpt /dev/sdb), таблица возвращается одной командой: sfdisk /dev/sdb < table.dump или sgdisk --load-backup=table.gpt /dev/sdb. Копия таблиц разделов всех дисков узла — часть профиля (тема 2); она занимает сотни байт.
2. Вторая копия GPT. GPT хранит копию заголовка и таблицы в последних секторах диска; при порче начала sgdisk -e и gdisk (команда восстановления b/c) восстанавливают основную копию из резервной. Таблица MBR такой копии не имеет.
3. Поиск разделов по сигнатурам. testdisk сканирует образ и ищет начала файловых систем по характерным признакам: у ext2/3/4 — суперблок с «магическим числом» 0xEF53 по смещению 56 от начала суперблока, то есть 1080 байт от начала раздела; у FAT и NTFS — загрузочный сектор ¹⁰. Найдя раздел, он предлагает записать таблицу обратно. В ЛР 9 тот же принцип показан коротким скриптом find_ext.py: он находит основной и резервные суперблоки и по номеру группы в резервной копии вычисляет начало раздела.

testdisk /log rescued.img          # интерактивно: Analyse → Quick Search → Write
python3 find_ext.py rescued.img    # ЛР 9: суперблоки и вероятное начало раздела

Если файловая система разрушена полностью (затёрты все копии суперблока или таблица инодов), применяется поиск файлов по сигнатурам (англ. file carving) программой photorec ¹⁰. Метаданные ФС не используются: в «сыром» образе ищутся заголовки известных форматов — %PDF-, FF D8 FF у JPEG, 89 50 4E 47 0D 0A 1A 0A у PNG, PK\x03\x04 у ZIP — и по структуре формата определяется конец файла. У этого метода два ограничения: имена и каталоги теряются (файлы называются по номеру сектора), а фрагментированный файл восстанавливается только до первого разрыва. В ЛР 9 скрипт carve_png.py делает то же для одного формата и показывает, что PNG извлекается из образа, в котором e2fsck уже ничего не может сделать.

Ремонт файловых систем ext4 и резервные суперблоки

Файловая система ext4 разбивает пространство раздела на группы блоков (англ. block groups) ⁴. В начале первой группы (Group 0) с фиксированным смещением 1024 байта от старта раздела расположен первичный суперблок (англ. Primary Superblock). Суперблок содержит критические параметры ФС: общее число блоков и inode, размер блока (1024, 2048 или 4096 байт), состояние флагов монтирования и контрольные суммы метаданных.

При повреждении первых секторов раздела монтирование невозможно:

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

Однако ext4 хранит копии суперблока в начале групп 1 и групп с номерами — степенями 3, 5 и 7 (свойство sparse_super) ⁴. Номера блоков с копиями показывает mke2fs -n с теми же параметрами, что при создании ФС (ключ -n ничего не записывает), или dumpe2fs, если основной суперблок ещё читается. Для раздела с блоком 1 КиБ, как в ЛР 9, копии лежат в блоках 8193, 24577, 40961, 57345 (C-09-06: 8193; расчёт storage.py); для блока 4 КиБ первая копия — в блоке 32768:

mke2fs -n -b 1024 part.img          # ничего не пишет, только печатает разметку

Superblock backups stored on blocks:
	8193, 24577, 40961, 57345

Починка по резервной копии:

e2fsck -fy -b 8193 -B 1024 part.img

Ключ -b задаёт блок с копией суперблока, -B — размер блока (без него e2fsck перебирает размеры сам). Файлы, потерявшие запись в каталоге, переносятся в lost+found с именами по номеру инода. Опыт ЛР 9 показывает и границу метода: если затёрт не только суперблок, а весь первый мегабайт раздела, e2fsck восстанавливает структуру ФС, но иноды группы 0 потеряны вместе с содержимым таблицы инодов, и файлы приходится искать по сигнатурам.

Другие файловые системы и диагностика поверхности

Для других файловых систем порядок тот же — сначала образ, потом инструмент починки, — меняются только команды. XFS чинится xfs_repair (с -n — только проверка; при повреждённом журнале -L обнуляет журнал, теряя последние изменения). Btrfs хранит несколько копий суперблока и контрольные суммы данных: btrfs rescue super-recover восстанавливает суперблок из копии, btrfs restore вытаскивает файлы с несобирающейся ФС на другой носитель, btrfs scrub на живой ФС находит тихую порчу. Пул ZFS, перенесённый на другую машину, подключается zpool import (с -o readonly=on — без записи), а zpool scrub проверяет контрольные суммы всех блоков. Поверхность HDD проверяется badblocks в режиме только чтения (badblocks -sv /dev/sdb, без -w, который стирает данные); на SSD эта проверка мало что даёт, состояние видно в SMART.

Криптографическая защита томов и управление ключами

Архитектура LUKS2 и уязвимость заголовка

Шифрование накопителей на изолированном узле — обязательная мера защиты информации от компрометации в случае кражи или изъятия оборудования ¹¹. Стандартом шифрования блочных устройств в Linux является спецификация LUKS (англ. Linux Unified Key Setup), реализованная в подсистеме dm-crypt.

В современной редакции LUKS2 шифрование организовано по двухуровневой схеме:

Пароль оператора (Passphrase) / Ключевой файл (Keyfile)
               │
               ▼ (Криптографическая функция KDF: Argon2id)
       Разблокировка одного из 32 слотов (Keyslot)
               │
               ▼ (Расшифровка метаданных)
       Мастер-ключ тома (Volume Key, 512-бит AES-XTS)
               │
               ▼ (Прозрачное посекторное шифрование dm-crypt)
       Сектора файловой системы (/dev/mapper/cryptroot)

Мастер-ключ тома (англ. Volume Key) генерируется генератором случайных чисел ядра один раз при создании тома и никогда не меняется. Пользовательский пароль не шифрует сам диск: пароль используется исключительно для расшифровки мастер-ключа, хранящегося в одном из 32 доступных слотов заголовка ¹¹. Хэширование пароля выполняется алгоритмом Argon2id, требующим значительных затрат оперативной памяти (до 1 ГБ) и времени ЦП, что предотвращает атаки аппаратного перебора на GPU/ASIC.

У этой архитектуры есть фундаментальная критическая уязвимость: заголовок LUKS2 имеет фиксированный физический размер (стандартно 16 МБ) и расположен в самом начале блочного устройства. Если в результате сбоя питания, повреждения первых секторов Flash-накопителя или ошибки оператора (dd if=/dev/zero of=/dev/sda bs=1M count=16) первые 16 мегабайт диска затираются — расшифровка данных математически невозможна ¹¹. Оговорка для LUKS2: двоичный заголовок и область метаданных JSON записаны в нём дважды (основная и вторичная копии), поэтому порча первых килобайт исправляется автоматически при открытии тома; но область слотов ключей хранится в одном экземпляре, и её потеря необратима без внешней копии, сделанной cryptsetup luksHeaderBackup ¹¹. Данные полезной нагрузки (англ. payload) остаются зашифрованными на случайном симметричном ключе AES, который более не существует во вселенной. Никакие методы карвинга или низкоуровневого анализа не способны извлечь ни единого байта из такого раздела.

Резервное копирование заголовка LUKS

Из необратимости потери заголовка LUKS2 следует проектное правило: создание резервной копии заголовка тома обязательно сразу после инициализации шифрованного устройства ¹¹.

Создание резервной копии заголовка:

cryptsetup luksHeaderBackup /dev/sdb2 --header-backup-file /mnt/external_safe/luks_header_node09.bin

Восстановление поврежденного заголовка из архивного файла:

cryptsetup luksHeaderRestore /dev/sdb2 --header-backup-file /mnt/external_safe/luks_header_node09.bin

Резервный файл заголовка содержит мастер-ключ тома (зашифрованный паролями активных слотов). Компрометация файла luks_header_node09.bin эквивалентна компрометации самого зашифрованного диска: получив этот файл, злоумышленник может запустить офлайн-перебор пароля на высокопроизводительном кластере. Поэтому резервные копии заголовков LUKS хранятся с тем же уровнем физической изоляции, что и сами мастер-пароли.

Схема разделения секрета и бумажные ключи

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

Для предотвращения этой единой точки отказа (SPOF, тема 1) применяются два инструмента:

1. Резервные ключи восстановления (Recovery Keys): в один из свободных слотов LUKS2 (например, Keyslot 1) добавляется криптографически стойкий алфавитно-цифровой ключ высокой энтропии (256 бит, 64 символа):

   # Генерация случайного ключа восстановления и добавление в свободный слот
   openssl rand -hex 32 > recovery_key.txt
   cryptsetup luksAddKey /dev/sdb2 recovery_key.txt
   

   Этот ключ распечатывается на бумажном носителе в виде текстовой строки и QR-кода, упаковывается в физически опечатанный свето-влагозащитный конверт и помещается в сейф узла (печатная часть профиля, тема 2). Бумага не подвержена сбоям прошивки контроллеров и сохраняет читаемость десятилетиями.

2. Схема разделения секрета Шамира (англ. Shamir's Secret Sharing, SSS): математический алгоритм, позволяющий разделить секрет (мастер-пароль или файл ключа) на N частей (долей) таким образом, что восстановить исходный секрет можно только при объединении любых K частей (K \le N, так называемая пороговая схема (K, N)) ¹². Любые K-1 частей не дают злоумышленнику абсолютно никакой информации о секрете (информационно-теоретическая стойкость).

Пример реализации для автономного коллектива из 3 операторов по схеме (2 из 3) с использованием утилиты ssss-split:

• Оператор А получает Долю 1.
• Оператор Б получает Долю 2.
• Оператор В получает Долю 3. Для расшифровки корневого накопителя узла после аварии достаточно присутствия любых двух операторов из трех. Гибель или предательство одного участника не блокирует доступ к системе и не раскрывает мастер-ключ досрочно.

Что эта модель не учитывает

1. Модель не учитывает тяжелые механические повреждения магнитных дисков (заклинивание гидродинамического подшипника шпинделя, обрыв катушки позиционера головок, царапины на магнитных пластинах). Устранение таких неисправностей требует ламинарного бокса чистой зоны (Cleanroom Class 100), донорского накопителя идентичной ревизии и прецизионного съемника магнитных головок, что выходит за рамки возможностей автономного узла.
2. Модель не учитывает электрический пробой NAND Flash памяти, при котором высоковольтный импульс разрушает изолирующие оксидные переходы элементарных ячеек кристалла, уничтожая квантовое состояние сохраненного заряда.
3. Модель не учитывает аппаратные программные блокировки прошивки SSD («кирпич» контроллера, вход в safe-mode ROM с кодом ошибки Silicon Motion или Phison), требующие перевода микросхемы в тестовый режим (testpoint) и технологических утилит заводской прошивки.
4. Модель предполагает добросовестность операционной системы и криптографических библиотек в отношении атак по сторонним каналам (англ. side-channel attacks — анализ потребления тока шины питания процессора при вычислении раундовых ключей AES в ОЗУ).

Итоги темы

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

Основная защита от потери информации — несколько копий в разных местах по адаптированному правилу трёх копий, из которых хотя бы одна недоступна для удаления с самого узла (rest-server --append-only) и хотя бы одна физически отключена. Разделение данных по трем уровням критичности с минимизацией RPO для уникальных файлов позволяет удержать объем резервных архивов и расход энергии на их генерацию в пределах допустимого баланса автономного узла. Дедупликация на основе плавающего окна в утилите restic обеспечивает компактность репозитория, а сквозное шифрование исключает утечку данных при физической утрате накопителя.

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

При наступлении физической аварии носителя порядок действий начинается с немедленной изоляции устройства, переводе в режим «только чтение» и снятии посекторного образа утилитой ddrescue с картой (mapfile): сначала с -n, чтобы быстро забрать исправное, затем, если позволяют время и энергия, с выскабливанием и повторами. Все последующие восстановительные манипуляции — от починки суперблоков e2fsck до сборки таблиц разделов в testdisk — производятся исключительно над копией образа. При этом наличие заблаговременно сохраненного заголовка LUKS2 и бумажной копии ключа восстановления разделяет безопасность и доступность, не допуская превращения шифрования в причину безвозвратной гибели данных.

Литература

1. Schroeder B., Lagisetty R., Merchant A. Flash Reliability in Production: The Expected and the Unexpected // 14th USENIX Conference on File and Storage Technologies (FAST '16). — USENIX Association, 2016.
2. Schroeder B., Gibson G. A. Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you? // 5th USENIX Conference on File and Storage Technologies (FAST '07). — USENIX Association, 2007.
3. Cai Y., Haratsch E. F., Mutlu O., Mai K. Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives // Proceedings of the IEEE. — 2017. — Vol. 105, No. 9. — P. 1666–1704.
4. The Linux Kernel documentation: ext4 Data Structures and Algorithms; ext4 General Information (Documentation/filesystems/ext4/, Documentation/admin-guide/ext4.rst). https://docs.kernel.org/filesystems/ext4/
5. Keeton K., Santos C., Beyer D., Chase J., Wilkes J. Designing for Disasters // 3rd USENIX Conference on File and Storage Technologies (FAST '04). — USENIX Association, 2004.
6. NIST Special Publication 800-34 Rev. 1. Contingency Planning Guide for Federal Information Systems. — National Institute of Standards and Technology, 2010. https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
7. Linux Magic System Request Key Hacks. Documentation/admin-guide/sysrq.rst. https://docs.kernel.org/admin-guide/sysrq.html
8. Muthitacharoen A., Chen B., Mazières D. A Low-bandwidth Network File System // SOSP '01: Proceedings of the 18th ACM Symposium on Operating Systems Principles. — ACM, 2001.
9. Diaz Diaz A. GNU ddrescue Manual. Version 1.30. — Free Software Foundation, 2026. https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
10. Grenier C. TestDisk & PhotoRec documentation. — CGSecurity. https://www.cgsecurity.org/wiki/TestDisk
11. Fruhwirth C., Brož M. LUKS2 On-Disk Format Specification. https://gitlab.com/cryptsetup/LUKS2-docs
12. Shamir A. How to share a secret // Communications of the ACM. — 1979. — Vol. 22, No. 11. — P. 612–613.
13. JEDEC JESD218. Solid-State Drive (SSD) Requirements and Endurance Test Method. — JEDEC Solid State Technology Association.
14. restic Documentation; rest-server README. https://restic.readthedocs.io/ ; https://github.com/restic/rest-server

Дополнительные материалы

Вопросы для самопроверки

1. Почему в автономных условиях механический жесткий диск (HDD) и твердотельный накопитель (SSD) требуют принципиально разных стратегий профилактики отказов?
2. В чем состоит физический механизм явления data retention во флеш-памяти NAND и почему хранение обесточенного SSD при высокой температуре резко ускоряет деградацию данных?
3. Каким образом транзакционный журнал (JBD2) в файловой системе ext4 защищает метаданные при аварийном отключении питания и почему он не защищает содержимое пользовательских файлов в режиме data=ordered?
4. Что такое тихая порча данных (silent data corruption или bit rot)? Почему традиционные файловые системы (ext4, XFS) не способны обнаружить искажение битов в теле файла?
5. Назовите три ключевые причины, по которым зеркальный RAID-1 массив не может рассматриваться в качестве замены регулярному резервному копированию.
6. По каким критериям данные автономного узла разделяются на три категории критичности? Почему для третьей категории (офлайн-справочники Kiwix, образы ISO) допустим RPO в 30 суток, тогда как для первой категории RPO не должен превышать 1 час?
7. Каким образом алгоритм дедупликации с плавающим окном переменного размера (Content-Defined Chunking, CDC) справляется со сдвигом байтов при редактировании файла?
8. В чем заключается адаптированное правило 3-2-1 для изолированного узла, полностью лишенного связи с интернетом и внешними дата-центрами?
9. Почему первый запуск GNU ddrescue делают с ключом -n (без фазы выскабливания)? Что остаётся несделанным после такого запуска и какие статусы будут в карте?
10. Какие атрибуты SMART являются первичными маркерами физической деградации магнитной пластины жесткого диска и ячеек твердотельного накопителя?
11. Почему повреждение первых 16 МБ раздела с шифрованием LUKS2 делает расшифровку данных математически невозможной даже при наличии правильного пароля оператора?
12. Каким образом схема разделения секрета Шамира (Shamir's Secret Sharing) устраняет единую точку отказа (SPOF) при хранении мастер-ключей автономного узла?

Глоссарий темы

Шпаргалка по инструментам

Низкоуровневая диагностика и посекторное спасение

# Диагностика физического состояния накопителя через SMART
smartctl -a /dev/sdX
smartctl -t short /dev/sdX     # Запуск короткого самотестирования
smartctl -t long /dev/sdX      # Запуск полного сканирования поверхности

# Многопроходное спасение дефектного накопителя утилитой GNU ddrescue
# Запуск 1: копирование, обрезка и прочёсывание без выскабливания (-n), прямой доступ (-d)
ddrescue -d -n /dev/sdX disk_rescue.img rescue.map

# Запуск 2 с той же картой: выскабливание и три прохода повторов
ddrescue -d -r3 /dev/sdX disk_rescue.img rescue.map

# Учебная ошибка чтения без root: сектора не '+' в карте дефектов считаются сбойными
ddrescue -H defects.map disk.img rescued.img test.map

# Просмотр статистики и генерация отчета карты
ddrescuelog -t rescue.map

Восстановление файловой системы ext4

# Поиск адресов резервных суперблоков без внесения изменений
mke2fs -n -b 4096 /dev/sdX1

# Проверка и восстановление ФС с использованием альтернативного суперблока
e2fsck -b 32768 -y /dev/sdX1

# Извлечение критического файла из поврежденного образа без монтирования
debugfs -R "dump /etc/network/interfaces /tmp/restored_interfaces" disk_rescue.img

Управление шифрованием LUKS2

# Создание резервной копии заголовка LUKS (обязательно при инициализации)
cryptsetup luksHeaderBackup /dev/sdX2 --header-backup-file /mnt/safe/luks_header.bin

# Восстановление заголовка LUKS из резервной копии
cryptsetup luksHeaderRestore /dev/sdX2 --header-backup-file /mnt/safe/luks_header.bin

# Добавление резервного ключа восстановления (Recovery Key) в свободный слот
cryptsetup luksAddKey /dev/sdX2 /path/to/recovery_key.bin

Резервное копирование restic

# Инициализация зашифрованного репозитория
export RESTIC_PASSWORD="strong_master_password"
restic init --repo /mnt/backup_drive/repo

# Создание инкрементного снапшота
restic backup --repo /mnt/backup_drive/repo /etc /var/data /home/user

# Просмотр списка снапшотов
restic snapshots --repo /mnt/backup_drive/repo

# Проверка n-й десятой части данных (за 10 запусков — весь репозиторий)
restic check --repo /mnt/backup_drive/repo --read-data-subset=3/10

# Сервер с неизменяемым хранилищем: удаление и перезапись отвергаются
rest-server --path /srv/restic --append-only --listen :8000

# Проверочное восстановление снапшота на чистый каталог
restic restore latest --repo /mnt/backup_drive/repo --target /tmp/test_restore

Что почитать и посмотреть

1. Diaz Diaz A. GNU ddrescue Manual, version 1.30 (2026). https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html Официальное руководство автора утилиты GNU ddrescue. Исчерпывающее описание фаз работы алгоритма, состояний карты блоков и методик спасения дисков с «залипающими» головками.
2. Ts'o T. Ext4 Disk Layout Specification // Linux Kernel Documentation. Официальная спецификация физического размещения структур файловой системы ext4 на блочном устройстве: суперблоки, дескрипторы групп, битовые карты блоков и таблицы inode.
3. Fruhwirth C., Broz M. LUKS2 On-Disk Format Specification (2022). Архитектурное описание структуры томов LUKS2, алгоритмов деривации ключей Argon2id, размещения JSON-метаданных и механизма защиты от прерванной записи заголовков.
4. JEDEC JESD218. Solid-State Drive (SSD) Requirements and Endurance Test Method. Стандарт, задающий классы SSD (Client, Enterprise), требования к сохранности данных без питания после выработки ресурса и методику испытаний; отсюда в теме 9 число «1 год при +30 °C» для клиентских SSD.
5. Backblaze Hard Drive and SSD Reliability Reports (Quarterly Review). Регулярные инженерные отчеты дата-центров Backblaze с анализом статистики отказов сотен тысяч HDD и SSD: корреляция между атрибутами SMART 5/187/197/198 и фактической смертью накопителей.
6. Muthitacharoen A. et al. A Low-Bandwidth Network File System (LBFS) // SOSP '01 (ACM). Классическая статья, заложившая математические основы блочной дедупликации с использованием скользящего окна Рабина (Rabin fingerprinting).

Углубление

Очерк 1. Транзакционный журнал JBD2 в ext4 и пределы его возможностей

Подсистема JBD2 (Journaling Block Device) ядра Linux обеспечивает транзакционную целостность метаданных ext4. Работа журнала организована в три фазы:

1. Journaling: запись дескриптора транзакции и измененных блоков метаданных в непрерывную кольцевую область на диске (.journal).
2. Commit: фиксация транзакции специальным маркером фиксации (commit block). Только после записи этого блока транзакция считается завершенной.
3. Checkpointing: фоновый сброс измененных метаданных из кольцевого журнала в их окончательные постоянные позиции в таблицах inode и суперблоках.

Если питание исчезает в фазе 1, транзакция отбрасывается. Если питание пропадает в фазе 3, процедура воспроизведения журнала (journal replay) при следующем монтировании считывает данные из журнала и дописывает их в постоянные блоки.

Однако у JBD2 есть неустранимые ограничения:

• Отсутствие защиты от bit rot: JBD2 не проверяет контрольные суммы блоков при чтении. Если блок повредился в результате деградации Flash-ячейки, JBD2 перезапишет его в основную область без генерации предупреждения.
• Поведение при сбое питания потребительских SSD: если контроллер накопителя сбросил кэш неупорядоченно, маркер фиксации (commit block) может физически записаться на пластину раньше, чем предшествующие ему блоки дескрипторов транзакции. При перезагрузке ядро попытается воспроизвести поврежденный журнал, что приведет к разрушению файловой системы. Для предотвращения этого в критических системах монтирование производят с явным флагом barrier=1.

Очерк 2. Схема разделения секрета Шамира для мастер-ключей узла

Схема Шамира базируется на фундаментальной теореме алгебры: через любые K точек на двумерной плоскости можно провести один и только один полином степени K-1.

Пусть мастер-секрет S представляет собой целое число в конечном поле Галуа \mathbb{F}_p (p > S, где p — простое число). Для разделения секрета на N частей по пороговой схеме (K, N):

1. Случайным образом выбираются K-1 коэффициентов a_1, a_2, \dots, a_{K-1}.
2. Формируется полином степени K-1: f(x) = S + a_1 x + a_2 x^2 + \dots + a_{K-1} x^{K-1} \pmod p Здесь свободный член f(0) = S и является защищаемым секретом.
3. Каждому из N операторов выдается точка на полиноме: пара (x_i, f(x_i)), где x_i \ne 0.

Любые K участников, объединив свои точки (x_1, y_1), \dots, (x_K, y_K), могут однозначно восстановить полином f(x) и вычислить S = f(0) с помощью интерполяционной формулы Лагранжа:

S = \sum_{j=1}^{K} y_j \prod_{m \ne j} \frac{0 - x_m}{x_j - x_m} \pmod p

Если же злоумышленник завладел K-1 долями, степень неопределенности в отношении S остается абсолютной: через K-1 точек можно провести бесконечное множество полиномов степени K-1, принимающих любое произвольное значение S' \in \mathbb{F}_p в точке x = 0. Это математически исключает компрометацию узла при потере одной из долей.

Лабораторная работа 9. Восстановление после порчи

• Раздел курса: тема 9 «Сохранность и восстановление данных»

Введение

В теме 9 восстановление данных описано как последовательность: изолировать носитель, снять образ, восстановить разметку, починить файловую систему, а если она не чинится — искать файлы по сигнатурам; и отдельно — резервные копии, которые делают всё это ненужным, если они есть и проверены. Каждый шаг этой цепочки имеет границу применимости, и работа построена так, чтобы до границы дойти: часть опытов должна закончиться неудачей, и правильное предсказание в них — «не восстановится».

Все опыты выполняются на файле-образе disk.img (64 МиБ, таблица MBR, раздел ext4 с блоком 1 КиБ), который скрипт make_image.sh создаёт без прав root. Данные в образе синтетические: конфигурация узла, журнал, телеметрия и PNG-«фото», сгенерированные скриптом; их эталонные SHA-256 записаны в reference.sha256. Реальные диски в работе не участвуют.

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

Ошибки чтения в части 2 получаются честно, без имитации нулями (нули читаются без ошибок и ничего не проверяют). Основной способ без root — настоящий GNU ddrescue в режиме --test-mode: по руководству ddrescue, сектора, не отмеченные в карте дефектов как +, программа считает ошибками чтения, не обращаясь к ним. Карта дефектов defects.map — синтетическая (сектора 8000 и 25000). Этот способ проверяет алгоритм ddrescue и чтение карты, но не поведение накопителя: задержек и «иногда читающихся» секторов в нём нет. Настоящая ошибка ввода-вывода ядра получается в ветке ВМ (или на своей машине с root) через цель error подсистемы device-mapper.

Цель работы

Восстановить данные с повреждённого образа диска разными способами, найти границы каждого способа и проверить восстановление сервиса из резервной копии restic.

После выполнения работы можно будет:

• восстановить таблицу разделов из дампа и без дампа — по сигнатурам суперблоков;
• починить ext4 по резервному суперблоку и объяснить, когда это не помогает;
• извлечь файлы по сигнатурам из образа с разрушенной ФС;
• снять образ «сбойного диска» ddrescue и прочитать карту: статусы, фазы, сбойные сектора;
• определить, какой файл задет сбойным сектором;
• сделать копию restic, восстановить её на чистый носитель и проверить отказ удаления через rest-server --append-only;
• замерить время каждого этапа и вести журнал, включая неуспешные восстановления.

Теоретический минимум

• Тема 9, «Посекторное копирование ddrescue и карта mapfile»: фазы copying, trimming, sweeping, scraping, retrying; статусы ?, *, /, -, +; ключ -n пропускает только выскабливание.
• Тема 9, «Числовой пример»: C-09-02 (1,74 ч), C-09-03 (1,81 ч), C-09-04 (2,71 ч), C-09-05 (5040 с).
• Тема 9, «Ремонт файловых систем ext4»: резервные суперблоки при блоке 1 КиБ — 8193, 24577, 40961, 57345 (C-09-06: 8193).
• Тема 9, «Неизменяемые репозитории»: почему rest-server --append-only, а не chattr +a.

Раскладка образа:

Смещения сбойных секторов проверяются арифметикой: 8000 · 512 = 4 096 000 = 0x3E8000, 25000 · 512 = 12 800 000 = 0xC35000 (C-09-09: 0x3E8000, 0xC35000).

Перечень оснащения

• Ноутбук с Linux; права root не нужны.
• Обязательно: python3, coreutils, util-linux (sfdisk), e2fsprogs (mke2fs, e2fsck, debugfs).
• Желательно: gddrescue, testdisk (содержит photorec), restic, rest-server (Debian 13: пакет restic-rest-server; иначе бинарный файл с github.com/restic/rest-server).
• Для ветки dm-error: ВМ из ЛР 7 (root внутри ВМ) или своя машина с root.
• Архив окружения: lr-env.zip.

Порядок выполнения работы

mkdir -p ~/polygon/lr09 && cd ~/polygon/lr09
unzip ~/Загрузки/lr-env.zip && cd lr-env
./selftest.sh                       # «selftest ЛР 9: OK»; SKIP — чего нет
./make_image.sh work && cd work     # disk.img, table.dump, reference.sha256, seed/
cp disk.img clean.img               # эталон для повторов опытов

Время каждого этапа засекается командой time или парой date +%s и записывается в журнал. После каждого опыта образ возвращается: cp clean.img disk.img. Раздел извлекается из образа и проверяется так:

dd if=disk.img of=part.img bs=512 skip=2048 status=none
../check_files.sh part.img reference.sha256 out    # 0 — всё совпало, 1 — нет, 2 — ФС не читается

Часть 1. Таблица разделов и начало диска

Задание

Испортить таблицу разделов, восстановить её из дампа и без дампа. Затем затереть начало диска целиком (MBR и первый мегабайт раздела) и выяснить, что из этого восстанавливается.

Предсказание

1. После затирания сектора 0 (MBR) повреждены ли файлы? Что покажет sfdisk -l?
2. Если дампа таблицы нет, по каким признакам найти начало раздела?
3. Затёрты первые 2 МиБ образа. Восстановит ли e2fsck по резервному суперблоку файлы? Найдутся ли они в lost+found?

Порядок выполнения

../damage.sh disk.img mbr
sfdisk -l disk.img
python3 ../find_ext.py disk.img                  # суперблоки и начало раздела
sfdisk disk.img < table.dump                     # способ 1: из дампа
cp clean.img disk.img; ../damage.sh disk.img mbr
printf 'label: dos\nstart=2048, type=83\n' | sfdisk disk.img   # способ 2: по find_ext.py
dd if=disk.img of=part.img bs=512 skip=2048 status=none
../check_files.sh part.img reference.sha256 out

Способ 3, если установлен testdisk: testdisk /log disk.img, затем Analyse → Quick Search → найденный раздел → Write. Записать, совпало ли найденное начало с сектором 2048.

Затирание начала диска:

cp clean.img disk.img; ../damage.sh disk.img head
sfdisk disk.img < table.dump
dd if=disk.img of=part.img bs=512 skip=2048 status=none
e2fsck -fy -b 8193 -B 1024 part.img; echo "код e2fsck $?"
../check_files.sh part.img reference.sha256 out
ls out/lost+found | head

Что должно получиться

• После порчи MBR файлы целы, раздела не видно; таблица восстановлена тремя способами (дамп, find_ext.py, testdisk или отметка SKIP), файлы совпадают с эталоном.
• После затирания начала диска: код e2fsck, итог check_files.sh и объяснение, почему файлы не нашлись даже по содержимому (что лежит в первом мегабайте раздела ext4 с блоком 1 КиБ).
• Время каждого способа восстановления таблицы.

Часть 2. Сбойные сектора и ddrescue

Задание

Снять образ «диска» с двумя сбойными секторами тремя запусками ddrescue (-n, полный, -r3), прочитать карту после каждого и определить, какие файлы задеты.

Предсказание

1. Какие статусы будут в карте после запуска с -n? Останутся ли участки /?
2. Изменится ли карта после -r3, если сектора не читаются никогда?
3. Задет ли сбойным сектором хотя бы один файл, или сектора попали в служебные области ФС?

Порядок выполнения

Ветка П0 (без root), если установлен ddrescue:

cd ~/polygon/lr09/lr-env
python3 mapfile_tool.py stats defects.map --expect-bad 8000 25000    # что «сломано»
./ddrescue_lab.sh work/clean.img defects.map                         # три запуска, карты run*.map
python3 mapfile_tool.py stats run-n.map

Какие файлы задеты. Сектор образа s принадлежит блоку ФС b = (s − 2048) · 512 / 1024; по блоку debugfs находит инод, по иноду — имя:

python3 -c "print((8000-2048)*512//1024, (25000-2048)*512//1024)"   # блоки 2976 и 11476
dd if=work/clean.img of=part.img bs=512 skip=2048 status=none
debugfs -R "icheck 2976 11476" part.img
debugfs -R "ncheck <инод>" part.img

Если ddrescue нет, работа идёт по приложенным картам: example_inprogress.map (пример из руководства GNU ddrescue 1.30 со всеми статусами) и defects.map; разбор mapfile_tool.py stats и вопросы предсказания отвечаются по ним и по разделу темы 9. В журнале отмечается, что ddrescue не запускался.

Ветка ВМ или root — настоящая ошибка ввода-вывода. Образ подключается через loop-устройство, поверх него строится устройство device-mapper, у которого сектора 8000 и 25000 отвечают ошибкой (цель error), остальные отображаются на образ (цель linear):

sudo losetup -f --show -r work/clean.img          # например /dev/loop0, только чтение
sudo dmsetup create baddisk <<'EOF'
0 8000 linear /dev/loop0 0
8000 1 error
8001 16999 linear /dev/loop0 8001
25000 1 error
25001 106071 linear /dev/loop0 25001
EOF
sudo dd if=/dev/mapper/baddisk of=/dev/null bs=512 skip=8000 count=1   # Input/output error
sudo ddrescue -d -n /dev/mapper/baddisk rescued.img real.map
sudo ddrescue -d -r3 /dev/mapper/baddisk rescued.img real.map
python3 mapfile_tool.py stats real.map --expect-bad 8000 25000
sudo dmsetup remove baddisk; sudo losetup -d /dev/loop0

Сумма длин в таблице равна размеру образа: 8000 + 1 + 16 999 + 1 + 106 071 = 131 072 сектора по 512 Б = 64 МиБ. Сравнить время запусков с веткой --test-mode и объяснить разницу.

Что должно получиться

• Сводка карты после каждого запуска: размеры по статусам, сбойные участки в секторах; подтверждение, что найдены ровно сектора 8000 и 25000.
• Ответ на вопрос 2 предсказания по фактическим картам.
• Номера блоков, инодов и имена задетых файлов (или вывод, что задеты служебные области), и решение: стоит ли тратить время на повторы ради этих секторов.

Часть 3. Суперблок и тихая порча

Задание

Затереть основной суперблок и восстановить ФС по резервному; затереть все копии суперблока и извлечь файлы по сигнатурам; изменить один байт данных файла и выяснить, кто это заметит.

Предсказание

1. Сколько копий суперблока в разделе 63 МиБ с блоком 1 КиБ и где они? Сверить с C-09-06 (первая копия — блок 8193).
2. Все копии суперблока затёрты. Что найдёт photorec (или carve_png.py) и что потеряется?
3. Изменён один байт в journal.txt. Что скажет e2fsck -fn? Что скажет сверка SHA-256?

Порядок выполнения

cd work
mke2fs -n -b 1024 part.img | grep -A1 'Superblock backups'    # part.img из clean.img
cp clean.img disk.img; ../damage.sh disk.img sb
dd if=disk.img of=part.img bs=512 skip=2048 status=none
../check_files.sh part.img reference.sha256 out; echo "код $?"
time e2fsck -fy -b 8193 -B 1024 part.img
../check_files.sh part.img reference.sha256 out

cp clean.img disk.img; ../damage.sh disk.img allsb
dd if=disk.img of=part.img bs=512 skip=2048 status=none
e2fsck -fy -b 8193 -B 1024 part.img; echo "код $?"
python3 ../carve_png.py disk.img carved && sha256sum carved/*.png seed/photos/panel.png
photorec /log /d carved_pr/ disk.img        # если установлен: интерактивно, тип файлов PNG и TXT

cp clean.img disk.img; ../damage.sh disk.img bitflip
dd if=disk.img of=part.img bs=512 skip=2048 status=none
e2fsck -fn part.img; echo "код $?"
../check_files.sh part.img reference.sha256 out

Что должно получиться

• Номера резервных суперблоков и восстановление по копии 8193 с совпадением всех файлов.
• При затёртых всех копиях: отказ e2fsck и извлечённый по сигнатуре PNG, совпадающий с исходным по SHA-256; список того, что сигнатурами не восстановилось (имена, каталоги, текстовые файлы без сигнатуры).
• Тихая порча: e2fsck ошибок не видит, сверка SHA-256 указывает изменённый файл. Вывод о том, какая проверка нужна в регламенте.

Часть 4. Резервная копия restic и восстановление сервиса

Задание

Сделать копию данных узла restic, «потерять» данные, восстановить их на чистый носитель и проверить по эталону; убедиться, что через rest-server --append-only удалить копию нельзя; настроить ежечасную копию таймером systemd --user.

Предсказание

1. Сколько займёт восстановление на чистый носитель по сравнению с копированием?
2. Что ответит restic forget --prune через сервер в режиме append-only?
3. Что не попадёт в копию каталога данных, но понадобится, чтобы сервис заработал на чистом носителе?

Порядок выполнения

cd ~/polygon/lr09/lr-env
unshare -rn bash -c 'ip link set lo up; ./restic_lab.sh work/seed work/reference.sha256'

Скрипт без restic печатает SKIP и ничего не подменяет. Внутри unshare -rn сервер rest-server слушает изолированную петлю и не виден основной системе.

Таймер (на своей машине, без root):

mkdir -p ~/.config/systemd/user ~/polygon/backup ~/polygon/data
cp systemd/restic-backup.* ~/.config/systemd/user/
printf '%s\n' "$(head -c 24 /dev/urandom | base64)" > ~/polygon/backup/password; chmod 600 ~/polygon/backup/password
RESTIC_PASSWORD_FILE=~/polygon/backup/password restic init -r ~/polygon/backup/repo
systemctl --user daemon-reload && systemctl --user enable --now restic-backup.timer
systemctl --user list-timers restic-backup.timer

Восстановление сервиса на чистом носителе: в ВМ из ЛР 7 (или в новом каталоге) восстановить из копии каталог данных и конфигурацию «острова» из ЛР 8 (conf/), поднять его ./island.sh up и проверить wiki.polygon.internal. Записать, чего не хватило (программы, ключ, пароль) — это записи журнала неуспешных восстановлений.

Что должно получиться

• Время init, backup, check, restore; совпадение восстановленных файлов с эталоном.
• Отказ forget --prune через append-only сервер (или SKIP) и объяснение, почему chattr +a здесь не годится.
• Работающий таймер (list-timers) и запись в журнале о первом срабатывании.
• Журнал восстановления сервиса, включая неуспешные попытки и их причины.

Журнал работы

Графы «Предсказание» заполняются до опыта, «Факт» — после. В графе «Ветка» — П0, --test-mode, dm-error или приложенные карты.

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

Контрольные вопросы

1. Почему имитация сбойных секторов записью нулей ничего не проверяет, а --test-mode и dm-error проверяют?
2. Чем различаются статусы *, / и - в карте ddrescue и в какой фазе каждый появляется?
3. Что именно пропускает ключ -n? Почему первый запуск делают с ним?
4. Почему сбойный сектор может не задеть ни одного файла и как это проверить?
5. Почему после порчи MBR данные целы, а после затирания первого мегабайта раздела — нет, хотя суперблок восстановлен из копии?
6. Как по резервному суперблоку вычислить начало раздела, если таблицы разделов нет?
7. Что теряется при поиске файлов по сигнатурам и почему фрагментированный файл восстанавливается не полностью?
8. Почему e2fsck не видит изменённого байта в файле и какая мера в регламенте это ловит?
9. Почему chattr +a не делает репозиторий restic неизменяемым, а rest-server --append-only делает? От чего append-only не защищает?
10. Почему синхронизация (тема 11) не заменяет резервную копию? Приведите опыт этой работы, где синхронизация разнесла бы порчу.
11. Где хранить пароль restic, чтобы потеря узла не означала потерю копии, а кража копии — раскрытие данных?
12. Что из неуспешных восстановлений части 4 нужно внести в регламент и в профиль узла (тема 2)?