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

Резервне копіювання на рівні проєктів

Added in version 4.14.

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

Підтримку відновлення даних з резервних копій передбачено лише для баз даних PostgreSQL або MariaDB 10.5+.

До резервних копій проєктів включено усі дані перекладу з Weblate (проєкт, складники, переклади, коментарі до рядків, пропозиції та перевірки). Такі резервні копії зручні для перенесення проєктів на інші екземпляри Weblate.

Створити резервну копію проєкту можна за допомогою пункту Керування ↓ Резервні копії. Відновити дані з резервної копії можна під час створення проєкту (див. Додавання проєктів і складників перекладу).

До поточних версій резервних копій не входять дані щодо керування доступом та дані журналу.

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

Створені резервні копії зберігатимуться на сервері, який визначається змінними PROJECT_BACKUP_KEEP_DAYS і PROJECT_BACKUP_KEEP_COUNT (типовим є зберігання не більше 3 резервних копій протягом 30 днів).

Використовуйте згенерований файл для імпорту проєкту при Додавання проєктів і складників перекладу.

Примітка

Відновлення з резервної копії може бути невдалим, якщо на сервері відновлення є іншим набір мов або інші налаштування SIMPLIFY_LANGUAGES. Процес відновлення повідомить вам коди мов, які не вдалося обробити, а потім ви можете додати пропущені визначення мов вручну.

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

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

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

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

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

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

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

../_images/backups.webp

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

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

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

Дивись також

borg init

Налаштовування резервного копіювання

  • Резервне копіювання бази даних можна налаштувати за допомогою DATABASE_BACKUP.

  • Створення резервних копій можна налаштувати за допомогою BORG_EXTRA_ARGS.

Передбачене у 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 не зможе записати їх туди.

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

Для створення віддалених резервних копій вам слід встановити на іншому доступному з вашого екземпляра Weblate за допомогою SSH сервері BorgBackup з використанням ключа SSH Weblate:

  1. Приготуйте сервер, на якому зберігатимуться ваші резервні копії.

  2. Установіть на ньому сервер SSH (такий сервер типово встановлено у більшості дистрибутивів Linux).

  3. Установіть на цьому сервері BorgBackup; у більшості дистрибутивів Linux є відповідні пакунки (див. Installation).

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

  5. Додайте ключ SSH Weblate до запису користувача, щоб Weblate міг встановлювати з’єднання SSH із сервером без пароля (див. Ключ SSH Weblate).

  6. Налаштуйте розташування резервних копій у Weblate як користувач@вузол:/шлях/до/резервних/копій або ssh://користувач@вузол:порт/шлях/до/резервних/копій.

Підказка

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

Дивись також

Ключ SSH Weblate, General

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

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

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

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

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

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

    Якщо застосовується контейнер Docker, файл налаштувань вже включено у контейнер і ви повинні відновити початкові змінні середовища. Файл environment.yml може допомогти вам у цьому (див. Дампи даних для резервних копій).

  6. Скопіюйте увесь каталог відновлених даних до місця, яке налаштовано змінною DATA_DIR.

    Якщо застосовується контейнер Docker, помістіть дані до тому даних, див. Томи контейнера Docker.

    Будь ласка, переконайтеся у тому, що визначено належних власників і права доступу до файлів, див. Права доступу у файловій системі.

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

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

Змінено в версії 4.7: Дамп середовища було додано як environment.yml, щоб допомогти у відновленні середовищ Docker.

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

Weblate створює тут дамп різноманітних даних, і ви можете включити ці файли для отримання повнішої резервної копії. Файли оновлюються щоденно (це потребує запуску сервера Celery, див. Фонові завдання з використанням Celery). У поточній версії сюди включено:

  • Параметри Weblate у файлі settings.py (розширена версія зберігається у settings-expanded.py).

  • Резервна копія бази даних PostgreSQL у файлі database.sql.

  • Дамп середовища як environment.yml.

Типово, резервні копії зберігаються у форматі простого тексту. Втім, її можна стиснути або повністю пропустити за допомогою параметра DATABASE_BACKUP.

Щоб відновити бази даних з резервної копії, завантажте її за допомогою інструментів бази даних, наприклад:

psql --file=database.sql weblate

Сховища систем керування версіями

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

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

Ключі SSH і GPG

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

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

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

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

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

Завдання Celery

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

Дивись також

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

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

За допомогою завдання cron ви можете наказати системі виконувати щодня команду bash. Приклад:

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

Ви можете скоригувати список тек і файлів за вашими потребами. Наприклад, щоб уникнути зберігання пам’яті перекладів (у теці резервних копій), ви можете скористатися таким:

$ 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

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

Дивись також

Оновлення з Python 2 до Python 3 у документації з Weblate 3.11.1, Перенесення даних з інших баз даних до PostgreSQL