# План відновлення після катастроф

## Обсяг та цілі

Цей план стосується відновлення після катастрофічних подій, що впливають на доступність сервісу Weblate, цілісність даних або безперервність роботи.

#### NOTE
Цей план спеціально розроблений для розгортання Weblate компанією Weblate s.r.o., але його можна аналогічно застосувати до інших розгортань.

## Визначень

- **Лихо:** Будь-яка незапланована подія, що призводить до повної або значної втрати послуг, даних або функціональності системи. Прикладами є збій обладнання, пошкодження даних, збій інфраструктури або зловмисна атака.
- **Цільова точка відновлення (RPO):** Максимально допустимий інтервал втрати даних: **24 години**.
- **Цільовий час відновлення (RTO):** Максимально прийнятний час для відновлення повного сервісу: **8 годин**.

## Критичні компоненти

- **Рівень застосунку:** Застосунок Weblate на Python/Django, фонові виконавці (Celery) та заплановані завдання.
- **Рівень даних:** База даних PostgreSQL, репозиторії перекладів (Git) та журнали.
- **Інфраструктура:** Веб-сервер (NGINX/Apache), зворотний проксі-сервер, томи сховища, конфігурація SSL/TLS та додаткова система ведення журналу SIEM.

## Політика резервного копіювання

[Автоматичне створення резервних копій за допомогою BorgBackup](https://docs.weblate.org/uk/latest/admin/backup.md#automated-backup) гарантує, що всі основні компоненти (база даних, дані та конфігурація) щоденно створюють резервні копії. Резервні копії зберігаються у двох географічно різних місцях. Політика зберігання резервних копій гарантує, що останні резервні копії будуть доступні щодня і зберігатимуться протягом шести місяців.

## Процедури відновлення

<a id="drp-host"></a>

### Сценарій збою: повна втрата хоста/системи

1. Підготовка нового хоста.
2. Bootstrap Weblate з використанням програмного забезпечення для налаштування.
3. Відновлення резервної копії Weblate після [Відновлення з BorgBackup](https://docs.weblate.org/uk/latest/admin/backup.md#restore-borg).
4. Перезапустіть контейнер Weblate.
5. Перевірте функціональність та виконайте перевірки на узгодженість.

### Сценарій збою: пошкодження бази даних або втрата обсягу даних

1. Зупиніть Weblate, щоб запобігти подальшим операціям запису.
2. Відновлення резервної копії Weblate після [Відновлення з BorgBackup](https://docs.weblate.org/uk/latest/admin/backup.md#restore-borg).
3. Перезапустіть служби та перевірте узгодженість перекладу й даних користувача.

### Сценарій невдачі: зловмисне втручання або програма-вимагач

1. Ізолюйте уражений хост від мережі.
2. Визначити останню відому справну резервну копію (до зараження).
3. Виконайте кроки з [Сценарій збою: повна втрата хоста/системи](#drp-host), щоб розгорнути систему на новому хості.

## Валідація та тестування

- **Перевірка резервних копій:** Щомісячне тестування відновлення резервних копій Weblate.
- **Тренування з відновлення після аварій:** Проводьте принаймні щорічно, включаючи повне відновлення до проміжного середовища.
- **Автоматизовані перевірки цілісності:** BorgBackup забезпечує цілісність резервних копій архівів.

## Кроки після відновлення

- Переконайтеся, що всі служби працюють та доступні.
- Повідомляти користувачів та зацікавлених сторін про статус відновлення.
- Задокументуйте часову шкалу, першопричину та отримані уроки.
- Застосуйте оновлення або зміни інфраструктури, щоб запобігти повторенню.
- Дотримуйтесь [Політика розкриття інформації про вразливості](https://docs.weblate.org/uk/latest/security/issues.md#vulnerability-disclosure-policy) у випадку, якщо була задіяна вразливість.