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

## Описание

 Ниже описаны типовые сценарии аварийного восстановления системы 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)