Восстановление

• Восстановление из резервной копии
• Восстановление при шифровании конфигурационного файла
• Восстановление Принтум из резервной копии
• Сценарии аварийного восстановления

Восстановление из резервной копии

Предусловия

• восстанавливать резервную копию нужно на чистый сервер
• IP-адрес или доменное имя сервера должны совпадать с тем, которое было на момент создания копии
• операционная система не должна меняться
• Свободное место ≥ размер архива резервной копии

Шаги

1. Переместите архив на целевой сервер.
2. Разархивируйте архив и запустите процесс восстановления, с помощью следующих команд:

sudo tar xzvf printum_backup_date-month-day_hour-minute.tar.gz

sudo printum_backup_date-month-day_hour-minute/restore.sh

где
printum_backup_date-month-day_hour-minute.tar.gz – название архива, printum_backup_date-month-day_hour-minute – название распакованной директории из архива

Результат

После успешного восстановления выводится: Restoration complete

Подождите несколько минут для запуска системы.

Проверка

• Корректность отображения данных принтеров в ЛК.
• Загрузка страниц технических кабинетов Мониторинга и ПМ.
• Работа печати, копирования и сканирования.

Очистка

После подтверждения работоспособности системы удалите архив и распакованную папку для экономии места:

sudo rm -f printum_backup_date-month-day_hour-minute.tar.gz
sudo rm -fr printum_backup_date-month-day_hour-minute

Восстановление при шифровании конфигурационного файла

Описание

Если конфигурационный файл зашифрован, восстановление должно выполняться с указанием пароля шифрования.

Шаги

Вместо стандартной команды восстановления используйте:

sudo -E ENV_VAULT_PASSWORD=<password> printum_backup_date-month-day_hour-minute/restore.sh

Где <password> — пароль шифрования, использованный при установке системы.

Важно

Указание правильного пароля критически важно для успешного восстановления зашифрованных данных.

Проверка

• Корректность отображения данных принтеров в ЛК.
• Загрузка страниц технических кабинетов Мониторинга и ПМ.
• Работа печати, копирования и сканирования.

Восстановление Принтум из резервной копии

Назначение

Инструкция описывает порядок восстановления Принтум после отказа серверов, повреждения инфраструктуры, потери данных или критических инцидентов.

Когда требуется восстановление

• Отказ NFS, HAProxy, Мониторинга или одного сервера ПринтМенеджера;
• Повреждение PostgreSQL;
• Потеря NFS;
• Повреждение Docker volumes;
• Критический отказ системы (2 и более серверов).

Основной принцип

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

Порядок восстановления

Восстановление выполняется строго по следующему порядку:

1. Сервер Мониторинга
2. Сервер базы данных ПринтМенеджера
3. Сервер NFS-хранилища ПринтМенеджера
4. Сервер балансировщика HAProxy
5. Сервер ПринтМенеджера №1
6. Сервер ПринтМенеджера №2
7. Сервер ПринтМенеджера №3
8. Сервер ПринтМенеджера №N

Шаг 1. Мониторинг

Сначала восстанавливается сервер Мониторинга — он используется как центральная конфигурация, источник пользователей и устройств.

Шаг 2. Сервер базы данных

Восстановить PostgreSQL. Проверить: запуск сервиса, доступность порта, корректность данных. При отказе сервера базы данных после восстановления — перезапустить все сервисы СУП на серверах ПринтМенеджера.

Шаг 3. NFS-хранилище

Восстановить NFS storage и stunnel. Проверить: export, mount, доступность volumes.

Шаг 4. HAProxy

Восстановить балансировщик. Проверить: healthcheck, backend status, routing.

Шаг 5. Серверы ПринтМенеджера

Восстановить все ноды ПринтМенеджера. После запуска:

cd /opt/printmanager
docker-compose down
docker-compose up -d

Проверить sync и очереди.

Контрольные проверки после восстановления

Проверка веб-интерфейсов

Проверить доступность: Личного кабинета, панелей администратора, Встроенных приложений на МФУ.

Проверка статусов HAProxy

Убедиться, что статусы всех компонентов в панели администратора HAProxy — ярко-зелёные.

Проверка Docker-контейнеров

На всех серверах Мониторинга и ПринтМенеджера:

docker ps

Проверить: нет restart loop, нет exited containers, нет unhealthy status.

Проверка авторизации

Проверить авторизацию пользователей в Личном кабинете и Встроенных приложениях на МФУ, а также LDAP/SSO и RFID-авторизацию.

Проверка синхронизации

Проверить доменную синхронизацию в Мониторинге. Проверить синхронизацию данных Мониторинга и ПринтМенеджера.

Проверка печати

Проверить: direct print, release print, queue processing, статистику, копирование и сканирование во Встроенных приложениях.

Типовые проблемы

Симптом	Возможная причина
ПринтМенеджер не запускается	NFS
Нет синхронизации	Мониторинг
Контейнеры unhealthy	PostgreSQL
Нет печати	HAProxy
Нет статистики	sync queue

Что важно помнить

• Порядок восстановления критически важен.
• NFS и PostgreSQL — ключевые зависимости.
• После восстановления требуется проверка синхронизации.
• После аварии статистика может догружаться постепенно.

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

Описание

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

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

---

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

Симптомы

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

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

1. Проверьте статус контейнеров на отказавшем сервере:

cd /opt/printmanager && sudo docker-compose ps

2. Соберите логи для последующей диагностики:

sudo /opt/printmanager/logs.sh

3. Перезапустите контейнеры ПМ:

sudo docker-compose down
sudo docker-compose up -d

4. Если работоспособность ПМ не вернулась, выполните его восстановление из резервной копии (см. «Резервное копирование и восстановление данных»).
5. После восстановления проверьте состояние сервисов всех ПМ на странице панели администратора HAProxy.
6. Проведите анализ собранных логов для установления причин отказа. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку 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

2. Если контейнер не запущен — запустите его:

• Для Мониторинга

cd /opt/printum
sudo docker-compose up -d postgres

• Для ПМ

cd /opt/printmanager
sudo docker-compose up -d db

3. Если возникают ошибки — соберите логи работы контейнеров и выполните восстановление из резервной копии:

sudo /opt/printum/logs.sh
#или
sudo /opt/printmanager/logs.sh

4. Для восстановления на чистый сервер выполните команды из раздела «Восстановление резервных копий» на странице «Резервное копирование и восстановление данных».
5. Подождите несколько минут для запуска системы.
6. Проведите анализ собранных логов для установления причин отказа базы данных. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку 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

2. Убедитесь в правильности параметров DRIVER_OPTS_DEVICE, DRIVER_OPTS_O, DRIVER_OPTS_TYPE для NFS-сервера в файле конфигурации ПМ:

sudo cat /opt/printmanager/.env

3. Соберите логи работы ПМ для последующей диагностики:

sudo /opt/printmanager/logs.sh

4. Выполните восстановление NFS-сервера из резервной копии. После восстановления перезапустите контейнеры ПМ:

cd /opt/printmanager
sudo docker-compose down
sudo docker-compose up -d

5. Проверьте, что задания в отложенной очереди печати, копирования и сканирования обрабатываются корректно.
6. Проведите анализ собранных логов для установления причин отказа базы данных. По возможности, устраните их самостоятельно для предупреждения повторения проблемы в будущем или обратитесь в техническую поддержку Printum (support@printum.io).

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

---

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

• Резервное копирование и восстановление данных