Borg ist für deduplizierte, verschlüsselte, inkrementelle Backups auf SSH-Ziele optimiert und wird von Hetzner explizit unterstützt. Vorteile: starke Deduplizierung, integrierte Verschlüsselung (AES-256/ChaCha20-Poly1305), einfache Retention und Mountbarkeit als FUSE-FS zum Restore einzelner Dateien.

apt install borgbackup

SSH Key für die Storage Box generieren (ohne Passwort!).

ssh-keygen -t ed25519 -C "borg@rootserver" -f ~/.ssh/hetzner_storage

Den Key kann man beim Erstellen der Storage Box hinzufügen oder wenn schon die Box eingerichtet ist, nachträglich hinzufügen.

ssh-copy-id -p23 -i ~/.ssh/hetzner_storage.pub uXXXXX@uXXXXX.your-storagebox.de

Borg Repo initialisieren (REPO_NAME ersetzen, bei mir z.B. nextcloud-docker, für mein Nextcloud Backup).

borg init --encryption=repokey --remote-path=borg1.4 ssh://uXXXXX@uXXXXX.your-storagebox.de:23/./REPO_NAME -i ~/.ssh/hetzner_storage

Meine Nextcloud läuft in Docker und die Daten sind nur per Mount eingebunden. Die Container selbst möchte ich nicht sichern, nur die Daten und die Datenbank. Dazu habe ich mir ein Script erstellt, was mir die DB per Docker und mysqldump dumped und die Daten sichert. Mein Backup soll verschlüsselt in der Storage Box liegen, dazu habe ich den Schlüssel in der Datei /root/.borg-passphrase abgelegt.

#!/bin/bash
set -euo pipefail

# === KONFIG ===
export BORG_RSH='ssh -i /root/.ssh/hetzner_borg -p 23 -o StrictHostKeyChecking=no'
export BORG_PASSPHRASE=$(cat /root/.borg-passphrase)
export BORG_REMOTE_PATH="borg-1.4"
NEXTCLOUD_CLI="nextcloud_cli" 
NC_DATA="/mnt/docker/data/nextcloud/data"
NC_RELEASES="/mnt/docker/data/nextcloud/releases"
NC_OCC_PATH_IN_DOCKER="/var/www/nextcloud/releases/current/occ"
DB_CONTAINER="nextcloud_db"
DB_NAME="nextcloud"
DB_USER="root"
BORG_REPO="ssh://uXXXXX@uXXXXX.your-storagebox.de:23/./nextcloud-docker"
TMP_BACKUP="/tmp/nextcloud-$(date +%Y%m%d-%H%M%S)"
LOCK_FILE="/var/run/borg-nextcloud.lock"
LOG_FILE="/var/log/borg-nextcloud.log"

[ -f "$LOCK_FILE" ] && { echo "Backup läuft!" >&2; exit 1; }
echo $$ > "$LOCK_FILE"
trap 'rm -f "$LOCK_FILE" && docker exec $NEXTCLOUD_CLI php $NC_OCC_PATH_IN_DOCKER maintenance:mode --off || true; rm -rf "$TMP_BACKUP"' EXIT INT TERM

exec > >(tee -a "$LOG_FILE") 2>&1
echo "=== Nextcloud Backup start: $(date) ==="

# 1. Maintenance ON
docker exec $NEXTCLOUD_CLI php $NC_OCC_PATH_IN_DOCKER maintenance:mode --on

# 2. DB Dump (mit Passwort!)
mkdir -p "$TMP_BACKUP/sql"
DB_PASS=$(docker exec $DB_CONTAINER printenv MYSQL_ROOT_PASSWORD)
docker exec $DB_CONTAINER mysqldump --single-transaction --routines --triggers \
  --user="$DB_USER" --password="$DB_PASS" "$DB_NAME" | gzip > "$TMP_BACKUP/sql/db.sql.gz"

# 3. Config backup
docker exec $NEXTCLOUD_CLI php $NC_OCC_PATH_IN_DOCKER config:list --output=json > "$TMP_BACKUP/config.json"

# 4. Borg Create
borg create "$BORG_REPO"::nextcloud-{now:%Y-%m-%d-%H:%M} \
  "$TMP_BACKUP/" \
  "$NC_DATA" \
  "$NC_RELEASES" \
  --exclude "*/cache/*" \
  --exclude "*/tmp/*" \
  --exclude "*/updater-*" \
  --exclude "*/appdata_*/*cache*" \
  --compression lz4 --stats --progress

