Бэкап и восстановление Nexus Repository

MAATRIX

Nexus Repository — это не просто файловый архив: внутри у него живёт база данных, которая знает, какой blob соответствует какой версии артефакта в каком репозитории. Потерять её без бэкапа — значит получить гигабайты безымянных файлов и разваленный CI/CD, где ни один mvn deploy или docker push больше не найдёт то, что искал. Разберём, что именно нужно сохранять, как это делать без остановки продакшена на часы и как поднять Nexus заново, если сервер лёг.

Что физически нужно бэкапить

У Nexus Repository (и OSS, и Pro) вся рабочая директория обычно называется sonatype-work/nexus3 — при установке из tar/rpm это чаще всего /opt/sonatype-work/nexus3, в Docker-образе sonatype/nexus3 — это /nexus-data. Внутри три вещи, которые нужны для полного восстановления:

• blobs/ — сами файлы артефактов (jar, npm-тарболы, docker-слои, wheel-файлы), хранятся как content-addressable storage: имя файла — это хэш содержимого, а не путь в репозитории.
• база данных — метаданные: какой blob к какому GAV (groupId:artifactId:version) или npm-пакету относится, права, роли, настройки репозиториев, blob store и realm-конфигурация.
• etc/ — конфигурационные файлы: nexus.properties, keystore для HTTPS, лицензия (для Pro), JVM-опции.

Отдельно стоит поисковый индекс (Elasticsearch внутри Nexus) — его бэкапить не нужно, он перестраивается автоматически при старте, если индекс повреждён или отсутствует. То же с временными файлами в tmp/ и логами в log/ — это балласт, который только раздувает архив.

Если Nexus крутится в вашем CI-контуре, то же самое окружение стоит готовить осознанно с самого начала — есть отдельный разбор, как настроить VPS под разработчика и CI/CD с прицелом на такие сервисы.

OrientDB или новый datastore — от чего зависит стратегия

До определённого момента Nexus 3 хранил метаданные в embedded OrientDB, и у него была штатная задача бэкапа этой базы прямо из веб-интерфейса. В более новых сборках Sonatype перевела ядро на новый datastore-движок: по умолчанию это embedded H2, либо — в конфигурациях с высокой нагрузкой — внешний PostgreSQL. Это принципиально меняет подход к бэкапу, поэтому первый шаг — понять, что у вас крутится сейчас.

Проверить можно так:

# версия и издание Nexus
curl -s http://localhost:8081/service/rest/v1/status | head
cat /opt/sonatype-work/nexus3/etc/nexus.properties | grep -i datastore

# если используется внешний PostgreSQL — это будет видно в nexus-store.properties
cat /opt/sonatype-work/nexus3/etc/fabric/nexus-store.properties 2>/dev/null

Если файла nexus-store.properties нет и в конфиге нет упоминаний PostgreSQL — у вас embedded-хранилище (OrientDB в старых установках или H2 в новых), и для него надёжнее всего работает холодный бэкап файловой системы, описанный ниже. Если видите jdbc:postgresql://... — добавляйте pg_dump в схему бэкапа отдельно от blob store.

Уточняйте точную версию и тип datastore именно на своём инсталляторе — Sonatype меняла умолчания между релизами, и то, что верно для одной версии 3.x, может отличаться в другой.

Холодный бэкап: самый надёжный способ

Какой бы движок БД ни стоял внутри, самый безопасный вариант — остановить сервис и снять снимок всей рабочей директории целиком. Blob store и база данных должны попадать в бэкап синхронно, иначе после восстановления можно получить записи в БД без файлов или файлы без записей.

Для установки через systemd:

sudo systemctl stop nexus
sudo tar -czf /backup/nexus-$(date +%F).tar.gz -C /opt sonatype-work
sudo systemctl start nexus

Для Docker Compose:

docker compose stop nexus
tar -czf /backup/nexus-$(date +%F).tar.gz -C /path/to/nexus-data .
docker compose start nexus

Простой на время бэкапа зависит от объёма blobs/ — для инсталляций на десятки-сотни гигабайт это может быть от пары минут до получаса. Если полная остановка неприемлема, есть компромисс: снимок на уровне файловой системы (LVM snapshot, ZFS snapshot или btrfs subvolume snapshot) без остановки сервиса, а уже с этого снимка — спокойно паковать архив. Это не гарантирует стопроцентную консистентность на уровне транзакции БД, но для большинства прод-сценариев Nexus такой риск приемлем, потому что запись метаданных и запись blob'ов в Nexus происходят близко друг к другу по времени.

Если у вас внешний PostgreSQL, добавьте к архиву дамп базы:

pg_dump -h localhost -U nexus -d nexus_db -F c -f /backup/nexus-db-$(date +%F).dump

Автоматизация бэкапа по расписанию

Ручной бэкап — это бэкап, которого не будет в нужный момент. Оформите его как systemd-таймер или cron-задачу с ротацией старых архивов.

Простой скрипт /usr/local/bin/nexus-backup.sh:

