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

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

Предусловия

Шаги

  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> — пароль шифрования, использованный при установке системы.

Важно

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

Проверка

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

Назначение

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

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

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

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

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

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

  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
Нет синхронизацииМониторинг
Контейнеры unhealthyPostgreSQL
Нет печатиHAProxy
Нет статистикиsync queue

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

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

Описание

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

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

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

Симптомы

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

  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 — Отказ нескольких серверов ПринтМенеджера

Симптомы

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

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

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

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

Симптомы

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

  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-хранилища (кластер)

Симптомы

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

  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 минут.

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

Проверка резервных копий

Назначение

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

Проверка наличия и целостности архива

  1. Убедиться, что файл резервной копии существует в указанном хранилище.

  2. Проверить, что архив не повреждён (размер ненулевой и соответствует ожидаемому).

  3. Распаковать архив вручную для проверки содержимого:

     sudo tar tzvf printum_backup_<date>.tar.gz | head -50

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

  1. Подготовить тестовый сервер с теми же IP-адресом/hostname, что и у рабочего сервера.

  2. Перенести архив резервной копии на тестовый сервер.

  3. Распаковать архив и запустить восстановление:

     sudo tar xzvf printum_backup_<date>.tar.gz
 sudo printum_backup_<date>/restore.sh

  4. После сообщения «Restoration complete» подождать несколько минут.

  5. Проверить работоспособность системы:

    • Открыть Личный кабинет — страница должна загружаться.
    • Проверить отображение устройств и пользователей.
    • Выполнить тестовую печать (при возможности).

  6. После проверки удалить тестовые данные:

    sudo rm -f printum_backup_<date>.tar.gz
sudo rm -fr printum_backup_<date>

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

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

sudo -E ENV_VAULT_PASSWORD=<password> /opt/printum/backup.sh /home/user/backup

Восстановление — также с паролем:

sudo -E ENV_VAULT_PASSWORD=<password> printum_backup_<date>/restore.sh

Что входит в резервную копию

Не копируется: Локальный агент мониторинга.

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

Откат после неудачного обновления

Назначение

Инструкция по откату системы Printum к предыдущей версии при сбое обновления.

Когда выполнять откат

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

Перед откатом убедитесь:

  1. Резервная копия была создана до обновления.

  2. Версии Мониторинга и ПМ, которые были до обновления, известны:

    cat /opt/printum/.version
cat /opt/printmanager/.version

  3. Резервная копия доступна и не повреждена.

Порядок отката

  1. Остановить текущие контейнеры:

    cd /opt/printum && sudo docker-compose down
cd /opt/printmanager && sudo docker-compose down

  2. Перенести резервную копию на сервер (если хранится внешне).

  3. Распаковать архив и запустить восстановление:

    sudo tar xzvf printum_backup_<date>.tar.gz
sudo printum_backup_<date>/restore.sh

  4. Подождать сообщение «Restoration complete».

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

  6. Проверить работоспособность: открыть Личный кабинет, проверить устройства и пользователей.

Что проверить после отката

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

При восстановлении с шифрованием использовать команду:

sudo -E ENV_VAULT_PASSWORD=<password> printum_backup_<date>/restore.sh

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