Sichern und Verschieben von Weblate

Sicherungen auf Projektebene

Neu in Version 4.14.

Warnung

Die Wiederherstellung von Backups wird nur unterstützt, wenn PostgreSQL oder MariaDB 10.5+ als Datenbank verwendet wird.

Das Projekt sichert alle Übersetzungsinhalte von Weblate (Projekt, Komponenten, Übersetzungen, Zeichenkette-Kommentare, Vorschläge oder Qualitätsprüfungen). Es ist geeignet, um ein Projekt auf eine andere Weblate-Instanz zu übertragen.

Sie können eine Projektsicherung in Verwaltung ↓ Sicherungen durchführen. Die Sicherung kann beim Erstellen eines Projekts wiederhergestellt werden (siehe Adding translation projects and components).

Die Sicherungen enthalten derzeit keine Informationen über die Zugriffssteuerung und den Verlauf.

Die Kommentare und Vorschläge sind mit dem Benutzernamen des Benutzers, der sie erstellt hat, hinterlegt. Beim Import werden sie einem passenden Benutzer zugewiesen. Wenn es keinen Benutzer mit einem solchen Benutzernamen gibt, wird er einem anonymen Benutzer zugewiesen.

Die erzeugten Backups werden auf dem Server aufbewahrt, wie durch PROJECT_BACKUP_KEEP_DAYS und PROJECT_BACKUP_KEEP_COUNT konfiguriert (standardmäßig werden maximal 3 Backups für 30 Tage aufbewahrt).

Automatisierte Datensicherung mit BorgBackup

Neu in Version 3.9.

Weblate hat integrierte Unterstützung für die Erstellung von Service-Backups mit BorgBackup. Borg erstellt platzsparende verschlüsselte Backups, die sicher in der Cloud gespeichert werden können. Die Backups können in der Verwaltungsoberfläche über den Reiter Sicherungen gesteuert werden.

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

Borg-Verschlüsselungsschlüssel

BorgBackup erstellt verschlüsselte Backups, die Sie ohne die Passphrase nicht wiederherstellen können. Die Passphrase wird beim Hinzufügen eines neuen Backup-Dienstes generiert und Sie sollten sie kopieren und an einem sicheren Ort aufbewahren.

Wenn Sie Von Weblate bereitgestellter Backup-Speicher verwenden, sichern Sie bitte auch Ihren privaten SSH-Schlüssel, da dieser für den Zugriff auf Ihre Backups verwendet wird.

Siehe auch

borg init

Backup anpassen

• Das Datenbank-Backup kann über DATABASE_BACKUP konfiguriert werden.

• Die Erstellung von Sicherungskopien kann mit BORG_EXTRA_ARGS angepasst werden.

Von Weblate bereitgestellter Backup-Speicher

Der einfachste Weg, Ihre Weblate-Instanz zu sichern, ist der Erwerb des Backup-Service unter weblate.org. So bringen Sie ihn zum Laufen:

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 Support integrieren.

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

4. Aktivieren Sie die neue Sicherungskonfiguration auf der Reiterkarte Sicherungen.

5. Sichern Sie Ihre Borg-Zugangsdaten, um die Backups wiederherstellen zu können, siehe Borg-Verschlüsselungsschlüssel.

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

Siehe auch

Weblate-SSH-Schlüssel, General

Wiederherstellung aus BorgBackup

1. Stellen Sie den Zugriff auf Ihr Backup-Repository wieder her und bereiten Sie Ihre Backup-Passphrase vor.

2. Listen Sie mit borg list REPOSITORY alle Backups auf dem Server auf.

3. Stellen Sie die gewünschte Sicherung mit borg extract REPOSITORY::ARCHIVE in das aktuelle Verzeichnis wieder her.

4. Stellen Sie die Datenbank aus dem SQL-Dump wieder her, der sich im Verzeichnis backup im Weblate-Datenverzeichnis befindet (siehe Gedumpte Daten für Backups).

5. Kopieren Sie die Weblate-Konfiguration (backups/settings.py, siehe Gedumpte Daten für Backups) an den richtigen Ort, siehe Anpassen der Konfiguration.

   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 Gedumpte Daten für Backups).

6. Kopieren Sie das gesamte wiederhergestellte Datenverzeichnis an den mit DATA_DIR konfigurierten Ort.

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

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

Die Borg-Sitzung könnte wie folgt aussehen:

$ 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

Manuelle Sicherung

Je nachdem, was Sie speichern möchten, sichern Sie die Art der Daten, die Weblate an den jeweiligen Stellen speichert.

Hinweis

Wenn Sie manuelle Backups durchführen, können Sie die Warnung von Weblate über fehlende Backups ausschalten, indem Sie weblate.I028 zu SILENCED_SYSTEM_CHECKS in settings.py oder WEBLATE_SILENCED_SYSTEM_CHECKS für Docker hinzufügen.

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

Datenbank

Der tatsächliche Speicherort hängt von der Einrichtung Ihrer Datenbank ab.

Hinweis

Die Datenbank ist der wichtigste Speicher. Legen Sie regelmäßig Sicherungskopien Ihrer Datenbank an. Ohne die Datenbank sind alle Übersetzungen verloren.

