Darf ich fragen, wie du vorgegangen bist? Ich habe noch Portainer dazwischen und zum Updaten des Stacks aus vier verschiedenen Containern, nutze ich immer einen Compose-Befehl von Mariushosting, was super funktioniert.
Hier einfach im Grafana Part die 14 durch die 17 zu ersetzen, wird vermutlich nicht funktionieren 
Doch, genau das hab ich gemacht 
image: postgres:17
Du musst halt die Schritte durchführen für DB Backup and restore.
Also Teslamate stoppen, db backup machen, 14er db löschen, Postgres14 stoppen, Ordner löschen (wichtig), dann mir Portainer neu erstellen, sobald Postgres17 up ist, (dann sind auch die ordner wieder da) restore vom Backup und fertig
Genau die von dir aufgezählten Punkte machen mir Probleme.
Geht schon beim Backup los. Wenn ich per SSH auf die Synology gehe und
docker compose exec -T database pg_dump -U teslamate teslamate > ./teslamate.bck
Eingebe (gemäß Anleitung auf TeslaMate Website), wirft er mir schon den ersten Fehler
schreib mal
sudo docker-compose
Im Verzeichnis, wo du die .yaml hast bist du eh? Also im root Verzeichnis von docker. wo dein Grafana liegt.
Ich weiß leider nicht, wo die .yaml liegt. Diese kippe ich ja in Portainer als Stack ein.
Hi Supertoy,
die sollte bei dir in /docker/teslamate liegen
Leider nicht
Ich habe es jetzt aber ganz abenteuerlich gelöst und zwar bin ich via Portainer in die Konsole des Postgres Containers selbst, habe dort die Befehle abgesetzt ohne das Docker-Geplänkel davor, dann die Backup-Datei in Sicherheit gebracht und auf dem gleichen Weg wiederhergestellt, also schon gemäß der Anleitung von Teslamate nur eben direkt im Container.
Sicher nicht im Sinne des Erfinders, aber was solls, es läuft wieder 
Danke dir trotzdem!
EDIT: Gerade noch den Ort der docker-compose gefunden. Teste ich dann beim Update auf Postgres 18 nochmal
ich habe bisher immer „docker exec database psql …“ in Verbindung mit portainer benutzt. Hat bisher funktioniert. Dieses mal konnte ich aber das backup nicht wieder einspielen.
Habe dann auch direkt im container wiederhergestellt.
Muss man eigentlich davon ausgehen, dass die Postgres-DB nicht sauber gebackupt wird, wenn man nachts die komplette NAS inkl. aller Docker Container sichert, da die DB ja dauerhaft im Zugriff ist? Dann müsste ich vor meinem Backup-Job per Skript die Teslamate-relevanten Container stoppen.
Du kannst nur dann sicher sein, wenn der container gestoppt wird. Andererseits, solange in dem Moment kein Schreibzugriff auf die DB erfolgt, sind die backups brauchbar.
Probiers aus.
Hallo,
ich habe alles ohne Fehlermeldung geschafft, jetzt aber beim Einspielen des Backups läuft mir das durch die Konsole:
Wo lag der Fehler?
Hab die Befehle alle noch einmal eingegeben, dann kam ich zumindest weiter
Das ist schon echt schlimm, wenn man nicht weiss, was man hier machen muss.
Es läuft aber
Warum macht man kein Datenbank-Backup, wenn man ein Datenbank-Backup haben möchte und alle Beteiligten inkl. dem Maintainer ein Datenbank-Backup empfehlen und genau das in einem Docker-Umfeld auch völlig ausreichend ist? 
Die Kopie einer Datenbank z.B. mit Hilfe einer (NAS-)Systemkopie muss nach der Rückkopie nicht kaputt sein, ist sie aber im Fall der Fälle dann meistens doch. Ein Restore des DB-Backups dürfte hingegen zu quasi 100% eine funktionierende Datenbank ergeben.
Bitte versucht die Konzepte zu verstehen! Es hilft wirklich und ist in Zeiten ordentlicher Projekt-Dokumentationen, Google, ChatGPt und YouTube nicht mehr besonders schwierig.
Einziger ergänzender Tipp: Macht euch noch eine externe Kopie eurer docker-compose.yml und dokumentiert kurz, falls ihr euer System speziell aufgesetzt habt.
Dann seit ihr selbst beim schlimmsten Crash ein paar Minuten nach Aufsetzen der neuen Hardware wieder auf dem Stand vom letzten externen(!) Backup.
Viel Erfolg! 
Danke
Das Problem hatte ich schon beim Update auf postgres 16.
Hat ewig gedauert, bis ich rausgefunden hab, woran es lag.
So konnte ich meine Schritte für postgres 17 einfach wieder holen und hat wunderbar geklappt.
oder wie würde ich von meinem laptop zur db connecten? am liebsten via sql ace. raspberry pi & Rechner sind im gleichen Netzwerk. einfach nach 192.168.1.15:3000 zu connecten funktioniert nicht…
Nein ist m.W. nicht möglich, weil der Wert von einem Query in den Grafana-Variablen berechnet wird.
Am einfachsten ist es wie hier zitiert:
Du brauchst den richtigen DB Port, d.h. der muss ggf. beim Postgres-Service nach außen gemappt werden.
Und vielleicht mal versuchen mit
https://dbeaver.io/
Richtig, z.B. so im postgres-Bereich der docker-compose.yml
ports:
- 5432:5432
Soeben ist die v1.31.1 erschienen:
Diese Version verhindert in erster Linie, dass beam.smp die CPU auf ARM-Hosts überlastet. Sie enthält auch eine Reihe von anderen Fehlerkorrekturen und Leistungsverbesserungen. Viel Spaß damit.
Ansonsten gelten weiterhin die Hinweise von v1.31.0 weiter oben
Läuft, danke!
Ich würde TM echt sehr vermissen, wenn ich mal auf eine andere Marke umsteigen sollte. Macht einfach immer Spaß, sich durch die verschiedenen Dashboards zu klicken
Die neue Version läuft super. Tolle und schnelle Arbeit vom Teslamate Team. Dankeschön.