Skip to main content

Сценарии аварийного восстановления

Описание

Ниже описаны типовые сценарии аварийного восстановления системы Printum: симптомы, порядок действий и ориентировочное время восстановления.

Для успешного восстановления системы обязательно иметь резервные копии Мониторинга и ПринтМенеджера(ов) в рабочем состоянии, созданные с помощью встроенного функционала резервного копирования или внешними средствами (например, снапшота\бэкапами на гипервизоре).

Сценарий 1: Отказ одного сервера ПринтМенеджера в конфигурации кластера

Симптомы

  • На панели администратора HAProxy один или несколько сервисов конкретного сервера ПМ отображаются как «DOWN» и подсвечены красным цветом.
  • Часть заданий печати, копирования и сканирования пользователей не обрабатывается устройствами под управлением печатью.

Порядок действий

  1. Проверьте статус контейнеров на отказавшем сервере:
cd /opt/printmanager && sudo docker-compose ps
  1. Соберите логи для последующей диагностики:
sudo /opt/printmanager/logs.sh
  1. Перезапустите контейнеры ПМ:
sudo docker-compose down
sudo docker-compose up -d
  1. Если работоспособность ПМ не вернулась, выполните его восстановление из резервной копии (см. «Резервное копирование и восстановление данных»).
  2. После восстановления проверьте состояние сервисов всех ПМ на странице панели администратора HAProxy.
  3. Проведите анализ собранных логов для установления причин отказа. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).

Ориентировочное время: 15–30 минут при перезапуске; 60–120 минут при восстановлении из резервной копии.

Сценарий 2 — Отказ нескольких серверов ПринтМенеджера

Симптомы

  • Большинство заданий печати, копирования и сканирования пользователей не обрабатываются не обрабатываются на устройствах под управлением печатью.
  • На панели администратора HAProxy менее половины узлов отображаются в статусе «UP» и отмечены зелёным цветом (кластер утратил кворум).

Порядок действий

  1. Восстановите сервера ПринтМенеджера, по описанию из сценария №1 (пункты 1-6).
  2. После восстановления:
    • Проверьте состояние сервисов всех ПМ на странице панели администратора HAProxy.
    • Проверьте успешность выполнения заданий печати, копирования и сканирования на устройствах под управлением печатью.
    • Проверьте работу синхронизации данных между Мониторингом и ПМ.
  3. Проведите анализ собранных логов для установления причин отказа. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).

Ориентировочное время: 60–240 минут в зависимости от числа отказавших узлов.

Сценарий 3 — Потеря базы данных PostgreSQL

Симптомы

  • Ошибки в логах ПМ: django.db.utils.OperationalError: connection to server failed
  • Веб-интерфейс Личного кабинета недоступен или отображает ошибки.

Порядок действий

  1. Убедитесь, что контейнер PostgreSQL запущен:
sudo docker ps | grep postgres
  1. Если контейнер не запущен — запустите его:
  • Для Мониторинга
cd /opt/printum
sudo docker-compose up -d postgres
  • Для ПМ
cd /opt/printmanager
sudo docker-compose up -d db
  1. Если возникают ошибки — соберите логи работы контейнеров и выполните восстановление из резервной копии:
sudo /opt/printum/logs.sh
#или
sudo /opt/printmanager/logs.sh
  1. Для восстановления на чистый сервер выполните команды из раздела «Восстановление резервных копий» на странице «Резервное копирование и восстановление данных».
  2. Подождите несколько минут для запуска системы.
  3. Проведите анализ собранных логов для установления причин отказа базы данных. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).

Ориентировочное время: 30–120 минут в зависимости от объёма данных.

Важно: IP-адрес или hostname сервера должны совпадать с теми, что были при создании резервной копии.

Сценарий 4 — Потеря NFS-хранилища (кластер)

Симптомы

  • Пользователи при попытке печати, копирования и сканирования заданий на устройствах под управлением печатью получают ошибку «Файл недоступен».
  • Логи ПринтМенеджера содержат ошибки обращения к NFS-директории.

Порядок действий

  1. Проверьте доступность NFS-сервера с сервера ПМ: вручную создайте тестовый файл на NFS-сервере:
cd /opt/printmanager
sudo docker-compose exec app touch /opt/app/public/media/test.txt
  1. Убедитесь в правильности параметров DRIVER_OPTS_DEVICE, DRIVER_OPTS_O, DRIVER_OPTS_TYPE для NFS-сервера в файле конфигурации ПМ:
sudo cat /opt/printmanager/.env
  1. Соберите логи работы ПМ для последующей диагностики:
sudo /opt/printmanager/logs.sh
  1. Выполните восстановление NFS-сервера из резервной копии. После восстановления перезапустите контейнеры ПМ:
cd /opt/printmanager
sudo docker-compose down
sudo docker-compose up -d
  1. Проверьте, что задания в отложенной очереди печати, копирования и сканирования обрабатываются корректно.
  2. Проведите анализ собранных логов для установления причин отказа базы данных. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).

Ориентировочное время: 15–60 минут.

Связанные страницы

Back to top