Sichern und Verschieben von Weblate

Sicherungen auf Projektebene

Added in version 4.14.

Warnung

Die Wiederherstellung von Sicherungen 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 Übersetzungsprojekte und Komponenten hinzufügen).

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 Sicherungen werden auf dem Server aufbewahrt, wie durch PROJECT_BACKUP_KEEP_DAYS und PROJECT_BACKUP_KEEP_COUNT konfiguriert (standardmäßig werden maximal 3 Sicherungen für 30 Tage aufbewahrt).

Use the generated file to import project when Übersetzungsprojekte und Komponenten hinzufügen.

Bemerkung

Das Wiederherstellen der Sicherung kann fehlschlagen, wenn der wiederherstellende Server einen anderen Satz von Sprachdefinitionen oder eine andere Konfiguration von SIMPLIFY_LANGUAGES hat. Bei der Wiederherstellung wird Ihnen mitgeteilt, welche Sprachcodes nicht verarbeitet werden konnten, und Sie können dann die fehlenden Sprachdefinitionen manuell hinzufügen.

Automatisierte Datensicherung mit BorgBackup

Weblate bietet integrierte Unterstützung für das Erstellen von Sicherungen mit BorgBackup. Borg erstellt platzsparende verschlüsselte Sicherungen, die sicher in der Cloud gespeichert werden können. Die Sicherungen 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 Sicherungen enthalten.

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

  • Tägliche Sicherungen der letzten 14 Tage

  • Wöchentliche Sicherungen der letzten 8 Wochen

  • Monatliche Sicherungen der letzten 6 Monate

../_images/backups.webp

Borg-Verschlüsselungsschlüssel

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

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

Siehe auch

borg init

Sicherung anpassen

  • Die Datenbanksicherung kann über DATABASE_BACKUP konfiguriert werden.

  • Die Erstellung von Sicherungskopien kann mit BORG_EXTRA_ARGS angepasst werden.

Von Weblate bereitgestellter Sicherungsspeicher

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

  1. Erwerben Sie den Sicherungsdienst 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 Sicherungen 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 das Sicherungs-Repository gesendet, welches Sie durch den Registrierungsprozess erhalten haben.

Verwendung von eigenem Sicherungsspeicher

Sie können auch Ihren eigenen Speicher für die Sicherungen verwenden. SSH kann verwendet werden, um Sicherungen im Remote-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 die lokale Sicherung 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 der Sicherung vom Weblate-Container als Volume freigegeben wird. Andernfalls werden die Sicherungen beim Neustart des Containers, in dem sie sich befinden, von Docker verworfen.

Eine Möglichkeit ist, Sicherungen 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 Sicherungen 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 Sicherungen gespeichert werden, muss der UID 1000 gehören, ansonsten kann Weblate die Sicherungen nicht dorthin schreiben.

Remote-Sicherungen

Um Remote-Sicherungen 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 Sicherungen 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 Speicherort der Sicherung in Weblate als user@host:/path/to/backups oder ssh://user@host:port/path/to/backups.

Hinweis

Von Weblate bereitgestellter Sicherungsspeicher bietet Ihnen automatisierte Remote-Sicherungen ohne jeglichen Aufwand.

Siehe auch

Weblate-SSH-Schlüssel, General

Wiederherstellung aus BorgBackup

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

  2. Listen Sie mit borg list REPOSITORY alle Sicherungen 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-Auszug wieder her, der sich im Verzeichnis backup im Weblate-Datenverzeichnis befindet (siehe Ausgegebene Daten für Sicherungen).

  5. Kopieren Sie die Weblate-Konfiguration (backups/settings.py, siehe Ausgegebene Daten für Sicherungen) 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 Ausgegebene Daten für Sicherungen).

  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 Sicherungen durchführen, können Sie die Warnung von Weblate über fehlende Sicherungen 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 Auszug der Datenbank mit datenbankeigenen Tools wie pg_dump oder mysqldump zu speichern. Diese Methode ist normalerweise leistungsfähiger als die Django-Sicherung und stellt vollständige Tabellen mit allen Daten wieder her.

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

Django-Datenbanksicherung

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.

Ausgegebene Daten für Sicherungen

Geändert in Version 4.7: Die Ausgabe der Einsatzumgebung 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 Sicherungen 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.

  • Ausgabe der Einsatzumgebung 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 Versionsverwaltung

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 erzeugt wurden, sollten Sie von diesen Speicherorten eine Sicherung erstellen. Andernfalls gehen die privaten Schlüssel verloren und Sie müssen neue Schlüssel erzeugen.

Vom Benutzer hochgeladene Dateien

Gespeichert in DATA_DIR /media.

Sie sollten alle vom Benutzer hochgeladenen Dateien sichern (z. B. Visueller Kontext für Zeichenketten).

Aufgaben von Celery

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

Siehe auch

Hintergrundaufgaben mit Celery

Befehlszeile für manuelle Sicherung

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

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

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

$ 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 in der Weblate-3.11.1-Dokumentation, Migration von anderen Datenbanken zu PostgreSQL