From 9956aa9c49e7c4403d329570d3c690aa57b87620 Mon Sep 17 00:00:00 2001 From: Florian Hillebrand Date: Mon, 27 Jun 2022 19:14:02 +0200 Subject: [PATCH] Fix some backup-related translations and language issues, especially translated commands and a half-translated example script. --- .../b_n_r-accidental_deletion.de.md | 4 +-- docs/backup_restore/b_n_r-backup.de.md | 33 ++++--------------- .../b_n_r-backup_restore-maildir.de.md | 6 ++-- .../b_n_r-backup_restore-mysql.de.md | 2 +- docs/backup_restore/b_n_r-coldstandby.de.md | 12 +++---- docs/backup_restore/b_n_r-coldstandby.en.md | 10 +++--- 6 files changed, 24 insertions(+), 43 deletions(-) diff --git a/docs/backup_restore/b_n_r-accidental_deletion.de.md b/docs/backup_restore/b_n_r-accidental_deletion.de.md index d0cbbc489..9677b497b 100644 --- a/docs/backup_restore/b_n_r-accidental_deletion.de.md +++ b/docs/backup_restore/b_n_r-accidental_deletion.de.md @@ -6,7 +6,7 @@ Wenn Sie Ihren Fehler innerhalb von ein paar Stunden bemerken, können Sie die D Wir erstellen automatisch tägliche Backups (24 Stunden Intervall ab dem Hochfahren -d) in `/var/lib/docker/volumes/mailcowdockerized_sogo-userdata-backup-vol-1/_data/`. -**Stellen Sie sicher, dass der Benutzer, den Sie wiederherstellen wollen, in Ihrem Mailcow-Backend** existiert. Legen Sie diesen neu an, falls nicht mehr existent. +**Stellen Sie sicher, dass der Benutzer, den Sie wiederherstellen wollen, in Ihrem Mailcow-Backend existiert**. Legen Sie diesen neu an, falls nicht mehr existent. Kopieren Sie die Datei mit dem Namen des Benutzers, den Sie wiederherstellen wollen, nach `__MAILCOW_DIRECTORY__/data/conf/sogo`. @@ -28,7 +28,7 @@ Eine gelöschte Mailbox wird in ihrer verschlüsselten Form nach `/var/lib/docke Der Ordner innerhalb von `_garbage` folgt der Struktur `[timestamp]_[domain_sanitized][user_sanitized]`, zum Beispiel `1629109708_exampleorgtest` im Falle von test@example.org, das am 1629109708 gelöscht wurde. -Um die Mailbox wiederherzustellen, stellen Sie sicher, dass Sie tatsächlich auf die gleiche Mailcow wiederherstellen, von der sie gelöscht wurde, oder Sie verwenden die gleichen Verschlüsselungsschlüssel in `crypt-vol-1`. +Um die Mailbox wiederherzustellen, stellen Sie sicher, dass Sie tatsächlich auf die gleiche Mailcow wiederherstellen, von der sie gelöscht wurde, oder Sie die gleichen Verschlüsselungsschlüssel in `crypt-vol-1` verwenden. **Stellen Sie sicher, dass der Benutzer, den Sie wiederherstellen wollen, in Ihrer Mailcow existiert**. Legen Sie diesen neu an, wenn der Benutzer fehlt. diff --git a/docs/backup_restore/b_n_r-backup.de.md b/docs/backup_restore/b_n_r-backup.de.md index 453fca8c4..d3d185266 100644 --- a/docs/backup_restore/b_n_r-backup.de.md +++ b/docs/backup_restore/b_n_r-backup.de.md @@ -25,9 +25,9 @@ Sie können auch "all" als zweiten Parameter verwenden, um alle Komponenten zu s ``` Das Skript wird Sie nach einem Speicherort für die Sicherung fragen. Innerhalb dieses Speicherortes wird es Ordner im Format "mailcow_DATE" erstellen. -Sie sollten diese Ordner nicht umbenennen, um den Wiederherstellungsprozess nicht zu unterbrechen. +Sie sollten diese Ordner nicht umbenennen, um den Wiederherstellungsprozess nicht zu stören. -Um ein Backup unbeaufsichtigt durchzuführen, definieren Sie MAILCOW_BACKUP_LOCATION als Umgebungsvariable bevor Sie das Skript starten: +Um ein Backup unbeaufsichtigt durchzuführen, definieren Sie MAILCOW_BACKUP_LOCATION als Umgebungsvariable, bevor Sie das Skript starten: ``` MAILCOW_BACKUP_LOCATION=/opt/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all @@ -41,7 +41,7 @@ Sie können das Backup-Skript regelmäßig über einen Cronjob laufen lassen. St 5 4 * * * cd /opt/mailcow-dockerized/; MAILCOW_BACKUP_LOCATION=/mnt/mailcow_backups /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup mysql crypt redis --delete-days 3 ``` -Standardmäßig sendet Cron das komplette Ergebnis jeder Backup-Operation per E-Mail. Wenn Sie möchten, dass cron nur im Fehlerfall (Exit-Code ungleich Null) eine E-Mail sendet, können Sie den folgenden Ausschnitt verwenden. Die Pfade müssen entsprechend Ihrer Einrichtung angepasst werden (dieses Skript ist ein Beitrag des Benutzers). +Standardmäßig sendet Cron das komplette Ergebnis jeder Backup-Operation per E-Mail. Wenn Sie möchten, dass cron nur im Fehlerfall (Exit-Code ungleich Null) eine E-Mail sendet, können Sie den folgenden Ausschnitt verwenden. Die Pfade müssen entsprechend Ihrer Einrichtung angepasst werden (dieses Skript ist ein Beitrag eines Benutzers). Das folgende Skript kann in `/etc/cron.daily/mailcow-backup` platziert werden - vergessen Sie nicht, es mit `chmod +x` als ausführbar zu markieren: @@ -68,25 +68,6 @@ if [ $RESULT -ne 0 ] then echo "${SCRIPT} ${PARAMETERS} ${OPTIONS} encounters an error:" echo "RESULT=$RESULT" -# https://mailcow.github.io/mailcow-dockerized-docs/b_n_r_backup/ - -set -e - -OUT="$(mktemp)" -export MAILCOW_BACKUP_LOCATION="/opt/backup" -SCRIPT="/opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh" -PARAMETERS="alle sichern" -OPTIONS="--delete-days 30" - -# Befehl ausführen -setzen +e -"${SCRIPT}" ${PARAMETERS} ${OPTIONS} 2>&1 > "$OUT" -ERGEBNIS=$? - -if [ $RESULT -ne 0 ] - dann - echo "${SCRIPT} ${PARAMETER} ${OPTIONS} ist auf einen Fehler gestoßen:" - echo "ERGEBNIS=$ERGEBNIS" echo "STDOUT / STDERR:" cat "$OUT" fi @@ -104,13 +85,13 @@ Cronjobs erstellen: 25 1 * * * rsync -aH --delete /opt/mailcow-dockerized /external_share/backups/mailcow-dockerized 40 2 * * * rsync -aH --delete /var/lib/docker/volumes /external_share/backups/var_lib_docker_volumes 5 4 * * * cd /opt/mailcow-dockerized/; BACKUP_LOCATION=/external_share/backups/backup_script /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup mysql crypt redis --delete-days 3 -# Wenn Sie wollen, benutzen Sie acl util, um die Berechtigungen einiger/aller Ordner/Dateien zu sichern: getfacl -Rn /path +# Wenn Sie wollen, benutzen Sie das Werkzeug acl, um die Berechtigungen einiger/aller Ordner/Dateien zu sichern: getfacl -Rn /path ``` -Am Zielort (in diesem Fall `/external_share/backups`) möchten Sie vielleicht Snapshot-Fähigkeiten haben (ZFS, Btrfs usw.). Machen Sie täglich einen Snapshot und bewahren Sie ihn für n Tage auf, um ein konsistentes Backup zu erhalten. -Führen Sie **kein** rsync auf eine Samba-Freigabe durch, Sie müssen die richtigen Berechtigungen einhalten! +Am Zielort (in diesem Fall `/external_share/backups`) möchten Sie vielleicht Snapshot-Möglichkeiten haben (ZFS, Btrfs usw.). Machen Sie täglich einen Snapshot und bewahren Sie ihn für n Tage auf, um ein konsistentes Backup zu erhalten. +Führen Sie **kein** rsync auf eine Samba-Freigabe durch, Sie müssen die richtigen Berechtigungen behalten! Zum Wiederherstellen müssen Sie rsync einfach in umgekehrter Richtung ausführen und Docker neu starten, um die Volumes erneut zu lesen. Führen Sie `docker-compose pull` und `docker-compose up -d` aus. -Wenn Sie Glück haben, können Redis und MariaDB die inkonsistenten Datenbanken automatisch reparieren (wenn sie _inkonsistent_ sind). +Wenn Sie Glück haben, können Redis und MariaDB die inkonsistenten Datenbanken automatisch reparieren (wenn sie inkonsistent _sind_). Im Falle einer beschädigten Datenbank müssen Sie das Hilfsskript verwenden, um die inkonsistenten Elemente wiederherzustellen. Wenn die Wiederherstellung fehlschlägt, versuchen Sie, die Sicherungen zu extrahieren und die Dateien manuell zurück zu kopieren. Behalten Sie die Dateiberechtigungen bei! \ No newline at end of file diff --git a/docs/backup_restore/b_n_r-backup_restore-maildir.de.md b/docs/backup_restore/b_n_r-backup_restore-maildir.de.md index c852aafc3..1cb93f478 100644 --- a/docs/backup_restore/b_n_r-backup_restore-maildir.de.md +++ b/docs/backup_restore/b_n_r-backup_restore-maildir.de.md @@ -3,11 +3,11 @@ Diese Zeile sichert das vmail-Verzeichnis in eine Datei backup_vmail.tar.gz im mailcow-Root-Verzeichnis: ``` cd /pfad/zu/mailcow-dockerized -docker run --rm -i -v $(docker inspect --format '{{ range .Mounts }}{{ if eq .Destination "/var/vmail" }}{{ .Name }}{{ end }}{{{ end }}' $(docker-compose ps -q dovecot-mailcow)):/vmail -v ${PWD}:/backup debian:stretch-slim tar cvfz /backup/backup_vmail.tar.gz /vmail +docker run --rm -i -v $(docker inspect --format '{{ range .Mounts }}{{ if eq .Destination "/var/vmail" }}{{ .Name }}{{ end }}{{ end }}' $(docker-compose ps -q dovecot-mailcow)):/vmail -v ${PWD}:/backup debian:stretch-slim tar cvfz /backup/backup_vmail.tar.gz /vmail ``` -Sie können den Pfad ändern, indem Sie ${PWD} (das dem aktuellen Verzeichnis entspricht) an einen beliebigen Pfad anpassen, auf den Sie Schreibzugriff haben. -Setzen Sie den Dateinamen `backup_vmail.tar.gz` auf einen beliebigen Namen, aber lassen Sie den Pfad so wie er ist. Beispiel: `[...] tar cvfz /backup/mein_eigener_filename_.tar.gz` +Sie können den Pfad ändern, indem Sie ${PWD} (das dem aktuellen Verzeichnis entspricht) zu einem beliebigen Pfad ändern, auf den Sie Schreibzugriff haben. +Setzen Sie den Dateinamen `backup_vmail.tar.gz` auf einen beliebigen Namen, aber lassen Sie den Pfad so wie er ist. Beispiel: `[...] tar cvfz /backup/mein_eigener_dateiname_.tar.gz` ### Wiederherstellen ``` diff --git a/docs/backup_restore/b_n_r-backup_restore-mysql.de.md b/docs/backup_restore/b_n_r-backup_restore-mysql.de.md index 80035550e..adb74a691 100644 --- a/docs/backup_restore/b_n_r-backup_restore-mysql.de.md +++ b/docs/backup_restore/b_n_r-backup_restore-mysql.de.md @@ -3,7 +3,7 @@ ``` cd /pfad/zu/mailcow-dockerized source mailcow.conf -DATE=$(Datum +"%Y%m%d_%H%M%S") +DATE=$(date +"%Y%m%d_%H%M%S") docker-compose exec -T mysql-mailcow mysqldump --default-character-set=utf8mb4 -u${DBUSER} -p${DBPASS} ${DBNAME} > backup_${DBNAME}_${DATE}.sql ``` diff --git a/docs/backup_restore/b_n_r-coldstandby.de.md b/docs/backup_restore/b_n_r-coldstandby.de.md index 443dfa4d7..421511e97 100644 --- a/docs/backup_restore/b_n_r-coldstandby.de.md +++ b/docs/backup_restore/b_n_r-coldstandby.de.md @@ -8,13 +8,13 @@ Dies kann auch verwendet werden, um Ihre mailcow auf einen neuen Server zu über Das bereitgestellte Skript funktioniert auf Standardinstallationen. -Es kann kaputt gehen, wenn Sie nicht unterstützte Volume Overrides verwenden. Wir unterstützen das nicht und wir werden keine Hacks einbauen, die das unterstützen. Bitte erstellen und pflegen Sie einen Fork, wenn Sie Ihre Änderungen beibehalten wollen. +Es kann versagen, wenn Sie nicht unterstützte Volume Overrides verwenden. Wir unterstützen das nicht und wir werden keine Hacks einbauen, die das unterstützen. Bitte erstellen und pflegen Sie einen Fork, wenn Sie Ihre Änderungen beibehalten wollen. Das Skript wird **die gleichen Pfade** wie Ihre Standard-Mailcow-Installation verwenden. Das ist das mailcow-Basisverzeichnis - für die meisten Nutzer `/opt/mailcow-dockerized` - sowie die Mountpoints. Um die Pfade Ihrer Quellvolumes zu finden, verwenden wir `docker inspect` und lesen das Zielverzeichnis jedes Volumes, das mit Ihrem mailcow compose Projekt verbunden ist. Das bedeutet, dass wir auch Volumes übertragen, die Sie in einer Override-Datei hinzugefügt haben. Lokale Bind-Mounts können funktionieren, müssen aber nicht. -Die Verwendung von rsync mit dem `--delete` Flag. Das Ziel wird eine exakte Kopie der Quelle sein. +Das Skript verwendet rsync mit dem `--delete` Flag. Das Ziel wird eine exakte Kopie der Quelle sein. `mariabackup` wird verwendet, um eine konsistente Kopie des SQL-Datenverzeichnisses zu erstellen. @@ -22,7 +22,7 @@ Nach dem Rsync der Daten führen wir `docker-compose pull` aus und entfernen alt Ihre Quelle wird zu keinem Zeitpunkt verändert. -**Sie sollten sicherstellen, dass Sie die gleiche `/etc/docker/daemon.json` auf dem entfernten Ziel verwenden. +**Sie sollten sicherstellen, dass Sie die gleiche `/etc/docker/daemon.json` auf dem entfernten Ziel verwenden.** Sie sollten keine Festplatten-Snapshots (z. B. über ZFS, LVM usw.) auf dem Ziel ausführen, während dieses Skript ausgeführt wird. @@ -37,7 +37,7 @@ In Ihrem mailcow-Basisverzeichnis, z.B. `/opt/mailcow-dockerized`, finden Sie ei Bearbeiten Sie diese Datei und ändern Sie die exportierten Variablen: ``` -export REMOTE_SSH_KEY=/pfad/zur/keyfile +export REMOTE_SSH_KEY=/pfad/zum/keyfile export REMOTE_SSH_PORT=22 export REMOTE_SSH_HOST=mailcow-backup.host.name ``` @@ -45,7 +45,7 @@ export REMOTE_SSH_HOST=mailcow-backup.host.name Der Schlüssel muss im Besitz von root sein und darf nur von diesem gelesen werden können. Sowohl die Quelle als auch das Ziel benötigen `rsync` >= v3.1.0. -Das Ziel muss über Docker und docker-compose **v1** verfügen. +Das Ziel muss über Docker und docker-compose **v2** verfügen. Das Skript wird Fehler automatisch erkennen und sich beenden. @@ -91,7 +91,7 @@ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 0 3 * * * bash /opt/mailcow-dockerized/create_cold_standby.sh 2> /var/log/mailcow-coldstandby-sync.log ``` -Wenn korrekt gespeichert, sollte der Cron-Job durch Eingabe angezeigt werden: +Wenn korrekt gespeichert, sollte der Cron-Job durch folgende Eingabe angezeigt werden: ``` crontab -l diff --git a/docs/backup_restore/b_n_r-coldstandby.en.md b/docs/backup_restore/b_n_r-coldstandby.en.md index fef1017e1..7ae14b673 100644 --- a/docs/backup_restore/b_n_r-coldstandby.en.md +++ b/docs/backup_restore/b_n_r-coldstandby.en.md @@ -10,11 +10,11 @@ The provided script will work on default installations. It may break when you use unsupported volume overrides. We don't support that and we will not include hacks to support that. Please run and maintain a fork if you plan to keep your changes. -The script will use **the same pathes** as your default mailcow installation. That is the mailcow base directory - for most users `/opt/mailcow-dockerized` - as well as the mountpoints. +The script will use **the same paths** as your default mailcow installation. That is the mailcow base directory - for most users `/opt/mailcow-dockerized` - as well as the mountpoints. -To find the pathes of your source volumes we use `docker inspect` and read the destination directory of every volume related to your mailcow compose project. This means we will also transfer volumes you may have added in a override file. Local bind mounts may or may not work. +To find the paths of your source volumes we use `docker inspect` and read the destination directory of every volume related to your mailcow compose project. This means we will also transfer volumes you may have added in an override file. Local bind mounts may or may not work. -The use rsync with the `--delete` flag. The destination will be an exact copy of the source. +The script uses rsync with the `--delete` flag. The destination will be an exact copy of the source. `mariabackup` is used to create a consistent copy of the SQL data directory. @@ -30,7 +30,7 @@ Versioning is not part of this script, we rely on the destination (snapshots or ## Prepare -You will need a SSH-enabled destination and a keyfile to connect to said destination. The key should not be protected by a password for the script to work unattended. +You will need an SSH-enabled destination and a keyfile to connect to said destination. The key should not be protected by a password for the script to work unattended. In your mailcow base directory, e.g. `/opt/mailcow-dockerized` you will find a file `create_cold_standby.sh`. @@ -45,7 +45,7 @@ export REMOTE_SSH_HOST=mailcow-backup.host.name The key must be owned and readable by root only. Both the source and destination require `rsync` >= v3.1.0. -The destination must have Docker and docker-compose **v1** available. +The destination must have Docker and docker-compose **v2** available. The script will detect errors automatically and exit.