Резервное копирование и перенос Weblate¶

Автоматическое резервное копирование с помощью BorgBackup¶

Добавлено в версии 3.9.

В Weblate встроена поддержка создания сервисных резервных копий с помощью BorgBackup. Borg создаёт компактные зашифрованные резервные копии, которые можно безопасно хранить в облаке. Управлять резервными копиями можно через интерфейс управления на вкладке Резервные копии.

Предупреждение

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

Резервные копии, которые делает Borg, являются инкрементальными, и Weblate настроен на сохранение следующих резервных копий:

14 ежедневных резервных копий
8 еженедельных резервных копий
6 ежемесячных резервных копий

Ключ шифрования Borg¶

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

В случае, если вы используете хранилище резервных копий на Weblate.org, пожалуйста, сделайте резервную копию вашего закрытого SSH-ключа — он используется для доступа к вашим резервным копиям.

См.также

borg init

Предоставляемое Weblate’ом хранилище резервных копий¶

Простейший подход к резервному копированию вашего экземпляра Weblate заключается в покупке сервиса резервного копирования на weblate.org. Процесс активации резервного копирования выполняется в несколько шагов:

Покупка услуги резервного копирования на https://weblate.org/support/#backup.
Ввод полученного ключа в интерфейсе управления, смотрите раздел Integrating support.
Weblate подключится к облачному сервису и получит информацию для доступа к резервным копиям.
Включение новой конфигурации резервного копирования на вкладке Резервные копии.
Резервное копирование учётных данных Borg, чтобы иметь возможность восстанавливать резервные копии, смотрите раздел Ключ шифрования Borg.

Подсказка

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

Использование собственного хранилища резервных копий¶

Также вы можете использовать своё собственное хранилище для резервного копирования. Загрузка резервных копий на удаленный сервер может осуществляться через SSH, на целевом сервере должен быть установлен BorgBackup.

См.также

Раздел Общие сведения в документации Borg

Локальная файловая система¶

Для локальной резервной копии рекомендуется указывать абсолютный путь, например /путь/к/резервной_копии. Каталог должен быть доступен на запись для пользователя, под которым запущен Weblate (смотрите раздел Разрешения файловой системы). В случае, если каталог не существует, Weblate попытается его создать, но для этого ему понадобятся разрешения.

Подсказка

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

Одним из вариантов является размещение резервных копий в существующем томе. Подойдёт, к примеру, /app/data/borgbackup. Это существующий том в контейнере.

Также вы можете добавить в файл compose Docker’а новый контейнер для резервных копий и использовать, например, путь /borgbackup:

services:
  weblate:
    volumes:
      - /home/weblate/data:/app/data
      - /home/weblate/borgbackup:/borgbackup

The directory where backups will be stored have to be owned by UID 1000, otherwise Weblate will not be able to write the backups there.

Удалённые резервные копии¶

Поддерживается удалённое резервное копирование с помощью SSH. На SSH-сервере должен быть установлен BorgBackup. Weblate подключается к серверу, используя ключ SSH, пожалуйста, убедитесь, что Weblate’овский ключ SSH принимается сервером (смотрите раздел SSH-ключ Weblate).

Подсказка

Предоставляемое Weblate’ом хранилище резервных копий предоставляет вам автоматическое удалённое резервное копирование.

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

Восстановите доступ к своему репозиторию резервных копий и подготовьте свою парольную фразу для резервного копирования.
Получите список существующих на сервере резервных копий с помощью команды borg list РЕПОЗИТОРИЙ.
Восстановите нужную резервную копию в текущий каталог с помощью команды borg extract РЕПОЗИТОРИЙ::АРХИВ.
Восстановите базу данных из SQL-дампа, размещённого в каталоге backup каталога данных Weblate (смотрите раздел Дампы данных для резервного копирования).
Скопируйте конфигурацию Weblate (backups/settings.py, смотрите раздел Дампы данных для резервного копирования) в нужное место, смотрите раздел Настройка конфигурации.
Скопируйте весь восстановленный каталог данных в место, заданное параметром DATA_DIR.

Сеанс Borg может выглядеть так:

$ borg list /tmp/xxx
Enter passphrase for key /tmp/xxx:
2019-09-26T14:56:08                  Thu, 2019-09-26 14:56:08 [de0e0f13643635d5090e9896bdaceb92a023050749ad3f3350e788f1a65576a5]
$ borg extract /tmp/xxx::2019-09-26T14:56:08
Enter passphrase for key /tmp/xxx:

См.также

borg list, borg extract

Ручное резервное копирование¶

