Edomi Backup steigt ins unermessliche!! (SQL SERVER?)

[Kirbsi]

Hallo Edomifreunde ????. Ich nutze seit jetzt knapp 2 Jahren Edomi und bin sehr zufrieden. Das einzige was mich immer in die Knie zwingt sind die immer größer werdenden Backup Dateien. Meine Backupdatei erhöht sich um ca. 1,5GB pro Monat. Ab einer Größe von 3 bis 4 GB gibt es Probleme beim ändern des Programmes. Dauert alles zu lange und manchmal geht es gar nicht. Aus diesem Grund bin ich gezwungen alle 2 -3 Monate meine Datenarchive zu löschen. Was sehr schade ist.
Was gibt es für Möglichkeiten meine Datenarchive auszulagern?
Ich hatte die Idee meine Daten auf einen Externen SQL Server zu schicken um die Backup-Dateien klein zu halten. Liege ich damit richtig das dann die Datenarchive nicht mehr mit in der Backupdateien sind? Oder gibt es andere Möglichkeiten die Datenarchive aus der Backupdateien zu bekommen.
Der MySQL – Server auf alle Fälle ist eingerichtet und die Kommunikation funktioniert auch.
Aber sobald den SQL Server umstelle in der Basis-Konfiguration verschwinden alle meine Daten. (Logikseiten und Visuseiten) Gibt es eine bestimmte Vorgehensweise wie man seine Dateien auf einen Externen SQL- Server verschieben kann. Also Live- Projekt löschen à umstellen und dann erzeugen oder so?? Habe gestern 10h versucht meine Daten zu verschieben. ohne Erfolg. Entweder sind alle meine Logikseiten und Visuseiten weg oder ich habe kein Projekt mehr. Wer kann mir weiterhelfen?

[vento66]

Ich würde

1. Edomi stoppen
2. Datenbank auf den Server klonen
3. Basis Konfig ändern
4. EDOMI Server neustarten

Zumindest mal als Überlegung. Ich habe das praktisch noch nie gebraucht.

[jonofe]

Auch wenn du deine SQL DB auf einen anderen Server verschiebst werden die Daten nicht weniger, denn du musst auch von der DB auf dem neuen Server ein regelmäßiges Backup machen. Auf die Performance wird es vermutlich signifikanten Einfluss haben, da EDOMI m.W. weitgehend mit eine in-Memory mySQL DB arbeitet. Bei einem externen mySQL Server müsste dann alles übers Netz gehen. Vermutlich keine gute Idee.

Ich würde zunächst an deiner Archivierungsstrategie ansetzen und diese optimieren. Was genau archivierst du denn über 2 Jahre was du wirklich irgendwann noch mal brauchst. Ggf. kann man das aggregieren Jahr, Monat, Woche, Tag, Stunde, ... etc.

Auch wenn du bestimmte Archive nicht mit ins Backup reinnimmst werden diese trotzdem immer größer und das beeinflusst irgendwann die Performance von EDOMI signifikant. Je weniger Rechenleistung desto größer der Einfluss. Wie man das trotzdem machen kann, wurde hier vor kurzem schon mal beschrieben. Grundsätzlich musst du das EDOMI interne Backup deaktivieren und dann per CRON regelmäßig ein eigenes TAR Archiv erstellen, in welchem du die nicht benötigten Archive rausfilterst.

HIER der Link zu dem Beitrag: https://knx-user-forum.de/forum/proj...51#post1282951

Wenn es nur um den Speicherplatz geht, dann einfach eine externe Platte oder ein SMB/CIFS oder NFS share nach /var/edomi-backups mounten, dann läuft zumindest die EDOMI Platte nicht voll.

[steffen79]

Kirbsi bist du sicher dass es an deinen datenarchiven liegt? Mal in das backup reingeschaut was da überhaupt den platz frisst? Ich meine es war (ist?) mal so dass die kamerabilder im
archiv landen... die fressen natürlich speicher. Gigabyte an datenarchiven wären merkwürdig und nach meinen erfahrungen eh nicht mehr praktikabel anzuzeigen, da solltest du mal über die parameter max dauer und totzeit schauen

[wintermute]

Ich hatte auch mal GB-grosse Backups nur wegen Debug-Ausgaben einiger LBS. Koennte man auch mal checken...

[ChrisAllgaeu]