# 5. Prune
borg prune "$BORG_REPO" --stats \
  --keep-within=1w \
  --keep-weekly=4 \
  --keep-monthly=6 \
  --keep-yearly=2

echo "✅ Backup fertig: $(date)"

Meine Backups sollen jede Nacht um 3 Uhr laufen. Dazu habe ich mir einen Service und Timer angelegt.

Service: /etc/systemd/system/borg-nextcloud.service

[Unit]
Description=Nextcloud Borg Backup
After=network-online.target

[Service]
Type=oneshot
User=root
ExecStart=/root/nextcloud_backup.sh

Timer: /etc/systemd/system/borg-nextcloud.timer

[Unit]
Description=Täglich Nextcloud Backup
Requires=borg-nextcloud.service

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

Service und Timer aktivieren

systemctl daemon-reload
systemctl enable --now borg-nextcloud.timer
systemctl status borg-nextcloud.timer

Kleiner Test ob alles funktioniert (Achtung, je nach Menge an Daten kann dies ein paar Stunden dauern)

systemctl start borg-nextcloud.service

Dazu verwende ich bei mir in der opnSense die zusätzlichen Plugins os-acme-client und os-haproxy, die unter System -> Firmware -> Plugins installiert werden müssen. Des Weiteren wird noch ein Domainanbieter mit API Zugriff benötigt. In meinem Fall nutze ich eine Domain von netcup und deren API. Meine Intranet URL Struktur wird später wie folgt aussehen *.intern.domain.tld.

Domain API Passwort und Key erstellen

Wie zuvor erwähnt bin ich bei netcup mit meinen Domains, hier einfach unter Stammdaten -> >_ API (oben rechts) oder direkt per Link https://www.customercontrolpanel.de/daten_aendern.php?sprung=api auf API-Passwort generieren klicken und Passwort wegspeichern. Das wird nur 1x angezeigt! Auf der rechten Seite dann Nutzungsbedingungen lesen / verstehen und über die Checkbox akzeptieren und API-Key erstellen anklicken.

ACME Client konfigurieren

Unter Services -> ACME Client -> Settings

Mit Apply bestätigen

Unter Services -> ACME Client -> Accounts

Hier kannst du für den Anfang und zum Testen die Test CA nutzen, musst du aber nicht. Wird später eh umgestellt. Die E-Mail Adresse sollte eine valide sein, da du von LE per Mails benachrichtigt wirst. Mit Save speichern

Den Account registrieren lassen. Dazu auf der rechten Seite beim Eintrag auf Register account klicken.

Unter Services -> ACME Client -> Challenge Types die API Daten von deinem Domain Anbieter eintragen. In meinem Fall immer noch netcup und mit Save bestätigen

Unter Services -> ACME Client -> Certificates muss nun das wildcard Zertifikat angelegt werden.


Der Last ACME Status sollte dann auf OK stehen.

Die opnSense mit dem Zertifikat absichern

Unter System -> Settings -> General muss auch die Domain eingetragen werden.

Unter System -> Settings -> Administration das Zertifikat auswählen, Domain hinterlegen und den Port ändern. Der Port kann frei gewählt werden, muss aber >= 1024 sein. Alles bis 1023 sind reservierte Systemports bzw. Portnummern bekannter Netzwerkdienste.

Nach dem Speichern sollte die opnSense unter der alten IP https://IP:55443 und der URL https://opnsense.intern.DOMAIN.tld:55443 erreichbar sein.

Unbound DNS Overrides

Falls der Unbound DNS noch nicht verwendet wird, muss dieser aktiviert und konfiguriert werden. Unter Services -> Unbound DNS -> General

Unter System -> Settings -> Gerneral habe ich sämtliche IPs meiner opnSense eingetragen.

Unter Services -> Unbound DNS -> Overrides müssen wir nun für jeden Service den wir über eine Subdomain erreichen wollen, einen Override anlegen. Die IP Adresse muss auf eine IP oder opnSense zeigen (wichtig). Theoretisch ginge auch der Weg über eine virtuelle IP, der Einfachheithalber habe ich diesen Schritt weggelassen. Kann aber auch später nachgezogen oder direkt erledigt werden.