В зависимости от того, что вы хотите сохранить, создайте резервную копию типов данных, которые Weblate сохраняет в соответствующих местах.

Подсказка

Если вы выполняете резервное копирование вручную, вы можете подавить предупреждение Weblate об отсутствии резервного копирования, добавив проверку weblate.I028 к параметру SILENCED_SYSTEM_CHECKS в settings.py или к переменной окружения WEBLATE_SILENCED_SYSTEM_CHECKS Docker’а.

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

База данных¶

Фактическое расположение хранилища зависит от настроек вашей базы данных.

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

Встроенные средства базы данных для резервного копирования¶

Рекомендуемый подход заключается в создании дампа базы данных с помощью родных для базы данных инструментов, таких как pg_dump или mysqldump. Обычно он работает лучше, чем резервная копия Django, и восстанавливает полные таблицы со всеми данными.

Эту резервную копию вы можете восстановить в новом выпуске Weblate, при запуске через migrate он выполнит все необходимые миграции. За более подробной информацией о том, как выполнить обновление между версиями обратитесь, пожалуйста, к разделу Обновление Weblate.

Резервное копирование базы данных средствами Django¶

В качестве альтернативы вы можете создать резервную копию базы данных при помощи Django’вской команды dumpdata. Резервное копирование этим способом не зависит от базы данных и может быть использовано в случае, если вы захотите сменить базу данных.

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

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

weblate shell
>>> from weblate.auth.models import User
>>> User.objects.get(username='anonymous').delete()

Файлы¶

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

Дампы данных для резервного копирования¶

Хранятся в DATA_DIR /backups.

Weblate сбрасывает сюда различные данные, и для создания более полных резервных копий вы можете включить эти файлы. Файлы обновляются ежедневно (требуется отдельный запущенный сервер Celery beat, смотрите раздел Фоновые задачи с использованием Celery). В настоящее время здесь хранятся:

Настройки Weblate в виде файла settings.py (также здесь под именем settings-expanded.py лежит обработанная версия этого файла).
Резервная копия базы данных PostgreSQL в виде файла database.sql.

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

Репозитории системы контроля версий¶

Хранятся в DATA_DIR /vcs.

Репозитории системы контроля версий содержат копии ваших вышестоящих репозиториев с изменениями из Weblate’а. Если вы включили для всех ваших компонентов перевода отправку изменений в вышестоящий репозиторий при коммите, в этот репозиторий включаются все изменения из Weblate’а, поэтому на стороне Weblate’а вам уже не нужно создавать резервные копии репозиториев. Они могут быть повторно склонированы из вышестоящих репозиториев без потери данных.

Ключи SSH и GPG¶

Хранятся в DATA_DIR /ssh и DATA_DIR /home.

Если вы используете сгенерированные Weblate ключи SSH или GPG, вы должны создать резервную копию этих каталогов, иначе вы потеряете закрытые ключи и вам придётся заново сгенерировать новые.

Загруженные пользователем файлы¶

Хранятся в DATA_DIR /media.

Вы должны сделать резервные копии загруженных пользователями файлов (например, визуальных контекстов для строк).

Задачи Celery¶

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

См.также

Фоновые задачи с использованием Celery

Командная строка для ручного резервного копирования¶

Используя задание в cron’е, вы можете задать команду bash’а, которая будет выполняться каждый день, например:

$ XZ_OPT="-9" tar -Jcf ~/backup/weblate-backup-$(date -u +%Y-%m-%d_%H%M%S).xz backups vcs ssh home media fonts secret

Строка между кавычками после XZ_OPT позволяет вам выбрать параметры для запуска xz, например, объём памяти, используемый для сжатия; смотрите руководство на странице https://linux.die.net/man/1/xz

Вы можете настроить список папок и файлов в соответствии со своими потребностями. Например, чтобы избежать сохранения памяти переводов (в папке резервных копий), вы можете использовать следующую команду:

$ XZ_OPT="-9" tar -Jcf ~/backup/weblate-backup-$(date -u +%Y-%m-%d_%H%M%S).xz backups/database.sql backups/settings.py vcs ssh home media fonts secret

Восстановление ручных резервных копий¶

Восстановите все данные, сохранённые вами в резервной копии.
Обновите все репозитории с помощью команды updategit.
```
weblate updategit --all
```

Перенос установки Weblate¶

Переместите свою установку на другую систему, следуя приведённым выше инструкциям по резервному копированию и восстановлению из резервной копии.

См.также

Обновление с Python’а 2 на Python 3, Переход с других баз данных на PostgreSQL