Weblate のバックアップと移動

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

バージョン 3.9 で追加.

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

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

Borg を使用したバックアップは増分バックアップです。 Webrate に設定された常に実施されるバックアップ:

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

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

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


Borg 暗号鍵

BorgBackup は暗号化したバックアップを作成するので、パスフレーズがないと復元できません。パスフレーズは、新しいバックアップ サービスを追加するときに生成されるので、コピーして安全な場所に保管しておくことが必要です。

Weblate 専用のバックアップ ストレージ を使用している場合は、バックアップに接続するための SSH 秘密鍵もバックアップしてください。


borg init

Weblate 専用のバックアップ ストレージ

Weblate のインスタンスをバックアップする最も簡単な方法は、`backup service at weblate.org `_ を購入することです。導入方法:

  1. https://weblate.org/support/#backup から バックアップ サービス を購入する。

  2. 取得したキーを管理画面から入力する。参照: サポートの統合

  3. Weblate はクラウド サービスに接続し、バックアップのための接続情報を取得する。

  4. バックアップ タブから、新しいバックアップの設定を有効にする。

  5. Borg 資格情報をバックアップして、バックアップを復元できるようにします。参照: Borg 暗号鍵


手動ですべてを有効にすることが必要なのは、安全のためです。ユーザーの同意がなければ、登録の過程で取得したデータはバックアップ リポジトリに送信しません。

独自のバックアップ ストレージの使用

バックアップには、独自のストレージも使用できます。SSH を使用してリモート接続先にバックアップを保存できます。対象のサーバーには BorgBackup のインストールが必要です。


Borgドキュメント項目 General

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

It is recommended to specify the absolute path for the local backup, for example /path/to/backup. The directory has to be writable by the user running Weblate (see ファイル システムのアクセス権). If it doesn't exist, Weblate attempts to create it but needs the appropriate permissions to do so.


When running Weblate in Docker, please ensure the backup location is exposed as a volume from the Weblate container. Otherwise the backups will be discarded by Docker upon restarting the container it is in.

One option is to place backups into an existing volume, for example /app/data/borgbackup. This is an existing volume in the container.

You can also add a new container for the backups in the Docker Compose file for example by using /borgbackup:

      - /home/weblate/data:/app/data
      - /home/weblate/borgbackup:/borgbackup

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

リモート バックアップ

In order to create the remote backups, you will have to install BorgBackup onto another server that’s accessible via SSH. Make sure that it accepts the Weblate's client SSH key, i.e. the one it uses to connect to other servers.


Weblate 専用のバックアップ ストレージ provides you automated remote backups.

Restoring from BorgBackup

  1. Restore access to your backup repository and prepare your backup passphrase.

  2. List all the backups on the server using borg list REPOSITORY.

  3. Restore the desired backup to the current directory using borg extract REPOSITORY::ARCHIVE.

  4. Restore the database from the SQL dump placed in the backup directory in the Weblate data dir (see Dumped data for backups).

  5. Copy the Weblate configuration (backups/settings.py, see Dumped data for backups) to the correct location, see 詳細設定.

  6. Copy the whole restored data dir to the location configured by DATA_DIR.

The Borg session might look like this:

$ 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:

Manual backup

Depending on what you want to save, back up the type of data Weblate stores in each respective place.


If you are doing the manual backups, you might want to silence Weblate's warning about a lack of backups by adding weblate.I028 to SILENCED_SYSTEM_CHECKS in settings.py or WEBLATE_SILENCED_SYSTEM_CHECKS for Docker.



The actual storage location depends on your database setup.


The database is the most important storage. Set up regular backups of your database. Without the database, all the translations are gone.

Native database backup

The recommended approach is to save a dump of the database using database-native tools such as pg_dump or mysqldump. It usually performs better than Django backup, and it restores complete tables with all their data.

You can restore this backup in a newer Weblate release, it will perform all the necessary migrations when running in migrate. Please consult Weblate のアップグレード on more detailed info on how to upgrade between versions.

Django バックアップ データベース

Alternatively, you can back up your database using Django's dumpdata command. That way the backup is database agnostic and can be used in case you want to change the database backend.

Prior to restoring the database you need to be running exactly the same Weblate version the backup was made on. This is necessary as the database structure does change between releases and you would end up corrupting the data in some way. After installing the same version, run all database migrations using migrate.

Afterwards some entries will already be created in the database and you will have them in the database backup as well. The recommended approach is to delete such entries manually using the management shell (see Invoking management commands):

weblate shell
>>> from weblate.auth.models import User
>>> User.objects.get(username='anonymous').delete()


If you have enough backup space, simply back up the whole DATA_DIR. This is a safe bet even if it includes some files you don't want. The following sections describe what you should back up and what you can skip in detail.

Dumped data for backups

Stored in DATA_DIR /backups.

Weblate dumps various data here, and you can include these files for more complete backups. The files are updated daily (requires a running Celery beats server, see Celery を使用するバックグラウンド タスク). Currently, this includes:

  • Weblate settings as settings.py (there is also expanded version in settings-expanded.py).

  • PostgreSQL database backup as database.sql.

The database backups are saved as plain text by default, but they can also be compressed or entirely skipped using DATABASE_BACKUP.

Version control repositories

Stored in DATA_DIR /vcs.

The version control repositories contain a copy of your upstream repositories with Weblate changes. If you have Push on commit enabled for all your translation components, all Weblate changes are included upstream. No need to back up the repositories on the Weblate side as they can be cloned again from the upstream location(s) with no data loss.

SSH and GPG keys

Stored in DATA_DIR /ssh and DATA_DIR /home.

If you are using SSH or GPG keys generated by Weblate, you should back up these locations. Otherwise you will lose the private keys and you will have to regenerate new ones.

User uploaded files

Stored in DATA_DIR /media.

ユーザーがアップロードしたすべてのファイルのバックアップが必要です(例: Visual context for strings)。

Celery tasks

The Celery task queue might contain some info, but is usually not needed for a backup. At most you will lose updates not yet been processed to translation memory. It is recommended to perform the fulltext or repository update upon restoration anyhow, so there is no problem in losing these.

Command line for manual backup

Using a cron job, you can set up a Bash command to be executed on a daily basis, for example:

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

The string between the quotes after XZ_OPT allows you to choose your xz options, for instance the amount of memory used for compression; see https://linux.die.net/man/1/xz

You can adjust the list of folders and files to your needs. To avoid saving the translation memory (in backups folder), you can use:

$ 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

Restoring manual backup

  1. Restore all data you have backed up.

  2. Update all repositories using updategit.

    weblate updategit --all

Moving a Weblate installation

Relocate your installation to a different system by following the backing up and restoration instructions above.