{#TE33E} Neue Hardware für den Teslalogger
Anzeige … Weil es das Gesetz so verlangt (was ist das?)
Der folgende Beitrag ist ein reiner Anleitungs-Artikel ohne Verbindung zu den im Beitrag genannten Marken. Aber die affige Gesetzgebung Deutschlands … ach egal.
Es werden im gesamten Artikel KEINE Affiliate-Links verwendet, es gibt auch kein Sponsoring oder ähnliches.
Mein Tesla Model 3 ist nun bald 5 Jahre alt, eine Vielzahl seiner Daten wurde mit dem Teslalogger mal mehr, mal weniger zuverlässig mitgeschrieben. Der dafür verwendete Raspberry Pi 3B ist nun doch schon in die Jahre gekommen, und so musste irgendwann geschehen, was nun vorgefallen ist: Die SD-Karte hielt den zahlreichen Schreib- und Lesevorgängen wohl nicht mehr stand und verabschiedete sich.
Einigermaßen regelmäßigen Sicherungen der Daten zum Dank war der Datenverlust nicht ganz so groß, schnell wurde ein Raspberry Pi 4 (2 GB) zum neuen Teslalogger erkoren. Aber da ich noch einen Raspberry Pi 5 8GB aus einem KI-Experiment herumliegen habe, wurde schnell ein neuer Plan geschmiedet, um das ganze Projekt auf ein neues Level zu setzen.
Hier in diesem Artikel wird es rein nur um die verwendete Hardware und den Umzug der Daten gehen. Die Installation des Teslaloggers NET8 und das Upgrade eines alten Systems auf NET8 habe ich ja bereits an anderer Stelle beschrieben.
Viel Spaß beim Lesen des Beitrages!
Was findest du in diesem Artikel?
- Was ist das Ziel dieses Beitrages?
- Disclaimer
- Welche Soft- und Hardware habe ich für diesen Beitrag genutzt?
- Zusammenbau der Hardware
- Sicherung der Daten des alten Teslaloggers
- Feste IP-Adresse für den RasPi vergeben
- Das Grundsystem wird auf der SSD installiert
- Via SSH mit dem Raspberry Pi verbinden und ein paar Einstellungen
- Grundeinstellung des RasPi
- Teslalogger installieren
- Einspielen der gesicherten Daten
- Einrichtung von Backups auf dem NAS
- Datensicherung automatisieren
- Sahnehäubchen Cloud-Sync
- Zusammenfassend betrachtet: Was kann der RasPi jetzt?
- Letzte Worte
Was ist das Ziel dieses Beitrages?
Wie bereits beschrieben: Der Raspberry Pi 3B hat seine Arbeit meistens gut erledigt, aber auch ich habe so manche Datenverluste zu beklagen. Die ersten 1,5 Jahre der Aufzeichnungen fehlen, dank einer katastrophalen Backup-Strategie meinerseits, vollständig, und auch auf Reisen hat der RasPi schon versagt. Am meisten schmerzt mich der Verlust unserer Reise im vergangenen Sommer zum Europa-Finale der WRO. Die Reiseroute München → Ostsee → Ljubljana, Slowenien, konnte sich echt sehen lassen. Aber eben halt leider nicht.
Daher stand fest: Ich wollte zwei der größten natürlichen Feinde des Teslaloggers, der WLAN‑Verbindung und der SD-Karte, an den Kragen gehen.
Besonders Letztere ist ein wirkliches Problem. SD-Karten sind nun mal nicht für die ständigen Schreib- und Lesevorgänge der verwendeten MariaDB-Datenbank gemacht. Auch wenn es mittlerweile spezielle SD-Karten für diesen Dauereinsatz gibt. Zum Schluss hatte ich im RasPi 3B eine solche im Einsatz (WD Purple), aber auch diese riss letztlich irgendwann die Hufe hoch.
Somit war nun klar: Jetzt muss alles einfach anders, nerdiger und besser werden.
Geplant war nun ein völlig überdimensionierter RasPi 5 mit 8GB RAM aus einem KI-Experiment (der später ganz bestimmt auch noch andere Aufgaben im Smarthome übernehmen kann), eine 256-GB-NVMe M.2 SSD und ein Alu-Gehäuse mit aktivem Lüfter und einem integrierten M.2-Port. Interessant war hier ganz besonders der neue PCI-Express-Anschluss des RasPi 5, der es ermöglichte, direkt von der SSD zu starten und deshalb (eigentlich, aber dazu später mehr) überhaupt keine SD-Karte mehr benötigen würde … sofern man ein externes M.2-Gehäuse besitzt, damit die SSD auch geflasht werden kann.
Ferner wird der RasPi direkt mit dem LAN verbunden, sodass der mögliche Flaschenhals WLAN ebenfalls entfallen würde. Die Speicherdaten sollten in regelmäßigen Abständen automatisch auf unserem Synology-NAS gespeichert werden, um einem möglichen Datenverlust durch Tod der SSD zuvorzukommen. Ja, ich weiß, ein lokales Backup ist kein Backup, daher sollten die Daten wenigstens noch in eine Cloud gesynct werden. Mehr Aufwand wäre mir das Ganze aber dann doch nicht mehr wert 😉
Disclaimer!
Dieser Beitrag dient der Unterhaltung und als Ideengeber für eigene Bastelprojekte.
Solltest du nun auf den Geschmack gekommen sein, deinem Teslalogger ebenfalls ein Hardware-Upgrade zu gönnen, dann viel Erfolg und Spaß!
Wenn du diesem Blog-Beitrag folgst, dann nur im Vollbesitz deiner geistigen Kräfte, aus freien Stücken und auf eigenes Risiko.
Ich übernehme keinerlei Haftung für Schäden an Hardware, Software oder deinen gesammelten Teslalogger-Daten!
Welche Soft- und Hardware habe ich für diesen Beitrag genutzt?
Raspberry Pi 5 mit 8GB RAM
Ediloca EN600 PRO 256 GB NVMe M.2 SSD 2280
Argon Neo 5 M.2 NVMe PCIe-Gehäuse für Raspberry Pi 5
Raspberry Pi OS (64-Bit-Version, Desktop-Version für zukünftige Ideen)
Cyberduck (oder beliebige andere SFTP-Software, wie Filezilla o. Ä., zur Sicherung der Daten)
TigerVNC (um auf den Desktop des RasPi zugreifen zu können)
Tabby/iTerm2 als Terminal
pCloud für die in die Cloud gsyncten Daten
Als OS für die Screenshots und zum Flashen der SSD verwende ich wahlweise macOS oder Linux Mint, das kann unter Windows alles ein wenig anders aussehen.
Überdies besitzen wir in unserem Haushalt eine Fritz!Box 5590 Fiber und auch hier wird es möglicherweise Unterschiede in der Darstellung geben.
Zusammenbau der neuen Hardware
Der Zusammenbau der Hardwareteile war wenig spektakulär.
Das Gehäuse Neo 5 von Argon ist ausgezeichnet verarbeitet, hat aber auch seine Nachteile. Es gibt keinen Schlitz für die SD-Karte, man muss das Gehäuse noch einmal zerlegen, wenn man an diese Karte heranmöchte. Somit musste ich die SD-Karte erst einsetzen, dann wieder entnehmen. Pro-Tipp: SD-Karte einfach drinlassen und das Gehäuse zuschrauben. Das hat den Vorteil, dass man die SSD über den Raspberry Pi-Desktop auf die SD-Karte kopieren kann und damit eine Sicherung des Betriebssystems hat. Dieses lässt sich dann im Notfall wieder auf die SSD kopieren.
Finde ich das gut? Ja. Habe ich das gemacht? Natürlich nicht, hole ich aber noch nach 🙂
Was sich noch als nicht so klug herausgestellt hat: Wenn man nicht aufpasst, wie herum das Flachbandkabel für die SSD im Gehäuse eingebaut werden muss.
Sicherung der Daten des alten Teslaloggers
Die Sicherung der Daten ist relativ einfach. Dafür verwendet man die Funktion Datensicherung , die sich im Extras-Menü der Teslalogger-Seite versteckt. Der Teslalogger legt zwar jeden Tag selbstständig eine Sicherung an, aber um wirklich auf dem aktuellsten Stand zu sein, sollte man Gebrauch von dieser Funktion machen. Wem es egal ist, der kann sich natürlich auch einfach das letzte automatische Backup auf die Festplatte ziehen. Der Sicherungsvorgang kann eine Zeit dauern, also heißt es hier Geduld mitbringen und auf die Erfolgsmeldung, die aus einer völlig weißen Seite besteht, zu warten.
Wenn der Teslalogger nun seine Datensicherung auf die SD-Karte geschrieben hat, dann wird es Zeit, ein SFTP-Programm zu starten. In meinem Fall ist es Cyberduck auf dem Mac. Alternativ verwende ich auch gerne das Urgestein FileZilla, das es gefühlt auch schon immer gibt. Am Ende ist es aber vollkommen egal. Das Ziel ist es, sich auf dem RasPi anzumelden und die Backup-Dateien herunterzuladen. Diese findet man im Verzeichnis „/home/teslalogger/teslalogger/backup/“. Wenn man nach dem Datum sortiert, dann benötigt man eigentlich nur die beiden neuesten Dateien, die mit „DAY-geofence-private*.gz“ und „DAY-mysqldump*.gz“ beginnen. Aber um sicherzugehen, dass alle Daten in Ordnung sind, kann man sich natürlich auch den gesamten Datenbestand sichern. Benötigt für das Vorthaben des Umzugs wird aber nur die jeweils aktuellste Datei. Ob man die Geofence-Datei überhaupt benötigt, kann ich gar nicht sagen, da ich im Teslalogger keine Geofence-Bereiche definiert habe.
Feste IP-Adresse für den Teslalogger vergeben
Damit man keine bösen Überraschungen erlebt und der Teslalogger immer schön im Heimnetz erreichbar bleibt, sollte man dem RasPi einen aussagekräftigen Namen und eine feste IP-Adresse zuweisen und dafür sorgen, dass dieser auch immer die gleiche Adresse erhält. Ich verwende hier einen Fritzbox-Router, das Einstellen der IP-Adressen wird auf anderen Modellen sicher anders aussehen.
Das Grundsystem wird auf dem RasPi installiert
Alles neu mit Raspberry Pi OS
Früher war es deutlich komplizierter, ein System mit Raspberry OS zum Laufen zu bringen.
Heute reicht es, den Raspberry Pi Imager herunterzuladen, die Software zu starten und dem Einrichtungsdialog zu folgen. Nur, dass das Betriebssystem in diesem Fall nicht auf einer SD-Karte hätte landen sollen, sondern direkt auf der SSD. Weswegen ich mir auch noch ein externes Gehäuse für die SSD hätte kaufen müssen.
Habe ich auch, das SSD-Gehäuse kam nur nicht rechtzeitig an. Ungeduldig, wie ich halt nun mal so bin, habe ich mich dann doch für den längeren Weg über die SD-Karte entschieden. Was sich am Ende sogar als wahrscheinlich der bessere Weg gezeigt hat.
Von hier an wird der Rest des Beitrages ein Gemisch aus Erfahrungsbericht mit Anleitungs-Charakter. Also sieh es mir bitte nach, wenn ich wild zwischen „Ich habe dann“ und „Jetzt machst du am besten“ hin und her wechsle 🙂
Installation des Raspberry Pi OS
Im ersten Schritt wird die Installer-Datei geöffnet und das Betriebssystem ausgewählt.
Ich habe mich hier für die Version „Raspberry Pi OS (64-bit)“ mit Desktop entschieden, da ich die Desktop-Oberfläche gerne via Remote Desktop über TigerVNC nutzen möchte. Und wie sich das im späteren Verlauf als richtig erwiesen hat, da sonst die Konfiguration des Cloud-Syncs deutlich komplizierter vonstattengegangen wäre. Im folgenden Dialog lassen sich dann noch alle wichtigen Einstellungen, wie der Zugang zum WLAN oder SSH, konfigurieren.
WICHTIG: Hier in diesem Setup-Dialog vergibst du auch deinen Usernamen und dein Passwort. Nachfolgend in diesem Beitrag wird von mir der User „user“ mit Passwort „passwort“ für den SSH-Login verwendet. Dass ich diese Daten NICHT wirklich verwende, versteht sich hoffentlich von selbst, oder? 😉
Mit dem Klick auf „Schreiben“ geht es auch schon los, damit sind Installation und die erste Konfiguration des Grundsystems abgeschlossen. Die SD-Karte kann nun in deinen RasPi gesteckt und der kleine Computer an seinem neuen Arbeitsplatz aufgestellt werden.
SD-Karte auch mit Imager-Software beschreibbar
Natürlich kannst du deine SD-Karte auch mit einem Imager-Tool, wie dem balenaEtcher oder Win32 Disk Imager, beschreiben. Wie das geht, habe ich bereits in diesem Artikel ausführlich beschrieben. Das Image für diese Installationsart findest du dann hier.
Via SSH mit dem Raspberry Pi verbinden
Hilfe, ich hab’ den RasPi verbeult!
Solltest du bereits viel mit deinem RasPi ausprobiert haben, so wie ich, kann es leicht passieren, dass du beim Versuch, dich mit dem Minicomputer zu verbinden, die Fehlermeldung „WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED…“ zu Gesicht bekommst. Was es damit auf sich hat, kannst du zum Beispiel hier nachlesen. Dort findest du auch Wege unter macOS und Windows, um das Problem zu lösen.
Verwendest du ebenfalls wie ich einen Mac, dann gib Folgendes in deiner Terminal-Software ein (dazu ist keine Verbindung zum RasPi notwendig, würde ja momentan ohnehin nicht gehen):
ssh-keygen -R "[SERVER-NAME]oder[IP-ADRESSE]"Im Anschluss daran sollte sich dein Computer wieder per SSH mit dem RasPi verbinden lassen.
Jetzt aber echt, verbinden des Rasberry Pi via SSH
Ich verwende hier die App „Tabby“ aus dem Homebrew Appstore. Die SSH-Verbindung funktioniert natürlich auch mit der Standard-App „Terminal“, die unter macOS automatisch vorinstalliert ist. Unter Windows verwendest du eben das bekannte Tool PuTTY oder MobaXterm (oder was du auch immer dafür einsetzen möchtest).
Hast du deinen Terminal-Client geöffnet, dann gibst du Folgendes in der Kommandozeile ein:
ssh [DEIN USER]@[IP-ADRESSE DEINES RASPI]
Beispiel: ssh user@raspi-ultron.local
Beispiel: ssh user@192.168.178.190Oder, falls du einen anderen Port als den Standardport 22 verwenden solltest:
ssh -p [PORTNUMMER] [DEIN USER]@[IP-ADRESSE DEINES RASPI]
Beispiel: ssh -p 220 user@raspi-ultron.local
Beispiel: ssh -p 220 user@192.168.178.190Username und Passwort sind hier die im vorherigen Abschnitt konfigurierten Daten, also „user“ und „passwort„. Hast du andere Login-Daten erstellt, dann verwendest du natürlich diese.
Für den Fall, dass du noch nie etwas mit der Kommandozeile des RasPi zu tun hattest: nicht wundern, wenn sich während der Passworteingabe im Eingabefeld nichts bewegt, das gehört so. Einfach Passwort eintippen und mit Return bestätigen.
Grundeinstellung des RasPi
Da wir gerade erst ein nagelneues OS aufgesetzt haben, solltest du zuerst das Betriebssystem aktualisieren.
sudo apt update && sudo apt upgrade -yNach dem ersten Anmelden am Raspberry Pi ist nun ein Besuch im Konfigurationsmenü notwendig.
sudo raspi-configHier müssen bereits die ersten wichtigen Einstellungen erledigt werden.
Interface Options -> VNC aktivieren (für Verbindung mit TigerVNC zum RasPi Desktop)
Advanced Options -> PCIe Speed (Aktivierung der PCIe-Schnittstelle)
Localisation Options -> Locale -> Sprachen de_DE.UTF8, en_GB.UTF8 und en_US.UTF8 Danach eine VNC-Verbindung zum RasPi-Desktop aufbauen und die Software „SD Card Copier“ starten. Dieser kopiert die SD-Karte auf die NVMe-M.2-SSD … sofern man das Flachbandkabel im Gehäuse richtigrum eingebaut hat. Wenn nicht, dann sieht man die SSD im Programm nicht und kann alles wieder zerlegen. Wenn es was falsch herum einzubauen gibt, dann mach‘ ich das …
Der nächste Schritt ist noch einmal mit sudo raspi-config in die Konfiguration und eine weitere wichtige Einstellung tätigen.
Advanced Options -> Boot Order -> NVMe aktivieren (Start von SSD)Dann den Raspberry Pi herunterfahren, die SD-Karte entfernen (oder als Backup-Lösung drinlassen) und den Computer erneut starten. Wenn alles richtig gelaufen ist, sollte der RasPi nun vom neuen Speicherort starten.
sudo shutdown nowTeslalogger installieren
Das wichtigste war geschafft, jetzt ging es darum, den Teslalogger wieder zu installieren und die gespeicherten Daten wiederherzustellen.
Das habe ich bereits an anderer Stelle beschrieben: Teslalogger auf Raspberry Pi installieren
Teslalogger-Daten wieder herstellen
Die Wiederherstellung der Daten war natürlich so einfach, wie die vorhergehende Datensicherung. Im Menüpunkt „Extras“ den Punkt „Wiederherstellung“ und anschließend die Backup-Datei auswählen. Dann heißt es: lange warten und ja nichts anfassen 😉
Datensicherung auf dem Synology NAS
Jetzt, da die Schwachstelle SD-Karte beseitigt war und ich ein wenig mehr Vertrauen in die NVMe M.2 SSD hatte, wollte ich trotzdem noch eine zusätzliche Sicherung einbauen. Wir besitzen ein NAS von Synology als Datengrab, und was würde sich besser eignen, als Datenempfänger des Teslaloggers herzuhalten?
Nachdem ich nun einen freigegebenen Ordner auf dem NAS erstellt und mit den erforderlichen Rechten versehen hatte, ging es an das Einbinden des Verzeichnisses.
Als Erstes wurde ein Mount-Punkt erstellt.
sudo mkdir -p /mnt/nas_backupDanach musste die Datei /etc/fstab bearbeitet werden. Fstab ist übrigens eine Dateisystemtabelle, die vom Kernel beim Booten zum Mounten des Dateisystems verwendet wird.
sudo nano /etc/fstabHier muss dann einfach die folgende Zeile am Ende der Datei eingefügt und angepasst werden
//[IP-ADRESSE NAS]/[FREIGABEORDNER]/[BACKUP-VERZEICHNIS] /mnt/nas_backup cifs username=[USERNAME],password=[PASSWORT],uid=[UID],gid=[GID],file_mode=0777,dir_mode=0777 0 0
Beispiel: //192.168.178.100/backup/Teslalogger /mnt/nas_backup cifs username=user,password=passwort,uid=1000,gid=1000,file_mode=0777,dir_mode=0777 0 0Die UID und GID findest du übrigens heraus, wenn du im Terminal id eingibst.
Nach dem Speichern und Schließen der Datei müssen die Service-Konfiguration neu geladen und das Laufwerk im System eingehängt werden.
systemctl daemon-reload
sudo mount -aJetzt wird es spannend, man kann schon mal einen ersten Test mit rsync machen.
rsync -av --delete ~/Teslalogger/backup/ /mnt/nas_backup/Wenn alles gut gelaufen ist, dann sollten nun die Backup-Dateien aus dem Teslalogger-Verzeichnis in der NAS-Freigabe auftauchen. Das --delete bewirkt übrigens, dass, wenn Dateien auf dem Raspberry Pi gelöscht wurden, diese im Backup-Laufwerk auf dem NAS ebenfalls gelöscht werden. Sollte man dieses Verhalten nicht wollen, dann muss diese Option weggelassen werden.
Man kann übrigens auch, ohne gleich direkt rsync zu starten, die Schreibrechte auf dem Netzwerkordner prüfen. Hier wird bei ausreichenden Rechten eine testdatei.txt im Zielverzeichnis erstellt.
touch /mnt/nas_backup/testdatei.txt
Datensicherung automatisieren
Jetzt macht es natürlich keinen Sinn, das Programm rsync immer manuell zu starten. Aber um Probleme mit rsync vorzubeugen, falls das gemountete Laufwerk nicht verfügbar sein sollte (in diesem Fall würden alle Dateien in das Verzeichnis /mnt/nas_backup geschrieben werden), gilt es noch ein Bash-Script zu erstellen.
nano ~/backup_to_nas.shIn dieses Skript kommen folgende Einträge:
(Spoiler: Im Bereich der Cloud-Sicherung verändert sich das Script noch einmal deutlich…)
#!/bin/bash
# Zielpfad definieren
MOUNT_POINT="/mnt/nas_backup"
# Prüfen, ob der Pfad ein aktiver Mount-Punkt ist
if mountpoint -q "$MOUNT_POINT"; then
echo "NAS ist verbunden. Starte Backup..."
rsync -av --delete ~/Teslalogger/backup/ "$MOUNT_POINT/"
echo "Backup abgeschlossen."
else
echo "Fehler: NAS ist nicht gemountet! Backup abgebrochen."
exit 1
fiDanach muss das Skript noch ausführbar gemacht und in crontab eingerichtet werden.
chmod +x ~/backup_to_nas.sh
crontab -eHier am Ende der Datei noch Folgendes anhängen:
0 4 * * * /home/[DEIN USER]/backup_to_nas.sh Wenn crontab richtig arbeitet und das Skript funktioniert, dann sollten nun um 4 Uhr morgens die Teslaloggerdaten vom RasPi auf das NAS gespiegelt werden.
Zu guter Letzt kann die Zeile in crontab noch erweitert werden. Diese Erweiterung legt eine Log-Datei an, sodass immer geprüft werden kann, ob das Backup überhaupt funktioniert hat.
0 4 * * * /home/[DEIN USER]/backup_to_nas.sh >> /home/[DEIN USER]/backup_log.txt 2>&1Diese Log-Datei kannst du dann so auslesen:
cat ~/backup_log.txtSahnehäubchen Cloud-Sync
Um das Ganze noch spannender zu machen, noch das Sahnehäubchen auf den Synology-Sync. Die Daten sollen auch gleichzeitig in die Cloud (in meinem Fall auf „den Computer eines anderen“, nämlich den von pCloud) geladen werden. Hier an dieser Stelle habe ich dann mit KI-Unterstützung weitergemacht, denn vom Cloud-Sync hatte ich nun wirklich überhaupt keine Ahnung. An dieser Stelle vielen herzlichen Dank an Google Gemini.
Für mein Vorhaben eignet sich die Software rclone , weil diese bereits pCloud und viele andere Cloud-Anbieter nativ unterstützt. Dafür muss Rclone erst mal installiert werden, danach muss der Konfigurationsvorgang gestartet werden. Kleiner Hinweis aus eigener Erfahrung: Startet die Einrichtung im Terminal auf dem Raspberry Pi-Desktop. Man benötigt einen Webbrowser, um einen Access-Token zu generieren, und das geht mit der Browser-Unterstützung des Desktops deutlich einfacher, als mit einer SSH-Verbindung von einem entfernten Computer aus.
sudo -v ; curl https://rclone.org/install.sh | sudo bash
rclone configNun folgt eine Reihe von Einstellungen:
n -> für "New remote"
Name: pcloud
Storage-Typ: 45 (in der langen Liste nach pcloud suchen).
Client_id -> leer lassen
Client_secret -> leer lassen
Edit advanced config?: n
Use web browser to authenticate? Hier folgt nun der große Unterschied. Auf dem RasPi OS-Desktop öffnet sich mit y nun der Browser, man loggt sich beim Cloud-Dienstleister ein, erlaubt den Zugriff auf Online-Speicher, schließt den Browser, und das war es dann auch schon. Rclone macht den Rest und mit q kann das Konfigurationsmenü beendet werden.
Was bei einer SSH-Verbindung und dem Druck auf n passiert? Das erspare ich dir jetzt, verwende lieber Methode 1 😉
Nun muss das Skript ~/backup_to_nas.sh noch einmal angepasst werden. Google Gemini war dann so nett und hat dieses noch einmal komplett auf den Kopf gestellt. So sieht es nun aus:
#!/bin/bash
# Zielpfad definieren
MOUNT_POINT="/mnt/nas_backup"
LOCAL_BACKUP="/home/[DEIN USERNAME]/Teslalogger/backup"
LOGFILE="/home/[DEIN USERNAME]/backup_log.txt"
echo " " >> $ LOGFILE
echo "--- Backup Start: $(date '+%Y-%m-%d %H:%M:%S') ---" >> $LOGFILE
# 1. Sync zum NAS
if mountpoint -q "$MOUNT_POINT"; then
echo "NAS ist verbunden. Starte Backup..." >> $LOGFILE
rsync -av --delete "$LOCAL_BACKUP/" "$MOUNT_POINT/" >> $LOGFILE 2>&1
else
echo "Fehler: NAS ist nicht gemountet! Überspringe NAS-Backup." >> $LOGFILE
fi
# 2. Sync zu pCloud
echo "Starte pCloud Upload..." >> $LOGFILE
/usr/bin/rclone sync "$LOCAL_BACKUP/" pcloud:[VERZEICHNIS]/[UNTERVERZEICHNIS] >> $LOGFILE 2>&1
echo "--- Backup Ende: $(date '+%Y-%m-%d %H:%M:%S') ---" >> $LOGFILE
echo "------------------------------------------------" >> $LOGFILEVersteht sich wahrscheinlich von selbst, dass die Bereiche [DEIN USERNAME] und pcloud:[VERZEICHNIS]/[UNTERVERZEICHNIS] entsprechend angepasst werden müssen.
Jetzt kann man für einen Test das Skript testen und die Log-Datei auslesen.
bash ~/backup_to_nas.sh
cat ~/backup_log.txtSollte alles richtig gelaufen sein, dann müssten sich Backup-Dateien auf dem NAS und in der Cloud befinden.
Herzlichen Glückwunsch, wir haben das Projekt wohl erstmal gemeistert!
Zusammenfassend betrachtet: Was kann der RasPi jetzt?
- Völlig überdimensionierter Raspberry Pi 5 8GB
- Startet von NVMe M.2 SSD
- Hat eine Backuplösung auf der SD-Karte mit an Bord
- Beheimatet den Teslalogger
- Sichert die Daten automatisch auf einem Synology NAS
- Sichert die Daten automatisch in einer Cloud
Letzte Worte
Damit sollte der Teslalogger durchaus ein brauchbares und langlebiges neues Zuhause haben, das Ziel wurde eindeutig erreicht.
War das Ganze machbar? Auf jeden Fall.
War das Ganze notwendig? Auf jeden Fall nicht … aber das war auch der Spaß an der Sache. Man darf schließlich auch mal „mit Kanonen auf Spatzen schießen“ (! Man darf natürlich NICHT mit Kanonen auf Spatzen schießen !) 🙂
Abschließend lässt sich nur noch sagen, dass das neue System auf jeden Fall viel Platz für Spielereien bietet. Man könnte noch zusätzlich PiHole als Werbeblocker installieren, das Smarthome über Home Assistant steuern oder sicherlich noch viele weitere interessante Dinge ausprobieren. So, dass sich der RasPi 5 nicht mehr langweilen muss, da er vom Teslalogger hoffnungslos unterfordert ist.
Ich hoffe, euch hat dieser Beitrag gefallen und vielleicht auch auf die eine oder andere Idee gebracht. Wenn ihr Lust habt, dann könnt ihr ja gerne in den Kommentaren noch etwas zu euren Bastelideen oder Teslaloggern schreiben.
Auf jeden Fall vielen lieben Dank für das Lesen dieses Blog-Beitrags, bis zum nächsten Mal, und haltet immer eure Galionsfigur sauber,
euer Michael, der Couchpirat. … Arrrr!