Резервное копирование и восстановление Jira

Резервное копирование — это одна из тех вещей, которые кажутся скучными, пока не произойдёт катастрофа. За годы работы я помогал восстанавливать Jira после различных инцидентов: от случайного удаления данных до полного отказа сервера. Опыт показал: правильная стратегия бэкапов и знание процедур восстановления — это не просто "best practice", это критично для выживания системы. В этой статье разберу практические подходы.

Что нужно бэкапить в Jira

Jira состоит из нескольких компонентов, каждый из которых требует отдельного подхода к резервному копированию:

База данных — все данные задач, пользователей, настроек
Home directory — файлы приложения, индексы, логи, плагины
Attachments — вложения к задачам (могут быть в БД или в файловой системе)
Конфигурация сервера — если используется внешний сервер приложений

Для полного восстановления нужны все компоненты. Если что-то потеряно, восстановление будет неполным.

База данных — самое важное

База данных содержит всю бизнес-логику Jira: задачи, комментарии, workflow, настройки проектов, пользователей. Потеря базы данных — это потеря всех данных. Поэтому бэкап БД критичен.

Для разных СУБД используются разные инструменты бэкапа:

PostgreSQL — pg_dump или pg_basebackup
MySQL/MariaDB — mysqldump или Percona XtraBackup
Oracle — RMAN или Data Pump
SQL Server — встроенные инструменты бэкапа

Home directory

Home directory содержит конфигурацию Jira, индексы поиска, логи, установленные плагины. Без него Jira не запустится даже с восстановленной базой данных.

Бэкап home directory обычно делается через стандартные инструменты файловой системы: tar, rsync или инструменты бэкапа на уровне ОС.

Стратегии резервного копирования

Не существует универсальной стратегии бэкапов, которая подходит всем. Выбор зависит от размера инстанса, требований к RPO (Recovery Point Objective) и RTO (Recovery Time Objective).

Полный бэкап

Полный бэкап включает базу данных и home directory. Это самый простой и надёжный способ, но он требует больше времени и места.

Когда использовать: для небольших и средних инстансов, когда можно позволить остановку Jira на время бэкапа, или когда используется репликация для горячего бэкапа.

Частота: обычно делается раз в день, в нерабочее время. Для критичных систем может быть несколько раз в день.

Инкрементальный бэкап

Инкрементальный бэкап сохраняет только изменения с последнего полного бэкапа. Это экономит место и время, но усложняет процедуру восстановления.

Когда использовать: для больших инстансов, где полный бэкап занимает много времени, или когда ограничено место для хранения бэкапов.

Важно: при инкрементальном бэкапе важно регулярно делать полные бэкапы (например, раз в неделю) и тестировать восстановление, так как оно сложнее.

Непрерывное резервное копирование (WAL archiving)

Для PostgreSQL можно настроить непрерывную архивацию WAL (Write-Ahead Log). Это позволяет восстановиться на любой момент времени с точностью до транзакции.

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

Использование встроенных инструментов Jira

Jira имеет встроенную функциональность для экспорта данных: System → Backup System. Это удобный инструмент, но у него есть ограничения.

Преимущества встроенного бэкапа

Простота использования — не требует знания SQL или файловой системы
Создаёт согласованный снимок — база данных и attachments в одном файле
Работает через веб-интерфейс

Недостатки встроенного бэкапа

Требует остановки Jira на время бэкапа (для полного бэкапа)
Может быть медленным для больших инстансов
Не поддерживает инкрементальные бэкапы
Не даёт такого контроля, как инструменты БД

Рекомендация: используйте встроенный бэкап как дополнительный инструмент, но не как единственный способ резервного копирования. Для production-систем лучше использовать нативные инструменты базы данных.

Автоматизация бэкапов

Ручное создание бэкапов ненадёжно — можно забыть, пропустить, сделать ошибку. Бэкапы должны быть автоматизированы.

Скрипты для бэкапа

Вот пример скрипта для автоматического бэкапа PostgreSQL и home directory:

#!/bin/bash
BACKUP_DIR="/backup/jira"
DATE=$(date +%Y%m%d_%H%M%S)
JIRA_HOME="/opt/atlassian/jira/home"
DB_NAME="jira"
DB_USER="jira_user"

# Бэкап базы данных
pg_dump -U $DB_USER -F c -b -f "$BACKUP_DIR/jira_db_$DATE.backup" $DB_NAME

# Бэкап home directory
tar -czf "$BACKUP_DIR/jira_home_$DATE.tar.gz" -C /opt/atlassian/jira home

# Удаление старых бэкапов (старше 30 дней)
find $BACKUP_DIR -name "*.backup" -mtime +30 -delete
find $BACKUP_DIR -name "*.tar.gz" -mtime +30 -delete

Этот скрипт можно запускать через cron ежедневно. Важно настроить ротацию бэкапов, чтобы не закончилось место на диске.

Мониторинг бэкапов