#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR=/backup/nexus
KEEP_DAYS=14
DATE=$(date +%F)

mkdir -p "$BACKUP_DIR"

systemctl stop nexus
tar -czf "$BACKUP_DIR/nexus-$DATE.tar.gz" -C /opt sonatype-work
systemctl start nexus

# удалить архивы старше KEEP_DAYS
find "$BACKUP_DIR" -name 'nexus-*.tar.gz' -mtime +$KEEP_DAYS -delete

chmod +x /usr/local/bin/nexus-backup.sh

Добавьте в crontab запуск в тихое время, когда меньше всего deploy'ев из CI:

0 3 * * * /usr/local/bin/nexus-backup.sh >> /var/log/nexus-backup.log 2>&1

Если у вас несколько репозиториев с высокой интенсивностью публикации (например, Docker registry и npm-registry для активной команды), стоит проверить перед внедрением расписания, что окно бэкапа не пересекается с пиковыми часами CI — иначе задачи сборки будут падать по таймауту на docker push, пока Nexus остановлен.

Отдельно стоит держать резервную копию etc/ даже вне общего архива — потеря keystore для HTTPS означает, что после восстановления нужно будет заново настраивать сертификат, если сам файл не попал в бэкап.

Восстановление Nexus из бэкапа

Порядок действий одинаков что при переезде на новый сервер, что при аварийном восстановлении на том же.

# 1. Остановить сервис (если он ещё жив)
sudo systemctl stop nexus

# 2. Отвести старую директорию в сторону (не удалять сразу — на случай если бэкап окажется неполным)
sudo mv /opt/sonatype-work /opt/sonatype-work.old

# 3. Распаковать архив
sudo tar -xzf /backup/nexus-2026-08-20.tar.gz -C /opt

# 4. Владельца и права — частая причина, почему сервис не стартует после восстановления
sudo chown -R nexus:nexus /opt/sonatype-work

# 5. Запустить и следить за логом
sudo systemctl start nexus
sudo tail -f /opt/sonatype-work/nexus3/log/nexus.log

Если восстанавливали дамп PostgreSQL отдельно от файлового архива:

dropdb -U postgres nexus_db
createdb -U postgres -O nexus nexus_db
pg_restore -h localhost -U nexus -d nexus_db /backup/nexus-db-2026-08-20.dump

После старта проверьте базовые вещи вручную, не полагаясь только на «сервис поднялся»:

• зайдите в веб-интерфейс и откройте один-два репозитория — видны ли компоненты;
• скачайте один известный артефакт через curl или mvn dependency:get — реально ли он отдаётся, а не просто числится в списке;
• проверьте docker pull из приватного registry, если он у вас настроен;
• посмотрите вкладку Tasks — переиндексация может понадобиться, если восстанавливали не строго синхронный снимок.

Если что-то не сходится (компонент есть в списке, а скачать не получается), это почти всегда означает рассинхронизацию между копией БД и копией blob store — например, бэкап файлов снят раньше, чем бэкап базы, или наоборот. Отсюда и важность холодного бэкапа: он снимает оба слоя одним движением.

Хранение бэкапов вне сервера и шифрование

Бэкап на том же диске, что и сам Nexus, защищает от порчи данных, но не от отказа диска или сервера целиком. Архив стоит увозить на отдельное хранилище — S3-совместимое, MinIO у себя или другой сервер.

Быстрый вариант с rclone после локального архивирования:

rclone copy /backup/nexus/nexus-$(date +%F).tar.gz remote:nexus-backups/ --progress

Более гибкий вариант — restic, который делает дедупликацию и шифрование «из коробки», что особенно полезно для больших blob store, где между бэкапами меняется небольшая доля файлов:

restic -r s3:https://s3.example.com/nexus-backups init
restic -r s3:https://s3.example.com/nexus-backups backup /opt/sonatype-work
restic -r s3:https://s3.example.com/nexus-backups forget --keep-daily 7 --keep-weekly 4 --prune

Если снимаете бэкап без предварительной остановки Nexus (например, через файловую систему в снапшоте), restic и rclone работают с уже статичным снимком, а не с «живым» каталогом — это снимает риск получить бэкап артефактов в момент их дозаписи. Сравнение самих инструментов бэкапа разобрано отдельно в статье restic или BorgBackup — что выгоднее и когда.

Если рядом с Nexus у вас уже крутится MinIO как S3-совместимое хранилище (частая связка для offsite-бэкапов на своей инфраструктуре), обязательно бэкапьте и его — иначе резервная копия Nexus окажется на хранилище, у которого своих бэкапов нет; подробности — в статье про бэкап и восстановление MinIO.

Не забывайте про шифрование при передаче в облако — если S3-бакет утечёт, содержимое приватного Docker registry или npm-репозитория с внутренним кодом не должно читаться напрямую. restic шифрует данные локально до отправки, это избавляет от необходимости доверять шифрование стороне, куда уходит бэкап.

Частые вопросы