Added Backup&Restore Section + Translation to German
Dieser Commit ist enthalten in:
DerLinkman
Ursprung
971b7ce3a9
Commit
c2bcc40c48
16 geänderte Dateien mit 594 neuen und 9 gelöschten Zeilen
40
docs/backup_restore/b_n_r-accidental_deletion.de.md
Normale Datei
40
docs/backup_restore/b_n_r-accidental_deletion.de.md
Normale Datei
|
|
@ -0,0 +1,40 @@
|
|||
Sie haben also ein Postfach gelöscht und haben keine Sicherungskopien, was?
|
||||
|
||||
Wenn Sie Ihren Fehler innerhalb von ein paar Stunden bemerken, können Sie die Daten des Benutzers wahrscheinlich wiederherstellen.
|
||||
|
||||
### SOGo
|
||||
|
||||
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 Ihrer Mailcow** existiert. Legen Sie sie neu an, falls sie fehlen.
|
||||
|
||||
Kopieren Sie die Datei mit dem Namen des Benutzers, den Sie wiederherstellen wollen, nach `__MAILCOW_DIRECTORY__/data/conf/sogo`.
|
||||
|
||||
1\. Kopieren Sie die Sicherung: `cp /var/lib/docker/volumes/mailcowdockerized_sogo-userdata-backup-vol-1/_data/restoreme@example.org __MAILCOW_DIRECTORY__/data/conf/sogo`
|
||||
|
||||
2\. Starten Sie `docker-compose exec -u sogo sogo-mailcow sogo-tool restore -F ALL /etc/sogo restoreme@example.org`.
|
||||
|
||||
Führen Sie `sogo-tool` ohne Parameter aus, um nach möglichen Wiederherstellungsoptionen zu suchen.
|
||||
|
||||
3\. Löschen Sie die kopierte Sicherung, indem Sie `rm __MAILCOW_DIRECTORY__/data/conf/sogo` ausführen
|
||||
|
||||
4\. Starten Sie SOGo und Memcached neu: `docker-compose restart sogo-mailcow memcached-mailcow`
|
||||
|
||||
### Mail
|
||||
|
||||
Im Falle einer versehentlichen Löschung einer Mailbox, können Sie diese (standardmäßig) 5 Tage lang wiederherstellen. Dies hängt von dem `MAILDIR_GC_TIME` Parameter in `mailcow.conf` ab.
|
||||
|
||||
Eine gelöschte Mailbox wird in ihrer verschlüsselten Form nach `/var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage` kopiert.
|
||||
|
||||
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 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`.
|
||||
|
||||
**Stellen Sie sicher, dass der Benutzer, den Sie wiederherstellen wollen, in Ihrer Mailcow existiert**. Legen Sie sie neu an, wenn sie fehlen.
|
||||
|
||||
Kopieren Sie die Ordner von `/var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage/[timestamp]_[domain_sanitized][user_sanitized]` zurĂĽck nach `/var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/[domain]/[user]` und synchronisieren Sie die Ordner neu und berechnen Sie die Quote neu:
|
||||
|
||||
```
|
||||
docker-compose exec dovecot-mailcow doveadm force-resync -u restoreme@example.net '*'
|
||||
docker-compose exec dovecot-mailcow doveadm quota recalc -u restoreme@example.net
|
||||
```
|
||||
40
docs/backup_restore/b_n_r-accidental_deletion.en.md
Normale Datei
40
docs/backup_restore/b_n_r-accidental_deletion.en.md
Normale Datei
|
|
@ -0,0 +1,40 @@
|
|||
So you deleted a mailbox and have no backups, he?
|
||||
|
||||
If you noticed your mistake within a few hours, you can probably recover the users data.
|
||||
|
||||
### SOGo
|
||||
|
||||
We automatically create daily backups (24h interval starting from running up -d) in `/var/lib/docker/volumes/mailcowdockerized_sogo-userdata-backup-vol-1/_data/`.
|
||||
|
||||
**Make sure the user you want to restore exists in your mailcow**. Re-create them if they are missing.
|
||||
|
||||
Copy the file named after the user you want to restore to `__MAILCOW_DIRECTORY__/data/conf/sogo`.
|
||||
|
||||
1\. Copy the backup: `cp /var/lib/docker/volumes/mailcowdockerized_sogo-userdata-backup-vol-1/_data/restoreme@example.org __MAILCOW_DIRECTORY__/data/conf/sogo`
|
||||
|
||||
2\. Run `docker-compose exec -u sogo sogo-mailcow sogo-tool restore -F ALL /etc/sogo restoreme@example.org`
|
||||
|
||||
Run `sogo-tool` without parameters to check for possible restore options.
|
||||
|
||||
3\. Delete the copied backup by running `rm __MAILCOW_DIRECTORY__/data/conf/sogo`
|
||||
|
||||
4\. Restart SOGo and Memcached: `docker-compose restart sogo-mailcow memcached-mailcow`
|
||||
|
||||
### Mail
|
||||
|
||||
In case of an accidental deletion of a mailbox, you will be able to recover for (by default) 5 days. This depends on the `MAILDIR_GC_TIME` parameter in `mailcow.conf`.
|
||||
|
||||
A deleted mailbox is copied in its encrypted form to `/var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage`.
|
||||
|
||||
The folder inside `_garbage` follows the structure `[timestamp]_[domain_sanitized][user_sanitized]`, for example `1629109708_exampleorgtest` in case of test@example.org deleted on 1629109708.
|
||||
|
||||
To restore make sure you are actually restoring to the same mailcow it was deleted from or you use the same encryption keys in `crypt-vol-1`.
|
||||
|
||||
**Make sure the user you want to restore exists in your mailcow**. Re-create them if they are missing.
|
||||
|
||||
Copy the folders from `/var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/_garbage/[timestamp]_[domain_sanitized][user_sanitized]` back to `/var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/[domain]/[user]` and resync the folder and recalc the quota:
|
||||
|
||||
```
|
||||
docker-compose exec dovecot-mailcow doveadm force-resync -u restoreme@example.net '*'
|
||||
docker-compose exec dovecot-mailcow doveadm quota recalc -u restoreme@example.net
|
||||
```
|
||||
116
docs/backup_restore/b_n_r-backup.de.md
Normale Datei
116
docs/backup_restore/b_n_r-backup.de.md
Normale Datei
|
|
@ -0,0 +1,116 @@
|
|||
### Sicherung
|
||||
|
||||
#### Anleitung
|
||||
|
||||
Sie können das mitgelieferte Skript `helper-scripts/backup_and_restore.sh` verwenden, um mailcow automatisch zu sichern.
|
||||
|
||||
Bitte kopieren Sie dieses Skript nicht an einen anderen Ort.
|
||||
|
||||
Um ein Backup zu starten, geben Sie "backup" als ersten Parameter an und entweder eine oder mehrere zu sichernde Komponenten als folgende Parameter.
|
||||
Sie können auch "all" als zweiten Parameter verwenden, um alle Komponenten zu sichern. Fügen Sie `--delete-days n` an, um Sicherungen zu löschen, die älter als n Tage sind.
|
||||
|
||||
```
|
||||
# Syntax:
|
||||
# ./helper-scripts/backup_and_restore.sh backup (vmail|crypt|redis|rspamd|postfix|mysql|all|--delete-days)
|
||||
|
||||
# Alles sichern, Sicherungen älter als 3 Tage löschen
|
||||
./helper-scripts/backup_and_restore.sh backup all --delete-days 3
|
||||
|
||||
# vmail-, crypt- und mysql-Daten sichern, Sicherungen löschen, die älter als 30 Tage sind
|
||||
./helper-scripts/backup_and_restore.sh backup vmail crypt mysql --delete-days 30
|
||||
|
||||
# vmail sichern
|
||||
./helper-scripts/backup_and_restore.sh backup vmail
|
||||
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
#### Cronjob
|
||||
|
||||
Sie können das Backup-Skript regelmäßig über einen Cronjob laufen lassen. Stellen Sie sicher, dass `BACKUP_LOCATION` existiert:
|
||||
|
||||
```
|
||||
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).
|
||||
|
||||
Das folgende Skript kann in `/etc/cron.daily/mailcow-backup` platziert werden - vergessen Sie nicht, es mit `chmod +x` als ausfĂĽhrbar zu markieren:
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
# Backup mailcow data
|
||||
# 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="backup all"
|
||||
OPTIONS="--delete-days 30"
|
||||
|
||||
# run command
|
||||
set +e
|
||||
"${SCRIPT}" ${PARAMETERS} ${OPTIONS} 2>&1 > "$OUT"
|
||||
RESULT=$?
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
# Backup-Strategie mit rsync und mailcow Backup-Skript
|
||||
|
||||
Erstellen Sie das Zielverzeichnis fĂĽr mailcows Hilfsskript:
|
||||
```
|
||||
mkdir -p /external_share/backups/backup_script
|
||||
```
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
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!
|
||||
|
||||
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).
|
||||
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!
|
||||
97
docs/backup_restore/b_n_r-backup.en.md
Normale Datei
97
docs/backup_restore/b_n_r-backup.en.md
Normale Datei
|
|
@ -0,0 +1,97 @@
|
|||
### Backup
|
||||
|
||||
#### Manual
|
||||
|
||||
You can use the provided script `helper-scripts/backup_and_restore.sh` to backup mailcow automatically.
|
||||
|
||||
Please do not copy this script to another location.
|
||||
|
||||
To run a backup, write "backup" as first parameter and either one or more components to backup as following parameters.
|
||||
You can also use "all" as second parameter to backup all components. Append `--delete-days n` to delete backups older than n days.
|
||||
|
||||
```
|
||||
# Syntax:
|
||||
# ./helper-scripts/backup_and_restore.sh backup (vmail|crypt|redis|rspamd|postfix|mysql|all|--delete-days)
|
||||
|
||||
# Backup all, delete backups older than 3 days
|
||||
./helper-scripts/backup_and_restore.sh backup all --delete-days 3
|
||||
|
||||
# Backup vmail, crypt and mysql data, delete backups older than 30 days
|
||||
./helper-scripts/backup_and_restore.sh backup vmail crypt mysql --delete-days 30
|
||||
|
||||
# Backup vmail
|
||||
./helper-scripts/backup_and_restore.sh backup vmail
|
||||
|
||||
```
|
||||
|
||||
The script will ask you for a backup location. Inside of this location it will create folders in the format "mailcow_DATE".
|
||||
You should not rename those folders to not break the restore process.
|
||||
|
||||
To run a backup unattended, define MAILCOW_BACKUP_LOCATION as environment variable before starting the script:
|
||||
|
||||
```
|
||||
MAILCOW_BACKUP_LOCATION=/opt/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all
|
||||
```
|
||||
|
||||
#### Cronjob
|
||||
|
||||
You can run the backup script regularly via cronjob. Make sure `BACKUP_LOCATION` exists:
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
Per default cron sends the full result of each backup operation by email. If you want cron to only mail on error (non-zero exit code) you may want to use the following snippet. Pathes need to be modified according to your setup (this script is a user contribution).
|
||||
|
||||
This following script may be placed in `/etc/cron.daily/mailcow-backup` - do not forget to mark it as executable via `chmod +x`:
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
# Backup mailcow data
|
||||
# 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="backup all"
|
||||
OPTIONS="--delete-days 30"
|
||||
|
||||
# run command
|
||||
set +e
|
||||
"${SCRIPT}" ${PARAMETERS} ${OPTIONS} 2>&1 > "$OUT"
|
||||
RESULT=$?
|
||||
|
||||
if [ $RESULT -ne 0 ]
|
||||
then
|
||||
echo "${SCRIPT} ${PARAMETERS} ${OPTIONS} encounters an error:"
|
||||
echo "RESULT=$RESULT"
|
||||
echo "STDOUT / STDERR:"
|
||||
cat "$OUT"
|
||||
fi
|
||||
```
|
||||
|
||||
# Backup strategy with rsync and mailcow backup script
|
||||
|
||||
Create the destination directory for mailcows helper script:
|
||||
```
|
||||
mkdir -p /external_share/backups/backup_script
|
||||
```
|
||||
|
||||
Create cronjobs:
|
||||
```
|
||||
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
|
||||
# If you want to, use the acl util to backup permissions of some/all folders/files: getfacl -Rn /path
|
||||
```
|
||||
|
||||
On the destination (in this case `/external_share/backups`) you may want to have snapshot capabilities (ZFS, Btrfs etc.). Snapshot daily and keep for n days for a consistent backup.
|
||||
Do **not** rsync to a Samba share, you need to keep the correct permissions!
|
||||
|
||||
To restore you'd simply need to run rsync the other way round and restart Docker to re-read the volumes. Run `docker-compose pull` and `docker-compose up -d`.
|
||||
|
||||
If you are lucky Redis and MariaDB can automatically fix the inconsistent databases (if they _are_ inconsistent).
|
||||
In case of a corrupted database you'd need to use the helper script to restore the inconsistent elements. If a restore fails, try to extract the backups and copy the files back manually. Keep the file permissions!
|
||||
16
docs/backup_restore/b_n_r-backup_restore-maildir.de.md
Normale Datei
16
docs/backup_restore/b_n_r-backup_restore-maildir.de.md
Normale Datei
|
|
@ -0,0 +1,16 @@
|
|||
### Sicherung
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
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`
|
||||
|
||||
### Wiederherstellen
|
||||
```
|
||||
cd /pfad/zu/mailcow-dockerized
|
||||
docker run --rm -it -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 xvfz /backup/backup_vmail.tar.gz
|
||||
```
|
||||
16
docs/backup_restore/b_n_r-backup_restore-maildir.en.md
Normale Datei
16
docs/backup_restore/b_n_r-backup_restore-maildir.en.md
Normale Datei
|
|
@ -0,0 +1,16 @@
|
|||
### Backup
|
||||
|
||||
This line backups the vmail directory to a file backup_vmail.tar.gz in the mailcow root directory:
|
||||
```
|
||||
cd /path/to/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
|
||||
```
|
||||
|
||||
You can change the path by adjusting ${PWD} (which equals to the current directory) to any path you have write-access to.
|
||||
Set the filename `backup_vmail.tar.gz` to any custom name, but leave the path as it is. Example: `[...] tar cvfz /backup/my_own_filename_.tar.gz`
|
||||
|
||||
### Restore
|
||||
```
|
||||
cd /path/to/mailcow-dockerized
|
||||
docker run --rm -it -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 xvfz /backup/backup_vmail.tar.gz
|
||||
```
|
||||
19
docs/backup_restore/b_n_r-backup_restore-mysql.de.md
Normale Datei
19
docs/backup_restore/b_n_r-backup_restore-mysql.de.md
Normale Datei
|
|
@ -0,0 +1,19 @@
|
|||
## Sicherung
|
||||
|
||||
```
|
||||
cd /pfad/zu/mailcow-dockerized
|
||||
Quelle mailcow.conf
|
||||
DATE=$(Datum +"%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
|
||||
```
|
||||
|
||||
## Wiederherstellen
|
||||
|
||||
!!! warning
|
||||
Sie sollten den SQL-Dump ohne `docker-compose` umleiten, um Parsing-Fehler zu vermeiden.
|
||||
|
||||
```
|
||||
cd /pfad/zu/mailcow-dockerized
|
||||
Quelle mailcow.conf
|
||||
docker exec -i $(docker-compose ps -q mysql-mailcow) mysql -u${DBUSER} -p${DBPASS} ${DBNAME} < backup_file.sql
|
||||
```
|
||||
19
docs/backup_restore/b_n_r-backup_restore-mysql.en.md
Normale Datei
19
docs/backup_restore/b_n_r-backup_restore-mysql.en.md
Normale Datei
|
|
@ -0,0 +1,19 @@
|
|||
## Backup
|
||||
|
||||
```
|
||||
cd /path/to/mailcow-dockerized
|
||||
source mailcow.conf
|
||||
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
|
||||
```
|
||||
|
||||
## Restore
|
||||
|
||||
!!! warning
|
||||
You should redirect the SQL dump without `docker-compose` to prevent parsing errors.
|
||||
|
||||
```
|
||||
cd /path/to/mailcow-dockerized
|
||||
source mailcow.conf
|
||||
docker exec -i $(docker-compose ps -q mysql-mailcow) mysql -u${DBUSER} -p${DBPASS} ${DBNAME} < backup_file.sql
|
||||
```
|
||||
98
docs/backup_restore/b_n_r-coldstandby.de.md
Normale Datei
98
docs/backup_restore/b_n_r-coldstandby.de.md
Normale Datei
|
|
@ -0,0 +1,98 @@
|
|||
# Cold-standby-Backup
|
||||
|
||||
mailcow bietet eine einfache Möglichkeit, eine konsistente Kopie von sich selbst zu erstellen, die per rsync an einen entfernten Ort ohne Ausfallzeit übertragen werden kann.
|
||||
|
||||
Dies kann auch verwendet werden, um Ihre mailcow auf einen neuen Server zu ĂĽbertragen.
|
||||
|
||||
## Das sollten Sie wissen
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
`mariabackup` wird verwendet, um eine konsistente Kopie des SQL-Datenverzeichnisses zu erstellen.
|
||||
|
||||
Nach dem Rsync der Daten fĂĽhren wir `docker-compose pull` aus und entfernen alte Image-Tags aus dem Ziel.
|
||||
|
||||
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 keine Festplatten-Snapshots (z. B. über ZFS, LVM usw.) auf dem Ziel ausführen, während dieses Skript ausgeführt wird.
|
||||
|
||||
Die Versionierung ist nicht Teil dieses Skripts, wir verlassen uns auf das Ziel (Snapshots oder Backups). Sie können dafür auch jedes andere Tool verwenden.
|
||||
|
||||
## Vorbereiten
|
||||
|
||||
Sie benötigen ein SSH-fähiges Ziel und eine Schlüsseldatei, um sich mit diesem Ziel zu verbinden. Der Schlüssel sollte nicht durch ein Passwort geschützt sein, damit das Skript unbeaufsichtigt arbeiten kann.
|
||||
|
||||
In Ihrem mailcow-Basisverzeichnis, z.B. `/opt/mailcow-dockerized`, finden Sie eine Datei `create_cold_standby.sh`.
|
||||
|
||||
Bearbeiten Sie diese Datei und ändern Sie die exportierten Variablen:
|
||||
|
||||
```
|
||||
export REMOTE_SSH_KEY=/pfad/zur/keyfile
|
||||
export REMOTE_SSH_PORT=22
|
||||
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 Skript wird Fehler automatisch erkennen und sich beenden.
|
||||
|
||||
Sie können die Verbindung testen, indem Sie `ssh mailcow-backup.host.name -p22 -i /path/to/keyfile` ausführen.
|
||||
|
||||
## Backup und Aktualisierung des Cold-Standby
|
||||
|
||||
Starten Sie das erste Backup, dies kann je nach Verbindung eine Weile dauern:
|
||||
|
||||
```
|
||||
bash /opt/mailcow-dockerized/create_cold_standby.sh
|
||||
```
|
||||
|
||||
Das war einfach, nicht wahr?
|
||||
|
||||
Das Aktualisieren des Cold-Standby ist genauso einfach:
|
||||
|
||||
```
|
||||
bash /opt/mailcow-dockerized/create_cold_standby.sh
|
||||
```
|
||||
|
||||
Es ist derselbe Befehl.
|
||||
|
||||
## Automatisierte Backups mit cron
|
||||
|
||||
Stellen Sie zunächst sicher, dass der `cron` Dienst aktiviert ist und läuft:
|
||||
|
||||
```
|
||||
systemctl enable cron.service && systemctl start cron.service
|
||||
```
|
||||
|
||||
Um die Backups auf dem Cold-Standby-Server zu automatisieren, können Sie einen Cron-Job verwenden. Um die Cron-Jobs für den Root-Benutzer zu bearbeiten, führen Sie aus:
|
||||
|
||||
```
|
||||
crontab -e
|
||||
```
|
||||
|
||||
Fügen Sie die folgenden Zeilen hinzu, um den Cold-Standby-Server täglich um 03:00 Uhr zu synchronisieren. In diesem Beispiel werden Fehler der letzten Ausführung in einer Datei protokolliert.
|
||||
|
||||
```
|
||||
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:
|
||||
|
||||
```
|
||||
crontab -l
|
||||
```
|
||||
98
docs/backup_restore/b_n_r-coldstandby.en.md
Normale Datei
98
docs/backup_restore/b_n_r-coldstandby.en.md
Normale Datei
|
|
@ -0,0 +1,98 @@
|
|||
# Cold-standby backup
|
||||
|
||||
mailcow offers an easy way to create a consistent copy of itself to be rsync'ed to a remote location without downtime.
|
||||
|
||||
This may also be used to transfer your mailcow to a new server.
|
||||
|
||||
## You should know
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
The use 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.
|
||||
|
||||
After rsync'ing the data we will run `docker-compose pull` and remove old image tags from the destination.
|
||||
|
||||
Your source will not be changed at any time.
|
||||
|
||||
**You may want to make sure to use the same `/etc/docker/daemon.json` on the remote target.**
|
||||
|
||||
You should not run disk snapshots (e.g. via ZFS, LVM etc.) on the target at the very same time as this script is run.
|
||||
|
||||
Versioning is not part of this script, we rely on the destination (snapshots or backups). You may also want to use any other tool for that.
|
||||
|
||||
## 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.
|
||||
|
||||
In your mailcow base directory, e.g. `/opt/mailcow-dockerized` you will find a file `create_cold_standby.sh`.
|
||||
|
||||
Edit this file and change the exported variables:
|
||||
|
||||
```
|
||||
export REMOTE_SSH_KEY=/path/to/keyfile
|
||||
export REMOTE_SSH_PORT=22
|
||||
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 script will detect errors automatically and exit.
|
||||
|
||||
You may want to test the connection by running `ssh mailcow-backup.host.name -p22 -i /path/to/keyfile`.
|
||||
|
||||
## Backup and refresh the cold-standby
|
||||
|
||||
Run the first backup, this may take a while depending on the connection:
|
||||
|
||||
```
|
||||
bash /opt/mailcow-dockerized/create_cold_standby.sh
|
||||
```
|
||||
|
||||
That was easy, wasn't it?
|
||||
|
||||
Updating your cold-standby is just as easy:
|
||||
|
||||
```
|
||||
bash /opt/mailcow-dockerized/create_cold_standby.sh
|
||||
```
|
||||
|
||||
It's the same command.
|
||||
|
||||
## Automated backups with cron
|
||||
|
||||
First make sure that the `cron` service is enabled and running:
|
||||
|
||||
```
|
||||
systemctl enable cron.service && systemctl start cron.service
|
||||
```
|
||||
|
||||
To automate the backups to the cold-standby server you can use a cron job. To edit the cron jobs for the root user run:
|
||||
|
||||
```
|
||||
crontab -e
|
||||
```
|
||||
|
||||
Add the following lines to synchronize the cold standby server daily at 03:00. In this example errors of the last execution are logged into a file.
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
If saved correctly, the cron job should be shown by typing:
|
||||
|
||||
```
|
||||
crontab -l
|
||||
```
|
||||
13
docs/backup_restore/b_n_r-restore.de.md
Normale Datei
13
docs/backup_restore/b_n_r-restore.de.md
Normale Datei
|
|
@ -0,0 +1,13 @@
|
|||
### Wiederherstellung
|
||||
|
||||
Bitte kopieren Sie dieses Skript nicht an einen anderen Ort.
|
||||
|
||||
Um eine Wiederherstellung durchzufĂĽhren, **starten Sie mailcow**, verwenden Sie das Skript mit "restore" als ersten Parameter.
|
||||
|
||||
```
|
||||
# Syntax:
|
||||
# ./helper-scripts/backup_and_restore.sh restore
|
||||
|
||||
```
|
||||
|
||||
Das Skript wird Sie nach einem Speicherort fĂĽr die Sicherung der mailcow_DATE-Ordner fragen.
|
||||
13
docs/backup_restore/b_n_r-restore.en.md
Normale Datei
13
docs/backup_restore/b_n_r-restore.en.md
Normale Datei
|
|
@ -0,0 +1,13 @@
|
|||
### Restore
|
||||
|
||||
Please do not copy this script to another location.
|
||||
|
||||
To run a restore, **start mailcow**, use the script with "restore" as first parameter.
|
||||
|
||||
```
|
||||
# Syntax:
|
||||
# ./helper-scripts/backup_and_restore.sh restore
|
||||
|
||||
```
|
||||
|
||||
The script will ask you for a backup location containing the mailcow_DATE folders.
|
||||
|
|
@ -68,7 +68,7 @@ docker-compose up -d
|
|||
|
||||
### Hooks
|
||||
|
||||
Sie können sich in den Update-Mechanismus einklinken, indem Sie Skripte namens `pre_commit_hook.sh` und `post_commit_hook.sh` zu Ihrem mailcows-Root-Verzeichnis hinzufügen. Siehe [hier](u_e/update-hooks.md) für weitere Details.
|
||||
Sie können sich in den Update-Mechanismus einklinken, indem Sie Skripte namens `pre_commit_hook.sh` und `post_commit_hook.sh` zu Ihrem mailcows-Root-Verzeichnis hinzufügen. Siehe [hier](../u_e/update-hooks.de.md) für weitere Details.
|
||||
|
||||
## FuĂźnoten
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ docker-compose up -d
|
|||
|
||||
### Hooks
|
||||
|
||||
You can hook into the update mechanism by adding scripts called `pre_commit_hook.sh` and `post_commit_hook.sh` to your mailcows root directory. See [this](u_e/update-hooks.md) for more details.
|
||||
You can hook into the update mechanism by adding scripts called `pre_commit_hook.sh` and `post_commit_hook.sh` to your mailcows root directory. See [this](../u_e/update-hooks.en.md) for more details.
|
||||
|
||||
## Footnotes
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Dies ist eine experimentelle Funktion, die es Admins und Domänenadmins erlaubt, sich direkt als Mailbox-Benutzer direkt bei SOGo anzumelden, ohne das Passwort des Benutzers zu kennen.
|
||||
Dies ist eine experimentelle Funktion, die es Admins und Domänenadmins erlaubt, sich direkt als Mailbox-Benutzer bei SOGo anzumelden, ohne das Passwort des Benutzers zu kennen.
|
||||
Dazu wird ein zusätzlicher Link zu SOGo in der Mailbox-Liste (mailcow UI) angezeigt.
|
||||
|
||||
Auch mehrere gleichzeitige Admin-Logins auf verschiedene Postfächer sind mit dieser Funktion möglich.
|
||||
|
|
|
|||
12
mkdocs.yml
12
mkdocs.yml
|
|
@ -65,14 +65,14 @@ nav:
|
|||
- 'Reset TLS certificates': 'troubleshooting/debug-reset_tls.md'
|
||||
- 'Backup & Restore':
|
||||
- 'Component backup & restore':
|
||||
- 'Backup': 'b_n_r-backup.md'
|
||||
- 'Restore': 'b_n_r-restore.md'
|
||||
- 'Cold-standby (rolling backup)': 'b_n_r-coldstandby.md'
|
||||
- 'Backup': 'backup_restore/b_n_r-backup.md'
|
||||
- 'Restore': 'backup_restore/b_n_r-restore.md'
|
||||
- 'Cold-standby (rolling backup)': 'backup_restore/b_n_r-coldstandby.md'
|
||||
- 'Manual backups':
|
||||
- 'Maildir': 'u_e-backup_restore-maildir.md'
|
||||
- 'MySQL (mysqldump)': 'u_e-backup_restore-mysql.md'
|
||||
- 'Maildir': 'backup_restore/b_n_r-backup_restore-maildir.md'
|
||||
- 'MySQL (mysqldump)': 'backup_restore/b_n_r-backup_restore-mysql.md'
|
||||
- 'mailcow-internal backups':
|
||||
- 'Recover accidentally deleted data': 'b_n_r-accidental_deletion.md'
|
||||
- 'Recover accidentally deleted data': 'backup_restore/b_n_r-accidental_deletion.md'
|
||||
- 'Manual/Guides/Examples':
|
||||
- 'mailcow UI':
|
||||
- 'Blacklist / Whitelist': 'u_e-mailcow_ui-bl_wl.md'
|
||||
|
|
|
|||
Laden …
In neuem Issue referenzieren