Восстановить данные

Восстанавливают на сервере командой sudo arcula restore. Мастера восстановления в ЛК нет: ЛК показывает, где бэкап сохранён и до какого уровня его проверяли.

Общие правила:

• Существующее не перезаписывается. Путь, том или база уже есть — проверка не пройдена, и arcula подскажет, что делать: перенести старое, восстановить рядом или достать файлами.
• Сервисы не запускаются. Базы поднимаются только временно, в контейнере без сети. Запуск — ваше решение.
• Ничего не меняется до подтверждения. Сначала проверка готовности и план, затем вопрос «Run the plan? [y/N]».

Мастер

sudo arcula restore

Мастер спрашивает по шагам:

1. «Restore from where?» — хранилища этого сервера или recovery kit.
2. «Recovery point:» — какой бэкап, по умолчанию самый свежий. У каждого — хранилища, где он есть.
3. «What do we do?» — режим.
4. Компонент или пути и каталог.

Затем — проверка готовности: restic, хранилища и бэкап, ОС и архитектура, Docker, место на дисках, конфликты с тем, что уже есть. Потом план по шагам и подтверждение.

Мастер запускается, только если флагов нет. С флагами arcula сразу проверяет и показывает план. Только проверка и план, ничего не меняя, — добавьте --dry-run:

sudo arcula restore --mode component --component support/postgres --dry-run

Восстановление прервалось — продолжите с того же места. ID запуска arcula напечатает при обрыве:

sudo arcula restore --resume <id>

Восстановить компонент

Например, базу на момент до неудачной миграции. В мастере выберите «One component (component)» и компонент из списка. Или флагами:

sudo arcula restore --mode component --component support/postgres

--component — ключ ресурса, путь, имя тома, проект/сервис или проект базы. Другой бэкап — --point (ID или его начало от 8 знаков), хранилище — --from.

Что получится:

• База PostgreSQL, сервис работает. Каждая база импортируется в новую — <база>_restored_<дата>_<время> — в том же контейнере. Рабочая база не трогается: сравните данные и перенесите нужное сами.
• База, сервис не работает. Временный контейнер на своём томе. После проверки он остановлен, но не удалён — данные можно посмотреть.
• Каталог или том. На исходное место. Место занято — мастер спросит другой каталог, флагами — --target /srv/restore.

Достать файлы

Нужны отдельные файлы: конфиг, загрузки пользователей. В мастере выберите «Extract files (files)»: arcula покажет пути из бэкапа — впишите номера или пути, затем каталог. Флагами:

sudo arcula restore --mode files --path /opt/support/uploads --target /srv/restore

• --path можно повторять. Путь — как на исходном сервере, volume ИМЯ для тома или путь внутри бэкапа (db/support/…).
• --target — пустой или новый каталог. Файлы лягут с полным путём: /srv/restore/opt/support/uploads, тома — в /srv/restore/volumes/<том>.

На сервере ничего не перезаписывается: забирайте нужное из каталога сами.

Поднять сервер на чистой машине

Сервер потерян, нужна новая машина. Доступа к чужим репозиториям у агента нет, поэтому другой сервер поднимается только по recovery kit. Kit выдаёт ЛК: «Настройки» → «Восстановление без панели» → «Recovery kit».

На новой машине нужны:

• arcula и restic 0.18.1. Панель жива — поставьте их строкой установки из «+ Сервер», как в статье Подключить сервер. Панели нет — см. Восстановить без панели.
• Docker Engine с Compose v2, если восстанавливаются тома и базы. arcula его не ставит.
• Recovery kit и пароль от него.

Что ещё понадобится этому серверу — ключи unseal Vault, та же версия GitLab, — ЛК показывает у сервера: «Обзор» → «Понадобится при восстановлении».

Проверьте kit — открывается ли он и читаются ли репозитории:

arcula kit verify ./arcula-recovery-kit-2026-10-24.age

Запустите мастер. Доступа к хранилищам у новой машины нет, поэтому он сразу спросит файл kit, затем его пароль:

sudo arcula restore

Или без мастера: с --kit arcula готовит сервер (prepare) из самого свежего бэкапа. План он всё равно покажет и спросит подтверждение:

sudo arcula restore --kit ./arcula-recovery-kit-2026-10-24.age

В kit несколько серверов, а имя хоста новой машины другое — назовите сервер: --server prod-db-01.

prepare идёт по порядку: пользователи и группы с исходными UID и GID, каталоги Compose-проектов и файлы, образы сервисов, базы, тома. Настройки хоста — cron, службы, прокси — только извлекаются в /var/lib/arcula/restore/<id>/host: включаете их вы, после проверки.

Что осталось сделать вам, отчёт перечислит в «Left for you to do». Обычно это запуск проектов:

cd /opt/support && docker compose up -d

Затем — cron и службы из извлечённых настроек хоста, DNS. Подключить новую машину к панели можно и позже: install.sh восстановленные данные не трогает.

Отчёт и уровень проверки

В конце arcula печатает отчёт: какой бэкап и из какого хранилища, что восстановлено, что не удалось или пропущено, что осталось сделать вам. И уровень — только по тому, что реально проверено:

Уровень 4 бывает, только если в восстановлении есть база PostgreSQL. Уровень 5 — «восстановлен проект» — эта версия не выдаёт: запуск сервисов остаётся за вами.

Полный отчёт и шаги лежат в /var/lib/arcula/journal/restore-<id>/run.json.

Что видно в ЛК

Если сервер подключён к панели, ход и отчёт уходят в ЛК:

• пока идёт — под именем сервера «Идёт восстановление бэкапа от … из «…»» и этап;
• сервер → «Бэкапы» → колонка «Восстановление»: уровень и дата. Наведите на неё — что именно проверялось и что осталось вам. Отметка «только восстанавливавшиеся» оставит в списке только такие бэкапы;
• сервер → «Журнал», фильтр «Восстановление»: «Восстановлено: компонент», «Восстановление не удалось» или «Восстановление прервано» — с шагами и строками лога.

Панель недоступна — восстановление всё равно идёт. Журнал дошлёт служба arcula-agent или sudo arcula restore --resume <id>.

На сервере те же отметки видны в sudo arcula points, колонка «Restore».