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

Автоматичне резервне копіювання

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

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

Попередження

До автоматизованих резервних копій буде включено лише базу даних PostgreSQL. Резервні копії даних інших рушіїв керування базами даних має бути збережено вручну. Рекомендуємо вам перейти на PostgreSQL, див. Налаштування бази даних для Weblate і Перенесення даних з інших баз даних до PostgreSQL.

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

  • резервний копій із 14-денним період створення

  • резервних копій із 8-тижневим періодом створення

  • резервних копій із 6-місячним періодом створення

../_images/backups.png

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

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

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

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

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

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

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

Підказка

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

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

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

Дивись також

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

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

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

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

Дивись також

borg init

Відновлення з 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.

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

Команда для резервного копіювання вручну

За допомогою завдання 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

Завдання Celery

У черзі завдань Celery можуть міститися корисні дані, але,зазвичай, створення їхньої резервної копії не виправдано. У найгіршому випадку ви втратите оновлення пам’яті перекладів, які ще не було оброблено. Такі дані рекомендовано оновлювати за цілими текстами та сховищами під час відновлення, тому ніяких проблем із втратою черги завдань не повинно бути.

Дивись також

Фонові завдання з використанням Celery

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

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

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

    weblate updategit --all

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

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

Дивись також

Оновлення з Python 2 до Python 3, Перенесення даних з інших баз даних до PostgreSQL