Раздел 3. Указания по восстановлению¶

3.1. Сохранение и восстановление данных¶

Восстановление BOX5-DIT-MGSN выполняется из заранее сохранённых копий конфигурации, данных, моделей и дистрибутива. Для целостного файлового восстановления резервная копия создаётся в технологическое окно: сначала фиксируется версия поставки, затем останавливаются сервисы, копируются данные и только после проверки архива сервисы запускаются снова.

Исходный Mermaid-код схемы: И2-MER-003. 3.1. Сохранение и восстановление данных.

3.1.1. Состав резервной копии¶

3.1.2. Порядок сохранения¶

1. Зафиксировать окружение, дату, версию поставки и список нод:

docker node ls
docker service ls

1. На мастер-ноде остановить кластер:

cd ~/CODE/box3
./utils/swarm/swarm.sh stop

1. На ноде песочницы остановить Node-RED sandbox, если он участвует в резервном копировании:

cd ~/CODE/node-red-sandbox
docker compose down

1. Сохранить конфигурацию и данные в архив площадки. Пример команд:

mkdir -p /data/backups/sova-$(date +%F)
rsync -a --numeric-ids ~/CODE /data/backups/sova-$(date +%F)/
rsync -a --numeric-ids /data/compose-data2 /data/backups/sova-$(date +%F)/
rsync -a --numeric-ids /data/sandbox-compose-data /data/backups/sova-$(date +%F)/
rsync -a --numeric-ids /data/models /data/backups/sova-$(date +%F)/
sudo cp /etc/systemd/system/box-restart.service /data/backups/sova-$(date +%F)/ || true

1. Проверить наличие архива, свободное место и контрольные суммы:

df -h
du -sh /data/backups/sova-$(date +%F)
find /data/backups/sova-$(date +%F) -type f -print0 | xargs -0 sha256sum \
  > /data/backups/sova-$(date +%F).sha256

1. Запустить кластер и песочницу:

cd ~/CODE/box3 && ./utils/swarm/swarm.sh start
cd ~/CODE/node-red-sandbox && docker compose up -d

1. Выполнить контроль после запуска: docker node ls, docker service ls, curl localhost, nvidia-smi на вычислительных нодах.

3.1.3. Порядок восстановления из резервной копии¶

Восстановление выполняется от меньшей области к большей. Если потерян один сервис, сначала проверяется возможность восстановления домена и его данных. При потере ноды или диска выполняется полное восстановление узла.

1. Подготовить целевой сервер: установить системное ПО, Docker, Docker Compose, NVIDIA driver и NVIDIA Container Toolkit в версиях, указанных в разделе 2, пункте 2.2.1.
2. На вычислительных нодах восстановить /etc/docker/daemon.json, отключить sleep/hibernate и проверить nvidia-smi.
3. Загрузить Docker-образы на каждую ноду:

docker load -i /data/update/dockerimg.tgz

1. Восстановить ~/CODE, каталог COMPOSE_DATA_SWARM_PATH, данные песочницы и модели из резервной копии:

rsync -a --numeric-ids /data/backups/<backup_id>/CODE/ ~/CODE/
sudo rsync -a --numeric-ids /data/backups/<backup_id>/compose-data2/ /data/compose-data2/
sudo rsync -a --numeric-ids /data/backups/<backup_id>/sandbox-compose-data/ /data/sandbox-compose-data/
sudo rsync -a --numeric-ids /data/backups/<backup_id>/models/ /data/models/
sudo chown -R 1000:1000 /data/models /data/sandbox-compose-data