Native Datenbanksicherung

Es wird empfohlen, einen Dump der Datenbank mit datenbankeigenen Tools wie pg_dump oder mysqldump zu speichern. Diese Methode ist normalerweise leistungsfähiger als das Django-Backup und stellt vollständige Tabellen mit allen Daten wieder her.

Sie können dieses Backup in einer neueren Version von Weblate wiederherstellen. Es wird alle notwendigen Migrationen durchführen, wenn es in migrate ausgeführt wird. Bitte konsultieren Sie Upgrade von Weblate für detailliertere Informationen über das Upgrade zwischen Versionen.

Sicherung der Django-Datenbank

Alternativ können Sie Ihre Datenbank auch mit dem Befehl dumpdata von Django sichern. Auf diese Weise ist die Sicherung datenbankunabhängig und kann verwendet werden, falls Sie das Datenbank-Backend ändern möchten.

Bevor Sie die Datenbank wiederherstellen, müssen Sie genau dieselbe Weblate-Version verwenden, mit der die Sicherung erstellt wurde. Dies ist notwendig, da sich die Datenbankstruktur zwischen den einzelnen Versionen ändert und Sie die Daten auf irgendeine Weise beschädigen würden. Nachdem Sie die gleiche Version installiert haben, führen Sie alle Datenbankmigrationen mit migrate durch.

Danach werden einige Einträge bereits in der Datenbank erstellt und sind auch in der Datenbanksicherung enthalten. Es wird empfohlen, solche Einträge manuell über die Verwaltungsshell zu löschen (siehe Aufrufen von Verwaltungsbefehlen):

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

Dateien

Wenn Sie genügend Speicherplatz haben, sichern Sie einfach das gesamte DATA_DIR. Das ist eine sichere Sache, auch wenn es einige Dateien enthält, die Sie nicht wollen. In den folgenden Abschnitten wird detailliert beschrieben, was Sie sichern sollten und was Sie weglassen können.

Gedumpte Daten für Backups

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

Gespeichert in DATA_DIR /backups.

Weblate legt hier verschiedene Daten ab, und Sie können diese Dateien für vollständigere Backups einbinden. Die Dateien werden täglich aktualisiert (erfordert einen laufenden Celery-Beats-Server, siehe Hintergrundaufgaben mit Celery). Derzeit umfasst dies:

• Weblate-Einstellungen als settings.py (es gibt auch eine erweiterte Version in settings-expanded.py).

• Sicherung der PostgreSQL-Datenbank als Datenbank.sql.

• Umgebungsdump als environment.yml.

Die Datenbanksicherungen werden standardmäßig als reiner Text gespeichert, können aber auch komprimiert oder mit DATABASE_BACKUP ganz übersprungen werden.

Um die Datenbanksicherung wiederherzustellen, laden Sie sie z. B. mit Hilfe der Datenbank-Tools:

psql --file=database.sql weblate

Repositorys der Versionskontrolle

Gespeichert 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- und GPG-Schlüssel

Gespeichert in DATA_DIR /ssh und DATA_DIR /home.

Wenn Sie SSH- oder GPG-Schlüssel verwenden, die von Weblate generiert wurden, sollten Sie von diesen Speicherorten ein Backup erstellen. Andernfalls gehen die privaten Schlüssel verloren und Sie müssen neue Schlüssel generieren.

Vom Benutzer hochgeladene Dateien

Gespeichert in DATA_DIR /media.

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

Aufgaben von Celery

Die Celery-Aufgabenwarteschlange kann einige Informationen enthalten, wird aber normalerweise nicht für ein Backup benötigt. Sie verlieren höchstens Aktualisierungen, die noch nicht im Translation Memory verarbeitet wurden. Es wird ohnehin empfohlen, bei der Wiederherstellung eine Volltext- oder Repository-Aktualisierung durchzuführen, so dass es kein Problem ist, diese zu verlieren.

Siehe auch

Hintergrundaufgaben mit Celery

Befehlszeile für manuelles Backup

Mit einem Cron-Job können Sie einen Bash-Befehl einrichten, der z. B. täglich ausgeführt wird:

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

Die Zeichenkette zwischen den Anführungszeichen nach XZ_OPT erlaubt es Ihnen, Ihre xz-Optionen auszuwählen, zum Beispiel die Menge an Speicher, die für die Kompression verwendet wird; siehe https://linux.die.net/man/1/xz

Sie können die Liste der Ordner und Dateien an Ihre Bedürfnisse anpassen. Um zu vermeiden, dass das Translation Memory (im Ordner „Backups“) gespeichert wird, können Sie diese Option verwenden:

$ 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

Wiederherstellen der manuellen Sicherung

1. Stellen Sie alle von Ihnen gesicherten Daten wieder her.

2. Aktualisieren Sie alle Repositorys mit updategit.

   weblate updategit --all
   

Verschieben einer Weblate-Installation

Verschieben Sie Ihre Installation auf ein anderes System, indem Sie die obigen Anweisungen zum Sichern und Wiederherstellen befolgen.

Siehe auch

Upgrade von Python 2 auf Python 3, Migration von anderen Datenbanken zu PostgreSQL