# Восстановление # Восстановление из резервной копии ## Предусловия - восстанавливать резервную копию нужно на чистый сервер - 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= printum_backup_date-month-day_hour-minute/restore.sh ``` Где `` — пароль шифрования, использованный при установке системы. ## Важно Указание правильного пароля критически важно для успешного восстановления зашифрованных данных. ## Проверка - Корректность отображения данных принтеров в ЛК. - Загрузка страниц технических кабинетов Мониторинга и ПМ. - Работа печати, копирования и сканирования. # Восстановление Принтум из резервной копии ## Назначение Инструкция описывает порядок восстановления Принтум после отказа серверов, повреждения инфраструктуры, потери данных или критических инцидентов. ## Когда требуется восстановление - Отказ 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
Нет синхронизацииМониторинг
Контейнеры unhealthyPostgreSQL
Нет печати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. Если работоспособность ПМ не вернулась, выполните его восстановление из резервной копии (см. [«Резервное копирование и восстановление данных»](https://wiki.printum.io/books/6-obnovlenie-i-obsluzivanie/page/rezervnoe-kopirovanie-i-vosstanovlenie-dannyx)). 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. Для восстановления на чистый сервер выполните команды из раздела [«Восстановление резервных копий»](https://wiki.printum.io/link/186#bkmrk-%D0%92%D0%BE%D1%81%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B7%D0%B5%D1%80) на странице [«Резервное копирование и восстановление данных»](https://wiki.printum.io/books/6-obnovlenie-i-obsluzivanie/page/rezervnoe-kopirovanie-i-vosstanovlenie-dannyx). 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 минут. --- ## Связанные страницы - [Резервное копирование и восстановление данных](https://wiki.printum.io/books/6-obnovlenie-i-obsluzivanie/page/rezervnoe-kopirovanie-i-vosstanovlenie-dannyx)