Files

vitya 19422352ba docs(.wiki): ingest NAS recovery session 2026-05-18/19

15-hour cross-hypervisor recovery from WD40EFAX SMR RAID5
cascade failure. 5 entities + 7 concepts + 1 source documenting:

- Root cause: WD40EFAX SMR cascade in 3-disk RAID 5
- Hyper Backup .hbk structure + SFTP-jail / ACL workarounds
- OVA from Synology VMM (KVM) → VirtualBox: SCSI→SATA,
  Hyper-V driver disable, paravirt=kvm, GA install, NAT switch
- MSSQL restore via named volume + chown, sqlcmd -x, mssql-conf
- Web.config UTF-16 vs UTF-8 BOM IIS 500.19 trap
- Traefik on Windows DD: configFile, named volume for acme.json,
  file-provider as docker.sock workaround
- Snapshot of current recovery architecture + SPOF list
- Placeholder for future resilient-architecture work

Plus .tasks/nas-recovery.md and STATUS.md updates closing the task.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-19 11:07:38 +03:00

7.0 KiB

Raw Blame History

title, type, tags, sources, updated

title

type

Hyper Backup — структура и recovery

Структура `.hbk` репозитория

Каталог <task-name>.hbk на target-NAS содержит:

<task>.hbk/
├── Config/          — метаданные задачи (план бэкапа)
│   ├── @Share/<sharename>/   — список файлов в каждой бэкапленной шаре
│   ├── target_info.db.<N>    — SQLite, инфа о target
│   ├── version_info.db.<N>   — версии бэкапов
│   ├── file_chunk*.index     — индексы для дедупликации
│   ├── virtual_file.index    — карта файлов
│   └── _Syno_TaskConfig      — **plain text JSON конфиг задачи** (имя, source-host, encryption flag, schedule, backup_folders[], backup_apps[], backup_volumes[])
├── Control/        — управление (lock, @writer)
├── Guard/          — служебное
├── Pool/           — дедуплицированные chunks данных
├── synobkpinfo.db  — SQLite с backup_info_tb, task_id_tb
├── _Syno_TaskConfig — копия конфига в корне
└── SynologyHyperBackup.bkpi — маркер

_Syno_TaskConfig — самый ценный файл для оценки бэкапа без полной распаковки. JSON в нём содержит:

name — имя задачи (в нашем кейсе rsync Server 1)
host_name — имя source-NAS
enable_data_encrypt (true/false) — шифрование клиентским паролем
backup_folders[] — список путей, которые бэкапились
backup_apps[] — DSM-пакеты (если бэкапили их данные)
backup_volumes[] — VM-снимки (Synology VMM)

Hyper Backup Vault vs Hyper Backup

Hyper Backup (/var/packages/HyperBackup/) — клиент. Бэкапит ИЗ этого DSM.
Hyper Backup Vault (/var/packages/HyperBackupVault/) — сервер. Принимает бэкап от других DSM.

На target-NAS (где лежит репо) обычно установлен Vault. Сам он не имеет UI для restore — только receive. Restore инициируется из Hyper Backup (тот же пакет, но в другом режиме).

Стратегии восстановления

Когда мёртвый NAS — source, репо на живом target:

A. Restore через DSM UI на target-NAS (применили мы)

Открыть DSM web UI на target.
Hyper Backup → Restore → Data Restore Wizard.
Список задач пустой (этот NAS — приёмник, не source). Снизу-слева: "Восстановить из существующих репозиториев".
Server type: "В локальную папку и на USB".
Указать путь к .hbk (/volume1/NetBackup/diskstation_1.hbk).
Если шифрования нет (enable_data_encrypt=false) — сразу к выбору данных.
Системную конфигурацию НЕ восстанавливать (иначе наложатся пользователи/сеть/шары source-NAS на target).
Selective restore — пик нужные подпапки.
Restore destination: "Restore to another location" → новая папка (/volume1/NetBackup/restore-tmp/ или просто root тома → создаст шары с именами как на source).
Версия: топовая (свежая дата).

Гочча: при restore "to original location" DSM создаст новые SMB-шары на target c именами как на source (backup/, docker/, work/). Это меняет state target-NAS. Если важно — выбирать "another location".

B. Hyper Backup Explorer (HBE) — офлайн на Windows/Mac/Linux

GUI-приложение от Synology, читает .hbk напрямую (требует password если шифрован). Подходит когда target-NAS недоступен и есть только файлы репо.

Минусы: GUI, тысячи кликов для многих файлов, нет batch-restore.

C. Restore + tar | ssh pull (бекап-копия на чужую машину)

Если уже restored to a target-NAS:

ssh user@target "tar cf - -C /volume1/backup ." | tar xf - -C /local/path

При chrooted SFTP (типичный DSM) — нельзя через scp/sftp пройти за пределы home. Решение: scp -O (legacy SCP protocol через чистый SSH-канал). Или ssh ... 'cat file' > local-file для одиночных файлов.

ACL/permissions особенности (DSM 7)

DSM 7 использует Synology ACL поверх POSIX. Видно + после permissions: d---------+.
POSIX-биты могут показывать 0 для всех, но реально ACL может open file для специфичных users/groups.
Файлы в Hyper Backup-репо могут иметь permission -rw------- (owner-only) — тогда другому юзеру scp -O не достанет, требуется chmod от root.

SFTP-jailed subsystem

DSM SFTP-subsystem chroot'ит пользователя в home (/var/services/homes/<user>/). Пути за пределами не видны через SFTP-клиент.

Обход: scp -O (флаг "use legacy SCP protocol") — обходит SFTP-subsystem, использует raw SSH-channel + shell-команды target-side. Тогда видно всё, что shell-пользователь видит.

Стратегии для будущего

Hyper Backup ежедневно, не "по триггеру" (как было). Окно потерь = 1 день.
Retention 30+ дней — даёт возможность откатиться при позднем обнаружении проблем.
Test restore раз в квартал — простейшая дисциплина: пик одну папку, восстанови в temp, проверь что файлы корректны. Иначе бэкап может тихо умереть без вашего ведома.
Многослойный backup: не только Synology→Synology. Дополнительно cloud (Backblaze B2, AWS S3 Glacier, Yandex Object Storage) — на случай если оба NAS физически рядом и сгорят вместе.

Связано: dead-synology-diskstation, kreknin-synology.

7.0 KiB Raw Blame History Unescape Escape