Sichern und Verschieben von Weblate

Project level backups

Neu in Version 4.14.

Warnung

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 ManageBackups. The backup can be restored when creating a project (see Adding translation projects and components).

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).

Automatisierte Datensicherung mit BorgBackup

Neu in Version 3.9.

Weblate has built-in support for creating service backups using BorgBackup. Borg creates space-effective encrypted backups which can be safely stored in the cloud. The backups can be controlled in the management interface from the Backups tab.

Geändert in Version 4.4.1: Sowohl PostgreSQL- als auch MySQL/MariaDB-Datenbanken sind in den automatischen Backups enthalten.

Die Backups mit Borg sind inkrementell, und Weblate ist so konfiguriert, dass die folgenden Backups beibehalten werden:

  • Tägliche Backups der letzten 14 Tage

  • Wöchentliche Backups der letzten 8 Wochen

  • Monatliche Backups der letzten 6 Monate

../_images/backups.png

Borg encryption key

BorgBackup creates encrypted backups and you wouldn’t be able to restore them without the passphrase. The passphrase is generated when adding a new backup service and you should copy it and keep it in a secure place.

If you are using Von Weblate bereitgestellter Backup-Speicher, please backup your private SSH key too, as it’s used to access your backups.

Siehe auch

borg init

Backup anpassen

Von Weblate bereitgestellter Backup-Speicher

The easiest way of backing up your Weblate instance is purchasing the backup service at weblate.org. This is how you get it running:

  1. Erwerben Sie den Backup-Dienst auf https://weblate.org/support/#backup.

  2. Geben Sie den erhaltenen Schlüssel in die Verwaltungsoberfläche ein, siehe Integrating support.

  3. Weblate stellt eine Verbindung zum Cloud-Dienst her und erhält die Zugangsdaten für die Backups.

  4. Aktivieren Sie die neue Backup-Konfiguration auf der Reiterkarte Backups.

  5. Sichern Sie Ihre Borg-Anmeldedaten, um die Backups wiederherstellen zu können, siehe Borg encryption key.

Hinweis

Der manuelle Schritt, alles einzuschalten, dient Ihrer Sicherheit. Ohne Ihre Zustimmung werden keine Daten an den Backup-Speicher gesendet, den Sie durch den Registrierungsprozess erhalten haben.

Verwendung von eigenem Backup-Speicher

Sie können auch Ihren eigenen Speicher für die Backups verwenden. SSH kann verwendet werden, um Backups im entfernten Ziel zu speichern, der Zielserver muss BorgBackup installiert haben.

Siehe auch

General in der Borg-Dokumentation

Lokales Dateisystem

Es wird empfohlen, den absoluten Pfad für das lokale Backup anzugeben, zum Beispiel /path/to/backup. Das Verzeichnis muss für den Benutzer, unter dem Weblate läuft, beschreibbar sein (siehe Filesystem permissions). Existiert es nicht, versucht Weblate, es zu erstellen, benötigt dafür aber die entsprechenden Berechtigungen.

Hinweis

Wenn Sie Weblate in Docker ausführen, stellen Sie bitte sicher, dass der Speicherort des Backups vom Weblate-Container als Volume freigegeben wird. Andernfalls werden die Backups beim Neustart des Containers, in dem sie sich befinden, von Docker verworfen.

Eine Möglichkeit ist, Backups in ein bestehendes Volume zu legen, zum Beispiel /app/data/borgbackup. Dies ist ein vorhandenes Volume im Container.

Sie können auch einen neuen Container für die Backups in der Docker-Compose-Datei hinzufügen, indem Sie beispielsweise /borgbackup verwenden:

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

Das Verzeichnis, in dem die Backups gespeichert werden, muss der UID 1000 gehören, ansonsten kann Weblate die Backups nicht dorthin schreiben.

Remote-Backups

Um Remote-Backups zu erstellen, müssen Sie BorgBackup auf einem anderen Server installieren, der für Ihre Weblate-Installation über SSH mit dem Weblate-SSH-Schlüssel erreichbar ist:

  1. Bereiten Sie einen Server vor, auf dem Ihre Backups gespeichert werden sollen.

  2. Installieren Sie den SSH-Server darauf (bei den meisten Linux-Distributionen erhalten Sie ihn standardmäßig).

  3. Installieren Sie BorgBackup auf diesem Server; für die meisten Linux-Distributionen sind Pakete verfügbar (siehe Installation).

  4. Wählen Sie einen vorhandenen Benutzer oder erstellen Sie einen neuen Benutzer, der für die Sicherung verwendet werden soll.

  5. Fügen Sie dem Benutzer den SSH-Schlüssel von Weblate hinzu, damit Weblate ohne Passwort per SSH auf den Server zugreifen kann (siehe Weblate-SSH-Schlüssel).

  6. Konfigurieren Sie den Backup-Speicherort in Weblate als user@host:/path/to/backups oder ssh://user@host:port/path/to/backups.

Hinweis

Von Weblate bereitgestellter Backup-Speicher bietet Ihnen automatisierte Remote-Backups ohne jeglichen Aufwand.

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 Adjusting configuration.

    Bei der Verwendung von Docker-Containern ist die Einstellungsdatei bereits im Container enthalten und Sie sollten die ursprünglichen Umgebungsvariablen wiederherstellen. Die Datei environment.yml kann Ihnen dabei helfen (siehe Dumped data for backups).

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

    Bei der Verwendung von Docker-Containern legen Sie die Daten in das Datenvolumen, siehe Docker-Container-Volumes.

    Bitte vergewissern Sie sich, dass die Dateien die korrekten Besitzverhältnisse und Berechtigungen haben, siehe Filesystem permissions.

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:

Siehe auch

borg list, borg extract

Manual backup

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

Hinweis

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.

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

Database

The actual storage location depends on your database setup.

Hinweis

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 Upgrading Weblate on more detailed info on how to upgrade between versions.

Django database backup

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()

Dateien

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

Geändert in Version 4.7: Der Umgebungsdump wurde als environment.yml hinzugefügt, um die Wiederherstellung in den Docker-Umgebungen zu erleichtern.

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 Background tasks using Celery). Currently, this includes:

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

  • PostgreSQL database backup as database.sql.

  • Umgebungsdump als environment.yml.

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

To restore the database backup load it using database tools, for example:

psql --file=database.sql weblate

Version control repositories

Stored in DATA_DIR /vcs.

Die Versionsverwaltung enthält eine Kopie Ihrer Upstream-Repositorys mit Weblate-Änderungen. Wenn Sie Bei Commit gleichzeitig Pushen für alle Ihre Übersetzungskomponenten aktiviert haben, werden alle Weblate-Änderungen Upstream aufgenommen. Es ist nicht notwendig, die Repositorys auf der Weblate-Seite zu sichern, da sie ohne Datenverlust von den Upstream-Speicherorten erneut geklont werden können.

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.

Sie sollten alle vom Benutzer hochgeladenen Dateien sichern (z. B. Bildschirmfotos).

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.