Ich speichere in Edomi Datenarchiven nur einen relativ begrenzten Zeitraum, schreibe mir aber dafuer im Hintergrund (ausserhalb von Edomi) eine Round Robin Table (RRT) mit. Das hat den imensen Vorteil, dass nach vorgegebenen Regeln die Daten "konsolidiert" werden und deswegen der Speicherbedarf extrem ueberschaubar bleibt (geht natuerlich nicht fuer Kamera/Bildarchive). Der Preis den man dafuer zahlt ist halt die geringere Datenaufloesung, je weiter man in die Zukunft schaut. Geht halt nicht mehr auf den Solarertrag in 15 Minuten Scheiben von vor 2 Jahren zu schauen... das sind halt jetzt Tage geworden.... nur so als Tipp oder Anregung....

[Brick]

Round Robin Table (RRT)

So etwas hätte ich gern nativ in Edomi.. aber ich glaub da hatten wir schon mal drüber gesprochen..

[mfd]

Waren das nicht die rrd's aus längst vergangenen Wiregate-Tagen? *schwelg*

Früher war doch nicht alles schlechter

[gaert]

Uff meiner Liste steht schon länger etwas in der Art - kurz gesagt könnten (irgendwann) Archivzeiträume quasi zusammengefasst werden, so dass nur ein entsprechender Mittelwert im Archiv verbleibt. Das Ganze wird wahrscheinlich als LBS verpackt, aber das steht noch nicht fest. Eventuell erweitere ich auch die Archiv-Konfiguration entsprechend, so dass quasi eine automatische "Komprimierung" möglich wird. Von Ringpuffern halte ich in diesem Kontext eher nicht so viel, aber je nach Einstellung der (neuen) Optionen wäre dies natürlich auch indirekt möglich.

EDIT:
Ein Ringpuffer ist ja im Grunde schon jetzt möglich - einfach die "Haltezeit" entsprechend einstellen. Ist zwar auf Zeiträume bezogen (statt Anzahl der Daten), aber kommt ja mehr oder weniger auf's Selbe raus...

[Kirbsi]

Danke für eure schnellen zahlreichen Antworten.
vento66 die Idee klingt einfach und klingt auch verdammt logisch aber gar nicht so einfach umzusetzen.

jonofe Ich habe 130 Datenarchive. Sicherlich sind nicht alle auf eine dauer von mehreren Jahren sinnvoll aber Daten wie Strom, Wasser und Sportaktivitäten möchte ich schon über mehrere Jahre miteinander vergleichen.Die SQL Datenbank lässt sich schneller sichern als die Backupdateien.

steffen79 Die Kamerafunktion nutze ich nicht da ich das auf meiner Synology DiskStation mache. Läuft besser.

wintermute sind wirklich nur Datenarchive lache nicht. Bin halt n Statistiktyp

ChrisAllgaeu . Nicht meins

Da ich beide Systeme auf dem gleichen ESXI6.5 Server am laufen habe, sehe ich keine Netzwerkprobleme auf mich zukommen da ja der Switch nur Virtuell ist. Auf unterschiedlichen System wäre das nicht ratsam. Sobald der Edomi mal keine Verbindung zum SQL Server hat, steigt Edomi aus.
Ich habe jetzt über Nacht bei meinem Test-Edomi die SQL Einstellung auf meinen externen SQL- Server gelegt, und über Nacht 130 Millionen Datenpunkte gespeichert. Und siehe da, die Backupdateigröße hat sich nicht geändert. Ist bei 130MB geblieben. Obwohl der archivKoData 8,4GB hat. So stelle ich mir das vor. Jetzt muss ich nur noch mein aktuelles Projekt auf den SQL-Server bekommen.
Wie sich so eine große Archiv-Datei auf die CPU und auf das darstellen in Diagrammen auswirkt, muss ich noch testen.

[sviper]

Hallo Leute,

meine Backups sind derzeit auch bei ca. 1,8GB.
Unter den Punkt Datenbanken bei Verwaltung sind ja die Größen der DB's ersichtlich. Sind 1.068 MB eigentlich 1,068 MB oder wirklich 1068 MB ?

[jonofe]

Wie groß sind denn deine Logfiles?

[sviper]

Hallo die Logs sind ziehmlich Groß sehe ich gerade.
Dem muss ich mal nachher nachgehen.

Danke für den Tipp.

[Brick]

Speicherst du deine Verbrauchdaten in den Logfiles ?
so war das wohl nicht gedacht ...

Gruß Martin

[sviper]

Bei den LBS (19001642) für die Verbrauchsdaten steht das Loglevel standardmäßig auf 8. Das habe ich jetzt mal auf 0 gesetz.