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!

Für die Lösung des Problems gibt es zahlreiche Ergebnisse und Herangehensweisen und auch Qnap hat einige Anleitung diesbezüglich veröffentlich. Ich habe nach und nach die ein oder andere Methode versucht. Erfolgreich war ich jedoch nur mit einer: https://www.qnap.com/de-de/how-to/faq/article/firmware-recovery-guide-for-x86-based-nas

Eine weitere hilfreiche Übersicht ist diese hier: https://www.qnap.com/de-de/how-to/faq/article/nas-firmware-recovery-guide

Dort einfach schauen welches NAS man hat und den Schritten folgen.

Ich hatte zuvor noch ein Backup meiner Konfiguration im Admin Panel exportiert, dies war allerdings nicht nötig, da alle Infos auf meinen HDDs gespeichert sind und diese wieder geladen werden, wenn die HDDs wieder eingesetzt und neugestartet wird.

Weitere Informationen / Wissenswertes

Wenn das NAS ohne Platten gestartet wird, wird der Default Admin Account verwendet. Die Benutzerdaten sind
Name: admin
Passwort: ist die MAC1 vom NAS. Diese befindet sich als Aufkleber unter dem NAS

Im BIOS muss man nicht unbedingt etwas anpassen, da man auch das Boot Menü mit F7 oder F11 öffnen kann. Bei mir war es F7, in einigen Anleitungen wird von F11 geschrieben.

Nachdem der DOM neu geschrieben wurde, muss ein Update der Firmware über den Qfinder Pro gemacht werden (Login über Default admin mit MAC1 als PW). Nachdem die Festplatten dann wieder eingebaut sind, muss neugestartet werden, so dass wieder mit den ursprünglichen Einstellungen gestartet wird. Danach muss erneut ein manuelles Update über den Qfinder Pro durchgeführt werden. Dazu muss die Firmware manuell heruntergeladen und über die App installiert werden. Nach einem erneuten Neustart sollte wieder alles wie gewohnt funktionieren. In Qfinder gibt es am NAS selber noch die Spalte ‚Status‘ hier sollten die Einträge geprüft werden. Mit Hover über die Icons erhält man weitere Informationen. So lange dort steht, dass man ein erneutes Firmware Update machen soll, sollte dies auch getan werden, da sonst nicht alle Programme aktualisiert und installiert werden können. Bei mir hat es 2 weitere Firmware Updates benötigt, damit ich wieder alle Programme updaten konnte.

Glücklicherweise lassen sich die Switches jedoch problemlos beschaffen und auch andere kompatible, die besser sind und mehr Klicks aushalten, sind verfügbar. Ich habe mich auch hier für zwei Kailh GM 8.0 entschieden. Fündig wurde ich auf eBay und es hat mich Fünf Euro für zwei Switches gekostet.

Die Demontage der G502 hat sich leider um einiges aufwendiger gestaltet, als wie es bei den beiden Mäusen zuvor der Fall war. Gestartet bin ich mit der Anleitung von iFixIt (Logitech G502 Lightspeed öffnen) mit der leider nur das Öffnen der Maus beschrieben wird. Um die Pads unterhalb der Maus zu entfernen, habe ich diese zuvor ein paar Minuten auf das Heizbett meines 3D Druckers bei 80 Grad gestellt.

Wie die Maus jedoch demontiert wird, so dass die Switches getauscht werden können, habe ich einem Video auf Youtube (Logitech G502 Lightspeed Switch Replacement) entnommen. Es empfiehlt sich das Video vorab ein mal komplett anzuschauen, um zu sehen, was das so auf einen zukommt. Für ungeduldige sei zu erwähnen, dass bei der Demontage des Mausrads darauf zu achten ist, dass einem die Sprungfedern nicht verloren gehen. Darauf wird im Video erst eingegangen, nachdem das Mausrad demontiert wurde und wenn man vorher pausiert, bekommt man es ggf. zu spät mit.

Bei der Demontage werden sehr viele kleine Schraube herausgedreht und beiseite gelegt. Hier empfiehlt es sich auch, diese nach Schritten zu sortieren, damit diese später auch wieder an Ort und Stelle kommen und man nicht durcheinander kommt. Mir hat es auch geholfen, Fotos von einzelnen Schritten anzufertigen.

