Weblate のバックアップと移動

プロジェクト レベルのバックアップ

Added in version 4.14.

プロジェクトは、Weblate からすべての翻訳コンテンツ（プロジェクト、コンポーネント、翻訳、文字列コメント、提案または検査結果）をバックアップします。プロジェクトを別の Weblate インスタンスに転送するのに適しています。

プロジェクトのバックアップは、 操作 ↓ バックアップ から実行できます。バックアップは、プロジェクトの作成時に復元できます（参照: 翻訳プロジェクトとコンポーネントの追加）。

現在、バックアップにはアクセス制御情報と履歴は含まれていません。

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 日分

  • 週次バックアップ、過去 6 週分

  • 月次バックアップ、過去 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 のインストールが必要です。

参考

Borgドキュメント項目 General

ローカル ファイルシステム

ローカルバックアップの絶対パスを、/path/to/backup のように指定してください。このディレクトリは、Weblate を実行しているユーザーの書き込み権限が必要です（参照: ファイル システムのアクセス権）。ディレクトリが存在しない場合は、Weblate が作成を試みますが、そのためには書き込み権限が必要です。

ヒント

Docker で Weblate を実行する場合は、バックアップの場所が Weblate コンテナからボリュームとして公開済みであることを確認してください。それ以外の場合、バックアップは、Docker が含まれているコンテナーを再起動したときに Docker によって破棄されます。

1 つの選択肢は、バックアップを既存のボリュームに配置することです。例えば、/app/data/borgbackup。これは、コンテナ内の既存のボリュームです。

例えば /borgbackup として、バックアップ用の新しいコンテナをDocker Composeファイルに追加する方法:

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 鍵を使用して Weblate サーバーに SSH で接続できる別のサーバーに BorgBackup をインストールする必要があります。作成方法:

  1. バックアップを保存するサーバーを準備する。

  2. SSH サーバーをインストールする（ほとんどの Linux ディストリビューションではデフォルトで提供されている）。

  3. 準備したサーバーに、 BorgBackup をインストールする。ほとんどの Linux ディストリビューションにはパッケージが用意されている（参照: Installation）。

  4. 既存のユーザーを選択するか、バックアップ用の新しいユーザーを作成する。

  5. Weblate がパスワードを使用せずに、サーバーに SSH で接続できるように、ユーザーの .ssh/authorized_keys ファイルに Weblate SSH 鍵をユーザーに追加してください（参照: Weblate SSH 鍵）。

  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 REPOSITORY を使用して、サーバー上のすべてのバックアップを一覧表示する。

  3. borg extract REPOSITORY::ARCHIVE を使用して、目的のバックアップを現在のディレクトリに復元する。

  4. Weblate データ ディレクトリーの backup ディレクトリーに置かれた SQL ダンプから、データベースを復元する（参照: バックアップ用にダンプしたデータ）。

  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:

参考

Restoring Docker based setup

The following steps assume the official Docker Compose setup using the bundled PostgreSQL and Valkey services, see Docker を使用したインストール. If your deployment uses an external database or a customized Compose file, adapt the database and volume steps to that environment.

Start with a Docker Compose checkout matching the restored deployment. Restore your original Compose overrides, secrets, and environment variables. The environment.yml file from バックアップ用にダンプしたデータ can help with this, but it is not imported automatically.

  1. Restore the backup archive using BorgBackup から復元 or unpack your manual backup so that the Weblate data directory and backups/database.sql are available.

  2. Stop the services which can write to the database or data volume:

    docker compose stop weblate cache

  3. Recreate the PostgreSQL volume.

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

    The volume name depends on the Compose project name and can differ from weblate-docker_postgres-data. Check your setup before removing any volume.

  4. Start the database service:

    docker compose up -d database

  5. Restore the database dump:

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

    Check that the database name matches POSTGRES_DB and the user matches POSTGRES_USER in your Compose configuration.

  6. Restore the Weblate data directory to the Docker data volume mounted as /app/data, see Docker コンテナのボリューム. Files in this volume have to be owned by UID 1000, see ファイル システムのアクセス権.

  7. Start the remaining services and follow the logs:

    docker compose up -d
docker compose logs -f

    The Weblate container performs database migrations on startup. If you are also upgrading Weblate, follow Docker コンテナーのアップグレード.

  8. Refresh the repositories after the restore:

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

参考

手動バックアップ

保存する内容に応じて、Weblate がそれぞれの場所に保存するデータを種類ごとにバックアップします。

ヒント

手動でバックアップしている場合、Weblate のバックアップ不足の警告を黙らせるには、settings.py ファイルの SILENCED_SYSTEM_CHECKS に weblate.I028 を追加する。Docker の場合は WEBLATE_SILENCED_SYSTEM_CHECKS を追加してください。

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

データベース

実際の保存場所は、データベースの設定によって異なります。

ヒント

データベースは最も重要なストレージです。データベースの定期的なバックアップを設定してください。データベースがなくなれば、すべての翻訳が消失します。

データベース自身でバックアップ

推奨する方法は、pg_dump などのデータベースに搭載しているツールを使用して、データベースのダンプを保存することです。これは通常 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 全体をバックアップしてください。これは、不要なファイルが含まれている場合でも安全な方法です。次のセクションでは、バックアップすべきものと除外できるものについて詳しく説明します。

バックアップ用にダンプしたデータ

バージョン 4.7 で変更: 環境ダンプは、Docker 環境での復元を支援するために 、environment.yml として追加されました。

保存先: DATA_DIR /backups。

Weblate は、さまざまなデータをここにダンプします。これらのファイルを含めて、より完全なバックアップを取ることができます。ファイルは毎日更新されます（実行中の Celery beats サーバーが必要。参照: 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 側のリポジトリは、データ損失のない上流リポジトリから再度クローンを作成できるため、バックアップする必要はありません。Weblate 側で、リポジトリのバックアップを取る必要はありません。上流リポジトリから再びクローンすれば、データを失うことはありません。

SSH 鍵および GPG 鍵

保存先: DATA_DIR /ssh および DATA_DIR /home。

Weblateで生成したSSH 鍵および GPG 鍵を使用している場合は、保存場所をバックアップしてください。バックアップしなければ、秘密鍵を消失し、新しい鍵の再生成が必要となります。

生成された SSH ラッパー スクリプトは CACHE_DIR に保存され、バックアップする必要はありません。

ユーザーがアップロードしたファイル

保存先: DATA_DIR /media。

ユーザーがアップロードしたファイルは、すべてバックアップしてください（例: Screenshots and visual context）。

Celery タスク

Celery タスク キューには、何かの情報が含まれていることがありますが、通常はバックアップする必要はありません。翻訳メモリで未処理の更新が、失われるだけです。どちらにしても、復元時にフル テキストまたはリポジトリの更新を実行をすれば、消失しても問題はありません。

参考

Celery を使用するバックグラウンド タスク

手動バックアップのコマンドライン

cron job を使用すると、毎日実行する 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 設置場所の移動

上記のバックアップと復元の手順に従い、インストールした Weblate を、他のシステムに移動します。

参考