import-stage: .wiki/concepts/ via split (temp prefix for merge into existing dir)
git-subtree-dir: .tmp-concepts git-subtree-mainline:98bcc37d32git-subtree-split:c727aaa1b6
This commit is contained in:
101
.tmp-concepts/hyper-backup-structure-and-recovery.md
Normal file
101
.tmp-concepts/hyper-backup-structure-and-recovery.md
Normal file
@@ -0,0 +1,101 @@
|
||||
---
|
||||
title: Hyper Backup — структура репо и стратегия восстановления
|
||||
type: concept
|
||||
tags: [backup, synology, hyperbackup, recovery, lessons]
|
||||
sources: [../sources/nas-recovery-session-2026-05-18.md]
|
||||
updated: 2026-05-19
|
||||
---
|
||||
|
||||
# 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** (применили мы)
|
||||
|
||||
1. Открыть DSM web UI на target.
|
||||
2. Hyper Backup → **Restore** → **Data Restore Wizard**.
|
||||
3. Список задач **пустой** (этот NAS — приёмник, не source). Снизу-слева: **"Восстановить из существующих репозиториев"**.
|
||||
4. Server type: **"В локальную папку и на USB"**.
|
||||
5. Указать путь к `.hbk` (`/volume1/NetBackup/diskstation_1.hbk`).
|
||||
6. Если шифрования нет (`enable_data_encrypt=false`) — сразу к выбору данных.
|
||||
7. **Системную конфигурацию НЕ восстанавливать** (иначе наложатся пользователи/сеть/шары source-NAS на target).
|
||||
8. Selective restore — пик нужные подпапки.
|
||||
9. **Restore destination:** "Restore to another location" → новая папка (`/volume1/NetBackup/restore-tmp/` или просто root тома → создаст шары с именами как на source).
|
||||
10. Версия: топовая (свежая дата).
|
||||
|
||||
**Гочча:** при 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]].
|
||||
Reference in New Issue
Block a user