Nach Änderungen an den Unbound DNS Einstellungen muss der Dienst immer neugestartet werden.

HAProxy konfigurieren

Für jeden Service, den wir unter einer Subdomain erreichen wollen, müssen wir einen echten Server unter Services -> HAProxy -> Settings -> Real Servers -> Real Servers anlegen.

Wichtig ist hier die IP (FQDN or IP), der Port und ob der Service selbst schon SSL (egal, ob es ein self signed cert ist) verwendet, unter der der Service erreichbar ist. Unser Browser geht mit der Subdomain über den HAProxy und hier wird das Let’s Encrypt Zertifikat ausgespielt. Der HAProxy selbst leitet den Traffic dann intern zu unserem Service weiter. Hier wird dann wenn SSL aktiviert das selbst signierte Zertifikat oder eben kein Zertifikat verwendet.

Unter Services -> HAProxy -> Settings -> Virtual Services -> Backend Pools wird zu jedem Backend Server ein Backend Pool angelegt. Ausnahme: Ein Backend Pool kann jedoch mehrere Backend Server enthalten. Wird aber nur beim Load Balancing benötigt.

Unter Services -> HAProxy -> Settings -> Advanced -> Map File müssen wir doch eine Subdomain auf Backend Pool Mapping erstellen. Das Mapping nutzen wir, um nicht für jeden Backend Pool einen Public Service anlegen zu müssen.

Das Mapping ist einfach und setzt sich immer wie folgt zusammen
subdomain oder komplette domain Backend Pool
homeassistant HomeAssistant_Backend
oder
homeassistant.intern.domain.tld HomeAssistant_Backend

Unter Services -> HAProxy -> Settings -> Rules & Checks -> Conditions müssen eine Condition anlegen, um http zu https redirecten zu können.

Unter Services -> HAProxy -> Settings -> Rules & Checks -> Rules müssen wir zwei Regeln anlegen. Eine um den HTTP Traffic nach HTTPS redirecten und eine um das Domain zu Backend Pool mapping durchführen zu können.

Wir nähern uns dem Ende und müssen nur noch zwei Frontends anlegen. Eins für HTTP und eins für HTTPS. Dies erledigen wir unter Services -> HAProxy -> Settings -> Virtual Services -> Public Services.

Zu guter letzt noch Test syntax und wenn keine Fehler gefunden wurden auf Apply klicken und deine Services sollten in deinem lokalen Netzwerk nun über die Subdomains erreichbar sein.

P.S.: Solltest du bei einem Service wie z.B. HomeAssistant HTTP Fehler bekommen, dann kann es daran liegen, dass du im Service den Trusted Proxy in der Config setzen musst. Bei HomeAssistant kommt, wenn man es nicht konfiguriert, ein 400 Bad Gateway Fehler.

HomeAssistant Bsp.

In der configuration.yml müssen use_x_forwarded_for und trusted_proxies eingetragen werden

http:
  ssl_certificate: ssl/fullchain.pem
  ssl_key: ssl/privkey.pem
  use_x_forwarded_for: true
  trusted_proxies:
    - 192.168.178.1
    - 127.0.0.1
    - ::1

Eigentlich wollte ich auch nichts übers Flashen von openWrt auf den EAP613 schreiben, jedoch hatte ich so meine Herausforderungen dabei und konnte nicht wirklich etwas dazu im Netz finden.

Für den Flash der openWrt Firmware waren diese drei Quellen von Relevanz für mich
openWrt Factory Install
openWrt Firmware for EAP613 v1
openWrt install instructions EAP613 v1

Ok, den ersten Link hatte ich erst hinterher gefunden, als ich mich auf Fehlersuche begeben hatte. Dort wird erklärt, wie die FW zu flashen und was zu beachten ist. Ich bin der Anleitung aus dem 3. Link gefolgt. Im ersten Link steht noch zusätzlich, dass die Prüfsumme der Firmware vorm Flashen geprüft werden sollte, dies hatte ich nicht gemacht, hat bei mir aber keine Probleme verursacht, da die Datei OK war, die ich geflasht hatte.

openWrt auf den TP Link EAP613 rev. 1 flashen