Beim Zerlegen der Maus macht diese jedenfalls einen echt wertigen Eindruck. Nahezu alle Teile sind verschraubt, gesteckt oder anders befestigt, so dass fast alles getauscht werden könnte. Klar, der Aufwand ist recht hoch, um an die Switches zu kommen, aber möglich. Warum zum Teufel werden Switches mit geringer Lebenserwartung verbaut? Die jetzt verbauten Kailh Switches sollen 80 Millionen Klicks aushalten. Hoffe das ich noch ein paar Jahre Freude an der Maus haben werde, zumal diese nur ein bis zwei Mal die Woche genutzt wird.

Die Demontage wird auf iFixIt (Corsair Vengeance M65 Mouse Wheel Button Replacement) sehr gut erklärt und lässt sich leicht umsetzen. Für die Demontage wird ein Torx (T6) benötigt, welchen ich leider nicht hatte. Ich habe mir diesbezüglich ein günstiges Set (38Pcs Feinmechaniker Schraubendreher Set) auf Amazon bestellt. Sicherlich nicht das beste Set, war aber ausreichend und macht einen soliden Eindruck.

Verwendetes Werkzeug

• Lötkolben
• kleinen Kreuz-Schraubendreher
• kleinen Schlitz-Schraubendreher (zum Aufhebeln)
• Torx T6
• Lötzinn
• Entlötlitze/Entlötpumpe
• 2x Kailh GM 8.0

Beim Zerlegen und tauschen der Switches bin ich nach der Anleitung von iFixIt vorgegangen: Logitech Anywhere Mouse MX Micro Switch Replacement

Die neuen Switches habe ich bei Amazon bestellt: 2x TS20100F070S Mikroschalter

Werkzeug / Materialien

• Lötkolben
• kleinen Kreuz-Schraubendreher
• Lötzinn
• Entlötlitze/Entlötpumpe
• neue Switches

Der Tausch ist nicht sonderlich schwierig/aufwendig. Man sollte sich nur die Zeit und Ruhe nehmen, die alten Switches ordentlich runter zu bekommen, da die Pads am PCB leicht abreißen können und die Maus so irreparabel wird.

Mein Grill ist inzwischen gut 6-7 Jahre alt und hat gute Dienste verrichtet, hat in der Zeit aber auch einiges gelitten. Die Roste haben einiges an Rost eingefangen, angefangen abzublättern und der Rost hat sich durch die schöne Patina gefressen.

Dieses Jahr musste ich ein wenig rabiater gegen den Rost vorgehen und habe erst mal alle lockeren Stellen gründlich mit einem Spachtel abgekratzt. Danach bin ich grob mit ein wenig Stahlwolle über den Rost gegangen und habe im Anschluss eine Paste bestehend aus Backpulver und Essigessenz hergestellt und aufgetragen. Der Paste habe ich ca. 1 Stunde Zeit zum Einwirken gegeben. Nach der Einwirkungszeit habe ich die Paste wieder gründlich abgewaschen und die Roste für ca. 3 Stunden bei 60 Grad Celsius im Backofen getrocknet.

Die Grillwanne reinige ich jedes Jahr mit einer alten EC oder anderen Plastikkarte, dass klappt ganz gut. Einfach vorsichtig den ganzen Schmand runterschieben und in die Fett Auffangschale schieben, die kann später dann einfach geleert werden.

Nach der Trockenzeit habe ich die Roste wieder gründlich mit Sonnenblumenöl eingerieben und auf dem Grill bei voller Temperatur eingebrannt. Diesen Vorgang habe ich 3 Mal wiederholt, so lange, bis die Roste wieder rundum schön mit einer Patina überdeckt sind.

Zubereitung

1. Die Vanillestange längst halbieren und mit den Kaffee- oder Espressobohnen in ein 750 ml Einmachglas füllen und mit 1/2 Liter Wodka auffüllen.
2. Den Ansatz für gut 8 Wochen an einem dunklen Ort ziehen lassen und gelegentlich schütteln.
3. Nach den 8 Wochen 200 ml Wasser in einem Kochtopf erhitzen und den Kandiszucker darin auflösen. Beiseite stellen und erkalten lassen.
4. Den Ansatz durch ein feines Sieb oder Tuch abseihen.
5. Abgeseihten Ansatz und kaltes Kandiszuckerwasser vereinen.