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

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

Added in version 4.14.

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

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

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

The comments and suggestions are backed up with the username of the user who did create them. Upon import it is assigned to a matching user. If there is no user with such username, it is assigned to anonymous user.

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

Import validation of uploaded project backups can be tuned using PROJECT_BACKUP_IMPORT_MAX_MEMBERS, PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE, PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE, PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE, and PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO.

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

Примітка

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

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

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

Змінено в версії 4.4.1: Бази даних PostgreSQL включені в автоматичне резервне копіювання.

Резервні копії з використанням 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

The directory where backups will be stored has to be owned by UID 1000, otherwise Weblate won’t be able to write the backups there.

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

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

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

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

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

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

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

  6. Створіть каталог, доступний для запису користувачем, де Weblate зможе віддалено налаштувати репозиторій резервних копій Borg, наприклад, у домашньому каталозі (тобто /home/borg/backups).

  7. Налаштуйте місце розташування резервної копії у Weblate як user@host:/home/borg/backups або ssh://user@host:port/home/borg/backups.

  8. Once enabled, the backups will be triggered automatically daily. You can also manually trigger a backup from the Weblate UI or using backup.

Підказка

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

Дивись також

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

Дивись також

Відновлення конфігурації на базі Docker

Наступні кроки передбачають використання офіційної конфігурації Docker Compose із вбудованими службами PostgreSQL та Valkey; див. Установлення за допомогою Docker. Якщо у вашому розгортанні використовується зовнішня база даних або налаштований файл Compose, адаптуйте кроки щодо бази даних та томів до цього середовища.

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

  1. Відновіть архів резервної копії за допомогою Відновлення з BorgBackup або розпакуйте створену вручну резервну копію, щоб забезпечити доступ до каталогу даних Weblate та файлу backups/database.sql.

  2. Зупиніть служби, які можуть записувати дані в базу даних або на том:

    docker compose stop weblate cache

  3. Створіть том PostgreSQL заново.

    docker compose stop database
docker compose rm -v database
docker volume remove weblate-docker_postgres-data

    Назва тома залежить від назви проєкту Compose і може відрізнятися від weblate-docker_postgres-data. Перед видаленням будь-якого тома перевірте налаштування.

  4. Запустіть службу бази даних:

    docker compose up -d database

  5. Відновити дамп бази даних:

    cat backups/database.sql | docker compose exec -T database psql --username weblate --dbname weblate

    Перевірте, чи ім’я бази даних відповідає значенню POSTGRES_DB, а ім’я користувача — значенню POSTGRES_USER у вашій конфігурації Compose.

  6. Відновіть каталог даних Weblate у том даних Docker, підключений як /app/data; див. Томи контейнера Docker. Власником файлів у цьому томі має бути користувач з UID 1000; див. Права доступу у файловій системі.

  7. Запустіть решту служб і стежте за журналами:

    docker compose up -d
docker compose logs -f

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

  8. Оновіть репозиторії після відновлення:

    docker compose exec --user weblate weblate weblate updategit --all

Дивись також

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

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

Підказка

Якщо ви виконуєте резервне копіювання вручну, вам варто увімкнути попередження Weblate щодо відсутності резервних копій додаванням weblate.I028 до SILENCED_SYSTEM_CHECKS у settings.py або WEBLATE_SILENCED_SYSTEM_CHECKS для Docker.

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

База даних

Справжнє розташування сховища залежить від ваших налаштувань бази даних.

Підказка

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

Власна система резервного копіювання бази даних

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

Створені скрипти-обгортки SSH зберігаються в CACHE_DIR, і їх не потрібно резервувати.

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

Зберігаються у 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

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

Дивись також