Автоматизация бэкапов бесполезна, если не знать, что они успешны. Настройте мониторинг:

Проверка успешности выполнения скрипта бэкапа
Проверка размера файлов бэкапа (слишком маленький файл — признак проблемы)
Уведомления об ошибках бэкапа
Периодическая проверка целостности бэкапов (попытка восстановления)

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

Восстановление Jira — это критичная операция, которую нужно выполнять быстро и правильно. Лучший способ подготовиться — регулярно тренироваться на тестовой среде.

Восстановление из полного бэкапа

Процедура восстановления зависит от типа бэкапа, но общий алгоритм такой:

Остановите Jira
Восстановите базу данных из бэкапа
Восстановите home directory (или очистите и восстановите)
Проверьте конфигурацию (пути, подключение к БД)
Запустите Jira
Проверьте, что всё работает

Важно: при восстановлении на другой сервер или после изменения конфигурации может потребоваться обновление путей в базе данных. Это особенно актуально для путей к attachments.

Восстановление на другой сервер

Иногда нужно восстановить Jira на другой сервер (например, при миграции или аварийном восстановлении). Процедура сложнее:

Установите Jira на новом сервере (той же версии, что была при бэкапе)
Восстановите базу данных
Восстановите home directory
Обновите пути в jira-config.properties (путь к home, путь к БД)
Обновите пути к attachments в базе данных, если они хранятся в файловой системе
Переиндексируйте Jira (может занять время)
Проверьте работу

Частичное восстановление

Иногда нужно восстановить не всю Jira, а только часть данных (например, один проект или удалённые задачи). Это более сложная операция, требующая работы с базой данных на уровне SQL.

Для частичного восстановления:

Восстановите бэкап на временную БД
Экспортируйте нужные данные через Jira API или SQL
Импортируйте данные в production через API или SQL (осторожно!)

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

Хранение бэкапов

Бэкапы должны храниться отдельно от основного сервера. Если сервер выйдет из строя, бэкапы на нём тоже будут потеряны.

Локальное хранилище

Хранение бэкапов на отдельном диске или сервере в той же локации — лучше, чем ничего, но не защищает от локальных катастроф (пожар, наводнение, кража).

Удалённое хранилище

Бэкапы должны копироваться в удалённое хранилище: другой дата-центр, облачное хранилище (S3, Azure Blob). Это защищает от локальных катастроф.

При использовании облачного хранилища важно:

Шифровать бэкапы (особенно если там есть персональные данные)
Настроить правильные права доступа
Использовать разные регионы для репликации (если критично)
Учитывать стоимость хранения (облачное хранилище может быть дорогим для больших бэкапов)

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

Бэкап бесполезен, если восстановление не работает. Регулярно тестируйте процедуру восстановления.

Частота тестирования

Рекомендую тестировать восстановление:

Ежемесячно — полное восстановление на тестовую среду
Ежеквартально — восстановление на другой сервер (имитация аварийного восстановления)
После значительных изменений — обновления, изменения конфигурации

Что проверять при тестировании

Восстановление завершается успешно
Jira запускается и работает
Все данные присутствуют (задачи, пользователи, настройки)
Attachments открываются
Поиск работает
Плагины работают
Время восстановления приемлемо (RTO)

Типичные ошибки

Вот ошибки, которые я часто вижу при настройке бэкапов:

Ошибка 1: Бэкапы не тестируются

Самая частая ошибка — бэкапы создаются регулярно, но никогда не тестируются на восстановление. Когда приходит время восстанавливаться, выясняется, что бэкап повреждён или процедура восстановления не работает.

Ошибка 2: Бэкапы хранятся на том же сервере

Если сервер выйдет из строя, бэкапы на нём тоже будут потеряны. Всегда храните бэкапы отдельно от основного сервера.

Ошибка 3: Отсутствие ротации бэкапов

Без ротации бэкапы накапливаются и занимают всё доступное место. Настройте автоматическое удаление старых бэкапов.

Ошибка 4: Игнорирование attachments

Если attachments хранятся в файловой системе (а не в БД), не забывайте их бэкапить. Восстановленная база данных с задачами бесполезна, если нет вложений.

Специфика Data Center

В Jira Data Center процедура бэкапа усложняется наличием нескольких узлов. Но есть и преимущества: можно делать бэкап с одного узла, не останавливая весь кластер.

Для Data Center рекомендую:

Делать бэкап базы данных (она общая для всех узлов)
Делать бэкап shared home (общий для всех узлов)
Не нужно бэкапить local home каждого узла (он регенерируется)
Использовать репликацию БД для горячего бэкапа

Выводы

Резервное копирование — это не опция, а необходимость. Правильная стратегия бэкапов и регулярное тестирование восстановления критичны для защиты данных.

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

Помните: бэкап бесполезен, если восстановление не работает. Тестируйте восстановление регулярно, не дожидаясь реальной катастрофы.

Если нужна помощь с настройкой бэкапов — свяжитесь со мной.