Weblate のバックアップと移動¶
プロジェクト レベルのバックアップ¶
Added in version 4.14.
プロジェクトは、Weblate からすべての翻訳コンテンツ（プロジェクト、コンポーネント、翻訳、文字列コメント、提案または検査結果）をバックアップします。プロジェクトを別の Weblate インスタンスに転送するのに適しています。
The backup includes every component in the project, including restricted components which the administrator can not open directly. Creating, listing, and downloading these backups requires Edit project settings. Grant that permission only to users trusted with the complete project contents.
プロジェクトのバックアップは、 操作 ↓ バックアップ から実行できます。バックアップは、プロジェクトの作成時に復元できます（参照: 翻訳プロジェクトとコンポーネントの追加）。
注釈
プロジェクトのバックアップは、2026.7 以降、Weblate の REST API を通じて作成、一覧表示、ダウンロードできます;
The backups include project-scoped teams and their memberships, but do not include history.
When restoring backups with duplicate team names, all teams are preserved. Additional teams with the same name receive a numeric suffix, and the import reports the renamed teams in its warnings. Built-in teams are restored separately from custom teams. Older backups do not record team type, so duplicate entries are restored as editable custom teams with numeric suffixes alongside the generated built-in team.
Missing repository directories are skipped while component and translation data are still backed up. Repository maintenance failures are logged, and the backup continues with the available repository files. Filesystem access and I/O errors cause the backup to fail, and incomplete archives are removed. Restoring a backup with missing or invalid repository metadata preserves the available files, components, and translation data, but the repository must be recovered separately.
コメントと提案は、作成時のユーザー名でバックアップします。インポート時に一致するユーザーがあれば割り当て、一致するユーザーが存在しない場合は、匿名ユーザーとします。
生成されたバックアップは、PROJECT_BACKUP_KEEP_DAYS と PROJECT_BACKUP_KEEP_COUNT に設定した通りにサーバーに保存します（デフォルトでは、最大 3 つのバックアップを 30 日間保存します）。
アップロードされたプロジェクトのバックアップのインポート検証は、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、および PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO を使用して調整できます。
完全なバックアップは、いかなるデータを復元する前にも検証されます。オブジェクトの不正なフィールド、参照、リポジトリパス、URL、正規表現、またはスクリーンショット ファイルが含まれている場合、インポートは拒否され、部分的なプロジェクトが作成されることはありません。
生成されたファイルは、翻訳プロジェクトとコンポーネントの追加 の手順でプロジェクトを追加する場合、または import_projectbackup コマンドを使用してインポートする場合に使用します。
注釈
バックアップの復元は、言語の定義 の一覧または SIMPLIFY_LANGUAGES の設定が異なる場合、失敗することがあります。復元の際にどの言語コードが処理できなかったのかが分かるので、不足している言語定義を手動で追加できます。
BorgBackup を使用した自動バックアップ¶
Weblate には、BorgBackup を使用してサービスのバックアップを作成する機能が付属しています。Borg はスペース効率の高い暗号化されたバックアップを作成し、クラウドに安全に保存します。バックアップは、管理画面の バックアップ タブから管理します。
バージョン 4.4.1 で変更: PostgreSQL データベースは自動バックアップに含まれています。
Borg を使用したバックアップは増分バックアップです。 Weblate は以下のバックアップを保持します。
日次バックアップ、過去 14 日分
週次バックアップ、過去 6 週分
月次バックアップ、過去 6 か月分
Borg 暗号鍵¶
BorgBackup は、暗号化したバックアップを作成するので、パスフレーズがないと復元できません。パスフレーズは、新しいバックアップ サービスを追加するときに生成されるので、コピーして安全な場所に保存しておくことが必要です。
Weblate 専用のバックアップ ストレージ を使用している場合は、バックアップに接続するための SSH 秘密鍵もバックアップしてください。
参考
バックアップのカスタマイズ¶
データベースのバックアップは、
DATABASE_BACKUPから設定します。バックアップの作成は、
BORG_EXTRA_ARGSを使用してカスタマイズできます。
Weblate 専用のバックアップ ストレージ¶
The easiest way of backing up your Weblate instance is purchasing the backup service at weblate.org. It is available for Weblate running in your own environment and does not require a hosting or separate support subscription.
This is how you get it running:
In the management interface, open Backups and select Buy backup service, or purchase the backup service directly.
Enter the obtained activation token in Activate support package on the Backups page, see サポートの統合.
Weblate はクラウド サービスに接続し、バックアップのための接続情報を取得する。
バックアップ タブから、新しいバックアップの設定を有効にする。
Back up your Borg credentials to be able to restore the backups, see 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
バックアップが保存されるディレクトリは、UID 1000 が所有者であることが必要です。そうでない場合、Weblate はそこにバックアップを書き込むことができません。
リモート バックアップ¶
リモート バックアップを作成するには、あなたの Weblate の SSH 鍵を使用して Weblate サーバーに SSH で接続できる別のサーバーに BorgBackup をインストールする必要があります。作成方法:
バックアップを保存するサーバーを準備する。
SSH サーバーをインストールする（ほとんどの Linux ディストリビューションではデフォルトで提供されている）。
準備したサーバーに、 BorgBackup をインストールする。ほとんどの Linux ディストリビューションにはパッケージが用意されている（参照: Installation）。
既存のユーザーを選択するか、バックアップ用の新しいユーザーを作成する。
Weblate がパスワードを使用せずに、サーバーに SSH で接続できるように、ユーザーの .ssh/authorized_keys ファイルに Weblate SSH 鍵をユーザーに追加してください（参照: Weblate SSH 鍵）。
Weblate がリモートで Borg バックアップリポジトリをセットアップできるように、ユーザーが書き込み可能なディレクトリをホームディレクトリ内などに作成します（例:
/home/borg/backups）。Weblate のバックアップ先を、
user@host:/home/borg/backupsまたはssh://user@host:port/home/borg/backupsに設定する。有効にすると、バックアップは毎日自動的に実行されます。 WeblateのUIあるいは backup を使用して、手動でバックアップを実行することもできます。
ヒント
Weblate 専用のバックアップ ストレージ を使用すると、リモート バックアップを簡単に自動化できます。
BorgBackup から復元¶
バックアップ リポジトリへのアクセスを復元し、バックアップ パスフレーズを準備する。
borg list REPOSITORYを使用して、サーバー上のすべてのバックアップを一覧表示する。borg extract REPOSITORY::ARCHIVEを使用して、目的のバックアップを現在のディレクトリに復元する。Weblate データ ディレクトリーの
backupディレクトリーに置かれた SQL ダンプから、データベースを復元する（参照: バックアップ用にダンプしたデータ）。Weblate の設定ファイル（
backups/settings.py、参照: バックアップ用にダンプしたデータ）を正しい場所にコピーする。参照: 詳細設定。Docker コンテナを使用する場合、設定ファイルは既にコンテナに含まれているため、元の環境変数の復元が必要です。
environment.ymlファイルは復元に便利かも（参照: バックアップ用にダンプしたデータ）。復元したデータ ディレクトリ全体を、
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 ベース環境の復元¶
以下の手順は、同梱の PostgreSQL と Valkey サービスを使用する公式の Docker Compose セットアップを前提としています。詳細は Docker を使用したインストール を確認してください。外部データベースを使用している場合や、Compose ファイルをカスタマイズしている場合は、データベースおよびボリュームに関する手順をその環境に合わせて調整してください。
復元対象のデプロイメントと一致する Docker Compose のチェックアウトから開始してください。元の Compose の上書き設定（overrides）、シークレット、環境変数を復元します。バックアップ用にダンプしたデータ に含まれる environment.yml はこの作業に役立ちますが、自動的にインポートされるわけではありません。
BorgBackup から復元 を使用してバックアップ アーカイブを復元するか、手動バックアップを展開して、Weblate のデータ ディレクトリと
backups/database.sqlを使用可能な状態にしてください。データベースまたはデータボリュームへの書き込みが可能なサービスを停止してください：
docker compose stop weblate cache
PostgreSQL ボリュームの再生成。
docker compose stop database docker compose rm -v database docker volume remove weblate-docker_postgres-data
ボリューム名はプロジェクト名に依存しますが、
weblate-docker_postgres-dataにて変更可能です。ボリュームを削除する前に確認してください。データベースサービスの起動：
docker compose up -d database
データベースダンプをリストア：
cat backups/database.sql | docker compose exec -T database psql --username weblate --dbname weblate
データベース名が
POSTGRES_DBと一致し、ユーザーがPOSTGRES_USERと一致していることを、Compose の設定で確認してください。Weblate のデータ ディレクトリを、
/app/dataとしてマウントされている Docker のデータ ボリュームへ復元してください。詳細は Docker コンテナのボリューム を確認してください。このボリューム内のファイルは UID 1000 が所有者であることが必要です。ファイル所有権については ファイル システムのアクセス権 を確認してください。残りのサービスを起動し、ログを確認してください：
docker compose up -d docker compose logs -f
Weblate コンテナは、起動時にデータベースのマイグレーションを実行します。Weblate もアップグレードする場合は、Docker コンテナーのアップグレード の手順に従ってください。
リポジトリの復元後にリフレッシュします：
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 タスク キューには、何かの情報が含まれていることがありますが、通常はバックアップする必要はありません。翻訳メモリで未処理の更新が、失われるだけです。どちらにしても、復元時にフル テキストまたはリポジトリの更新を実行をすれば、消失しても問題はありません。
手動バックアップのコマンドライン¶
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
手動バックアップの復元¶
バックアップしたデータをすべて復元する。
updategitを使用して、すべてのリポジトリを更新する。weblate updategit --all
Weblate 設置場所の移動¶
上記のバックアップと復元の手順に従い、インストールした Weblate を、他のシステムに移動します。