Disclaimer:
Ich übernehme keinerlei Haftung für evt. Schäden die auftreten können. Wenn du dir unsicher bis, lies dir noch mal die Infos auf den openWrt Seiten etc. durch und wäge ab, ob du deinen AP wirklich auf openWrt umstellen magst. Sollte beim installieren von openWrt etwas schief laufen, ist es ein hoher Aufwand den Ursprungszustand wiederherzustellen

1. Beim 2. Link von oben die Firmware laden (Firmware OpenWrt Install URL – Nicht den Snapshot und auch nicht das Update! )
2. Die Datei openwrt-23.05.3-ramips-mt7621-tplink_eap613-v1-squashfs-factory.bin ggf. validieren (Prüfsumme) und in factory.bin umbenennen.
3. EAP613 mit dem PoE Switch oder Netzteil und Router / PC verbinden und starten lassen.
4. Per Browser auf die AP IP connecten und sich mit admin:admin einloggen
5. Dort in den AP Einstellungen SSH aktivieren und speichern.
6. Per SSH auf den AP connecten (User, IP und ggf. Port anpassen)
   ssh -p 22 -oHostKeyAlgorithms=+ssh-dss admin@192.168.178.145
7. In der SSH Console dann den Befehl cliclientd stopcs eingeben. Dies wird mit Success bestätigt.
   
8. Zurück im Browser in der Weboberfäche unter Firmware Update die factory.bin auswählen und auf update klick. Das Update dauert ein paar Minuten. In der Zeit das Gerät nicht vom Strom trennen und das Browserfenster offen lassen.

Fehler / Probleme

Ich hatte bei mir die Herausforderung, dass der AP mit openWrt nicht mehr erreichbar war. Er war zwar sichtbar im Router und Switch, hatte aber keine IP. Dachte erst ich hätte ihn gebrickt, lag aber daran, dass dort die IP Configuration auf DHCP Server stand. Ich habe dann den PoE Switch, EAP613 und einen PC zusammen laufen lassen. Der EAP613 fungierte dann als DHCP Server / Router und hat die IPs verteilt. Selbst war der AP dann unter 192.168.1.1 erreichbar und ich konnte mich mit dem Benutzer root und ohne Password einloggen. Dort habe ich dann beim aktiven Interface auf DHCP client umgestellt und gespeichert. Danach konnte ich das Switch wieder ins Netzwerk hängen und der AP hat eine IP zugewiesen bekommen.

Disclaimer
ich habe den Beitrag nach besten Wissen und Gewissen verfasst und übernehme keine Verantwortung für evtl. Schäden oder Verluste von E-Mails etc. Die Verwendung der hier bereitgestellten Informationen beruht auf eigene Gefahr!

Muss oder möchte man seine E-Mail Postfächer von einem auf einen anderen Server umziehen und die alten Mails übernehmen, so kann dies einfach per imapsync erledigt werden.

Ich persönlich habe irgendwann aufgegeben, einen eigenen Mailserver zu betreiben und habe mir hierfür den Service gemietet, damit ich muss um nichts kümmern muss. Jetzt war ich nur leider dazu gezwungen, meine Postfächer von einem auf einen anderen zu migrieren. Prinzipiell gesehen lässt sich das auch per Mail Client erledigen, dauert aber verdammt lange und ich habe auch nicht jedes verwendete Postfach selbst in Verwendung. Hier bietet es sich auch direkt an, imapsync auf einem Server im Rechenzetrum oder dem Home Server auszulagern. Eine Installation lokal auf dem eigenen PC/Notebook ist aber auch kein Problem. Dafür habe ich mir ein Dockerfile und docker-compose.yml file erstellt. Beides kann hier abgerufen werden.

Der Weg über imapsync in Docker setzt Docker und docker compose voraus. Beides gibts für Win, Mac sowie auch Linux. Auf eine Installation für Docker gehe ich hier nicht weiter ein, da es hierzu schon zahlreiche Anleitungen gibt und auch von Docker (Docker installieren) selbst.

imapsync installieren / einrichten

Wenn Docker installiert und gestartet ist, werden die beiden Dateien von hier benötigt. Einfach irgendwo zusammen in einem Ordner ablegen und den Pfad schon mal im CMD / Terminal öffnen.

Mit dem Befehl

