102 lines
7.0 KiB
Markdown
102 lines
7.0 KiB
Markdown
---
|
||
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]].
|