---
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]].