Weblate のバックアップと移動

Project level backups

バージョン 4.14 で追加.

警告

Restoring backups is only supported when using PostgreSQL or MariaDB 10.5+ as a database.

The project backups all translation content from Weblate (project, components, translations, string comments, suggestions or checks). It is suitable for transferring a project to another Weblate instance.

You can perform a project backup in Manage ↓ Backups. The backup can be restored when creating a project (see 翻訳プロジェクトとコンポーネントの追加).

The backups currently do not include access control information and history.

The comments and suggestions are backed up with an username of 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.

The generated backups are kept on the server as configured by PROJECT_BACKUP_KEEP_DAYS and PROJECT_BACKUP_KEEP_COUNT (it defaults to keep at most 3 backups for 30 days).

BorgBackup を使用した自動バックアップ

バージョン 3.9 で追加.

Weblate には、BorgBackup を使用してサービスのバックアップを作成する機能が付属しています。Borg はスペース効率の高い暗号化されたバックアップを作成し、クラウドに安全に保存します。バックアップは、管理画面の バックアップ タブから管理します。

バージョン 4.4.1 で変更: PostgreSQL と MySQL/MariaDB の両方のデータベースが自動バックアップに含まれています。

Borg を使用したバックアップは増分バックアップです。 Webrate は以下のバックアップを保持します。

  • 日次バックアップ、過去 14 日分

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

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

../_images/backups.png

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

バックアップが保存されるディレクトリは、UID 1000 が所有者であることが必要です。異なる場合、Weblate はそこにバックアップを書き込むことができません。

リモート バックアップ

Weblate を導入したサーバーとは別に、Weblate の SSH 鍵を使用して SSH で接続できるサーバーが必要です。バックアップ サーバーの準備方法:

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

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

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

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

  5. Weblate がパスワードを使用せずに、サーバーに SSH で接続できるように、Weblate SSH 鍵をユーザーに追加する（参照: Weblate SSH 鍵）。

  6. Weblate のバックアップ先を、user@host:/path/to/backups または ssh://user@host:port/path/to/backups に設定する。

ヒント

Weblate 専用のバックアップ ストレージ を使用すると、リモート バックアップを簡単に自動化できます。

参考

Weblate SSH 鍵、General

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:

参考

borg list、borg extract

手動バックアップ

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

ヒント

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

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

データベース

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

ヒント

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

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

推奨する方法は、pg_dump や mysqldump などのデータベースに搭載しているツールを使用して、データベースのダンプを保存することです。これは通常 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`（拡張版として :file:`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 鍵を使用している場合は、保存場所をバックアップしてください。バックアップしなければ、秘密鍵を消失し、新しい鍵の再生成が必要となります。

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

保存先: DATA_DIR /media。

ユーザーがアップロードしたファイルは、すべてバックアップしてください（例: 文字列の視覚情報）。

Celery タスク

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

参考

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

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

cron job を使用すると、毎日実行する 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

手動バックアップの復元

  1. バックアップしたデータをすべて復元する。

  2. updategit を使用して、すべてのリポジトリを更新する。

    weblate updategit --all

Weblate 設置場所の移動

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

参考

Python 2 から Python 3 にアップグレード、他のデータベースから PostgreSQL に移行