Fix some backup-related translations and
language issues, especially translated commands and a half-translated example script.
Dieser Commit ist enthalten in:
Florian Hillebrand
Ursprung
18aa341ee0
Commit
9956aa9c49
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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!
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
Laden …
In neuem Issue referenzieren