Резервне копіювання і пересування Weblate

Автоматичне створення резервних копій за допомогою BorgBackup

Нове в версії 3.9.

У Weblate передбачено вбудовану підтримку створення резервних копій за допомогою BorgBackup. Borg створює шифровані резервні копії мінімального розміру, які можна безпечно зберігати у «хмарі». Керувати резервним копіюванням можна за допомогою інтерфейсу керування на вкладці Резервні копії.

Змінено в версії 4.4.1: До автоматичного резервного копіювання включено і базу даних PostgreSQL, і базу даних MySQL/MariaDB.

Резервні копії з використанням Borg є нарощувальними, а Weblate налаштовування на збереження таких резервних копій:

  • Щоденне резервне копіювання до 14 днів

  • Щотижневе резервне копіювання до 8 тижнів

  • Щомісячне резервне копіювання до 6 місяців

../_images/backups.png

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

BorgBackup створює зашифровані резервні копії. Без пароля ви не зможете відновити дані з резервної копії. Пароль створюється при додаванні нової служби резервного копіювання, вам слід скопіювати його і зберігати його у безпечному місці.

Якщо ви користуєтеся Передбачене у Weblate сховище резервних копій, будь ласка, включіть до резервного копіювання і ваш закритий ключ SSH — його буде використано для доступу до ваших резервних копій.

Дивись також

borg init

Передбачене у Weblate сховище резервних копій

Найпростішим способом резервного копіювання вашого екземпляра Weblate є придбання служби резервного копіювання на weblate.org. Активацію можна виконати за декілька кроків:

  1. Придбайте обслуговування із резервним копіюванням на https://weblate.org/support/#backup.

  2. Введіть отриманий ключ в інтерфейсі керування, див. Інтегрування підтримки.

  3. Weblate з’єднається із «хмарною» службою і отримати дані для доступу до резервних копій.

  4. Увімкніть нові налаштування резервного копіювання на вкладці Резервні копії.

  5. Створіть резервну копію реєстраційних даних Borg з метою уможливлення відновлення резервних копій, див. Ключ шифрування Borg.

Підказка

Крок вмикання усього вручну додано з метою убезпечення ваших даних. Без вашої згоди під час процедури реєстрації до сховища резервних копій не буде надіслано жодних даних.

Використання нетипового сховища резервних копій

Ви також можете скористатися власним сховищем для резервних копій. Для збереження резервних копій на віддаленому сервері можна скористатися SSH. На сервері сховища копій має бути встановлено BorgBackup.

Дивись також

General у документації до Borg

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

Рекомендуємо вказати абсолютний шлях до локальної резервної копії, наприклад /шлях/до/резервної/копії. Запис до каталогу має бути відкрито для користувача, від імені якого запущено Weblate (див. Права доступу у файловій системі). Якщо каталогу не існуватиме, Weblate спробує його створити, але програма повинна мати для цього відповідні права доступу.

Підказка

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

Одним із варіантів дій є розташування резервних копій на наявних томах. Наприклад, можна вибрати /app/data/borgbackup. Це наявний том у контейнері.

Ви також можете додати новий контейнер для резервних копій у файлі Docker Compose та скористатися, наприклад, /borgbackup:

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

Каталог, де зберігатимуться резервні копії, повинен належати UID 1000, інакше Weblate не зможе записати їх туди.

Віддалені резервні копії

Для створення віддалених резервних копій вам слід встановити на іншому доступному за допомогою SSH сервері BorgBackup. Переконайтеся, що він приймає клієнтський ключ Weblate, тобто ключ, який використовується для з’єднання з іншими серверами.

Підказка

Передбачене у Weblate сховище резервних копій надає вам доступ до автоматичного створення резервних копій на віддалених серверах.

Дивись також

Ключ SSH Weblate

Відновлення з BorgBackup

  1. Відновлення доступу до вашого сховища резервних копій і приготування вашого пароля до резервних копій.

  2. Отримайте список усіх резервних копій на сервері за допомогою команди borg list СХОВИЩЕ.

  3. Відновіть бажану резервну копію до поточного каталогу за допомогою команди borg extract СХОВИЩЕ::АРХІВ.

  4. Відновіть базу даних із дампу SQL із розташування у каталозі backup каталогу даних Weblate (див. Дампи даних для резервних копій).

  5. Скопіюйте налаштування Weblate (backups/settings.py, див. Дампи даних для резервних копій) у відповідне місце, див. Коригування налаштувань.

  6. Скопіюйте увесь каталог відновлених даних до місця, яке налаштовано змінною 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

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

Перш ніж відновлювати базу даних, вам слід встановити і запустити точну ту саму версію Weblate, що і на сервері, на якому виконувалося резервне копіювання. Це необхідно, оскільки структура бази даних змінюється між випусками, отже, використання неналежної версії може призвести до певного пошкодження даних. Після встановлення тієї самої версії запустіть усі процедури перенесення бази даних за допомогою команди migrate.

Щойно встановлення буде виконано, у базі даних з’являться деякі записи, які вже є у резервній копії. Рекомендуємо вилучити такі записи вручну за допомогою оболонки керування (див. Виклик команд керування):

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

Файли

Якщо у вас достатньо місця, рекомендуємо просто створити резервну копію усіх даних у DATA_DIR. Це найбезпечніший варіант, навіть якщо при цьому до резервної копії потраплять непотрібні вам файли. У наступних розділах докладно описано те, що має потрапити до резервної копії, і дані, які можна безпечно пропустити при резервному копіюванні.

Дампи даних для резервних копій

Зберігається у DATA_DIR /backups.

Weblate створює тут дамп різноманітних даних, і ви можете включити ці файли для отримання повнішої резервної копії. Файли оновлюються щоденно (це потребує запуску сервера Celery, див. Фонові завдання з використанням 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.

Якщо ви користуєтеся ключами SSH або GPG, які створено Weblate, вам слід створити резервні копії цих даних, інакше ви можете втратити закриті ключі, і вам доведеться створювати нові.

Вивантажені користувачем файли

Зберігаються у DATA_DIR /media.

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

Завдання 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

Відновлення зі створеної вручну резервної копії

  1. Відновлення усіх даних зі створеної вами резервної копії.

  2. Оновлення усіх сховищ за допомогою updategit.

    weblate updategit --all
    

Пересування встановленого екземпляра Weblate

Перенесіть ваш екземпляр на іншу систему за допомогою настанов зі створення і відновлення резервних копій, які наведено вище.