1. Проверить в ~/CODE/box3/utils/swarm/swarm.sh, что COMPOSE_DATA_SWARM_PATH указывает на восстановленный каталог /data/compose-data2.
2. Проверить настройки песочницы в ~/CODE/node-red-sandbox/.env: COMPOSE_DATA_DIR, MLFLOW_MODELS_PATH, NRI_ASSETS_HOST_DIR, NGINX_HOST_PORT. В ~/CODE/box3/ui-rest/ui-config/config.json проверить SCENARIOS_FRAME_URL.
3. Восстановить или повторно выполнить оффлайн-активацию Guardant. Если сервер или состояние /var/guardant изменились, старый request-файл не используется: сформировать новый запрос через curl http://localhost:19191/get_request и загрузить новый ответ активации по процедуре раздела 2, пункта 2.2.4.
4. Инициализировать или восстановить Docker Swarm:

docker swarm init --advertise-addr <IP-адрес_мастер-ноды>
docker swarm join --token <token> <master_ip>:2377

1. Назначить лейблы нод db, rest, inference, а для ноды песочницы также nr_sandbox, flows_manager, events_validator.

2. Запустить кластер и песочницу:

   cd ~/CODE/box3 && ./utils/swarm/swarm.sh start
   cd ~/CODE/node-red-sandbox && docker compose up -d
   

3. При восстановлении моделей выполнить проверочную конвертацию и выгрузку моделей в хранилище:

   docker exec -it $(docker ps | grep nr-sbx-nri | awk '{print $1}' | head -n1) bash
   python3 -m nri.mlflow.tools.convert_all_models --models_filter_path /models/sel-models.csv
   exit
   

4. Выполнить контрольный чек-лист раздела 2, пункта 2.4.1.

3.1.4. Контроль успешности восстановления¶

3.2. Действия при сбоях¶

При сбоях администратор действует по принципу локализации: сначала определить границы отказа, затем остановить только затронутый контур, восстановить данные или конфигурацию и выполнить чек-лист. Ручное изменение файлов внутри контейнеров не считается штатным способом восстановления, так как изменения теряются при пересоздании контейнеров.

3.2.1. Первичная диагностика¶

1. Проверить состояние нод и сервисов:

docker node ls
docker service ls
docker node ps --no-trunc <node_hostname>

1. Проверить свободное место и крупные каталоги:

df -h
ncdu /data

1. Проверить web-доступ и nginx:

curl localhost
docker logs bx_ui-nginx.1.<service_id> --tail 200

1. На вычислительных нодах проверить GPU и runtime:

nvidia-smi
cat /etc/docker/daemon.json

1. Проверить лейблы нод:

docker node ls -q | xargs docker node inspect \
  -f '{{ .ID }} [{{ .Description.Hostname }}]: {{ .Spec.Labels }}'

3.2.2. Типовые сбои и действия администратора¶

3.2.3. Восстановление после полной потери ноды¶

1. Установить ОС и системные зависимости по требованиям раздела 2.
2. Восстановить Docker, Docker Compose, NVIDIA driver и NVIDIA Container Toolkit, если нода вычислительная.
3. Загрузить dockerimg.tgz, восстановить /data/compose-data2, /data/models и при необходимости /data/sandbox-compose-data.
4. На мастер-ноде получить актуальную команду присоединения:

docker swarm join-token worker

1. Присоединить заменённую ноду к swarm, назначить прежние лейблы и запустить кластер.
2. Проверить задачи на восстановленной ноде:

docker node ps --no-trunc <node_hostname>

3.2.4. Эскалация¶

Администратор эскалирует сбой ответственному DevOps/VizorLabs, если:

• восстановление из последней резервной копии не запускает сервисы;
• потеряны или повреждены данные БД/MinIO без актуальной резервной копии;
• Guardant не принимает оффлайн-ответ или не поднимает порт 19191;
• ошибка затрагивает интеграцию с ПК-КОТ в PROD;
• повторный запуск моделей или конвертация завершаются одинаковой ошибкой.

В обращении фиксируются окружение, время сбоя, выполненные команды, состояние docker node ls, docker service ls, проблемные строки логов и версия поставки. Чувствительная информация, включая полные .env-файлы, пароли, токены и лицензии, в обращение не включается.