wird ein Image des benötigten Debian Grundsystems geladen, die benötigten Pakete für imapsync, zsh etc. installiert.

Nachdem build Prozess sollte der Docker Container im Hintergrund gestartet sein. Dies kann mit folgendem Befehl geprüft werden.

Der Status wichtig, hier sollte irgendwas von ‚Up X seconds‚ oder ‚Up x minutes‚ etc. stehen. Wenn hier ‚Exited (x) x seconds ago‚ steht, ist ein Fehler passiert und der Container konnte nicht gestartet werden. Hier hilft ein ‚docker logs imapsync‚ Befehl um die Logs des Containers angezeigt zu bekommen.

Wenn der Container gestartet ist, kann sich per Terminal verbunden werden bzw. wir können auf den Docker Container springen.

Anstelle von zsh kann auch bash oder sh als shell verwendet werden. Ich persönlich präferiere hier die Z shell.

Nun kann getestet werden, ob imapsync richtig installiert wurde.

Postfächer vorbereiten

Ich habe (händisch) auf dem neuen Mailserver jedes Postfach welches ich synchronieren werde, neu angelegt. Hier habe ich überall das selbe einfach Passwort wie z.B. ‚target123′ festgelegt. Auf dem alten Mailserver habe ich von jedem Postfach das Passwort auf z.B. ’source123‘ geändert, um den sync Vorgang etwas einfacher zu gestalten.

Auch ist es sinnvoll, gelösche Elemente so wie SPAMs schon vom alten Server komplett zu löschen, da es sonst sehr lange dauern kann die alle zu übernehmen.

Nachdem diese Vorbereitungen abgeschlossen sind, kann gesynct werden.

Sync Vorgang starten

Ich habe alle Mails mit dem oben angegebenen Befehl synchronisieren lassen. Eine genaue Übersicht aller Befehle kann in der imapsync Dokumentation oder man page nachgeschaut werden.

Folgende Platzhalter müssen angepasst werden:

MAILSERVER1 -> IP oder Adresse vom alten Mailserver
MAILSERVER2 -> IP oder Adresse vom neuen Mailserver
PASSWORTSOURCE -> Login PW z.B. source123
PASSWORTTARGET -> Login PW z.B. target123
LOGINSOURCE -> Benutzername oder E-Mail für Login
LOGINTARGET -> Benutzername oder E-Mail für Login

Es ist auch noch wichtig zu erwähnen, dass der Parameter –delete1, alle erfolgreich synchronisierte Nachrichten von host1/MAILSERVER1 unwiderruflich löscht! Also aufpassen!

Der Befehl kann kann per STRG + C abgebrochen werden und später einfach wieder neugestartet werden. Auch kann der Befehl nach Erfolg alle paar Stunden wieder ausgeführt werden, um die restlichen noch eintreffenden Mails zu syncen. Ich hab den Sync 24h nach Erfolg das letze Mal noch gestartet (DNS Cache), um wirklich noch die letzten Mails zu syncen.

Der Sync dauert unterschiedlich lange, so wurden bei mir teilweise 60 Mails die Sekunde kopiert, aber auch bei sehr großen Postfächern mit 12 GB mit 60 Mails/s gestartet und dann zwischendurch runter auf 0,5 Mails/s gefallen. Ein mehrfacher Neustart brachte auch keinen Erfolg. So haben teilweise ein paar Postfächer mehrere Tage gebraucht um kopiert zu werden.

DNS Einstellungen aktualisieren (nur, wenn E-Mail Adressen gleich bleiben)

Wenn mindestens die Domain gleich bleibt, z.B. test@julsen.de sync zu test@julsen.de (julsen.de bleibt gleich), muss noch der DNS Eintrag angepasst werden. Dies ist meist in der Verwaltungsoberfläche bei dem Anbieter, wo auch die Domain gehostet wird. Es kann bis zu 24 Stunden dauern, bis überall die neuen Einträge angekommen sind und nicht mehr die alten aus dem DNS Cache gezogen werden.

Hier kann sicherlich auch mit der MX Priorisierung gearbeitet werden und nach Sync einfach der alte Mailserver dann gekillt werden, geht aber nur wenn man auch Zugriff auf den alten Server hat.

Passwörter setzen

Wichtig ist am Ende noch alle Passwörter wieder auf sichere Passwörter zu ändern!