Backup von DBlog?!

[Soc]

Hallo Zusammen,

wie einige von Euch sicherlich schon lange ihre Logs auf eine Datenbank umgestellt haben, stellt sich für mich die Frage wie ein sinnvolles Backup dieser Datenbank (in meinem Fall sqlite3) gemacht werden soll.

Im Forum habe ich gelesen das manche die DB "einfach" kopieren (vermutlich wird das auch beim Command "backup" so gemacht).

Da fhem ständig in die DB schreibt, kann meines Erachtens ein cp des Files erfolgreich sein oder auch nicht.
Wenn wärend fhem einen Satz schreibt und der cp ... paralell läuft, ist es fraglich in was für einen Zustand die DB gesichert wurde.

Wie macht ihr das?

Gruß

Soc

[betateilchen]

Dazu gibt es schon mehrere Threads hier im Forum. Vielleicht solltest Du mal anfangen, die Suche zu benutzen, bevor Du zu jedem Grundsatzthema einen eigenen Thread eröffnest. Du bist nicht der Erste, der mit DbLog arbeitet.

[Soc]

Hallo betateilchen,

wie es so mit dem suchen ist. Es steht und fällt mit dem Suchbegriff.
Da kann es schon sein, dass ich vermutlich den falschen Begriff (dblog backup) verwendet habe. Dafür schon mal Entschuldigung.

Es ist sicherlich als Entwickler zermürbend wenn man "ständig" Fragen lesen muss welche wohl schon x-mal diskutiert wurden.

Die Frage ist nur wie man darauf reagiert.
Meines Erachtens gibt es dafür mehere Reaktionsmöglichkeiten:

1. Einen Link posten.
2. Daraus aufmerksam machen das diese Thema in Forum unter Suchbegriff xyz zu finden ist.
3. nicht reagieren.

Eine Option 4. (Den Fragenden zurechtweisen) ist sicherlich möglich. In wie weit diese Reaktion dem Sinn einer community entspricht muss jeder für sich selber entscheiden.

Gruß

Soc

[Soc]

Ich habe im Forum nach "dblog" gesucht und jeden der gefundenen Beiträge (wenn der Betreff einigermassen gepasst hat) angesehen.
Leider finde ich weiterhin keinen Beitrag der das Thema beleuchtet.

Kennt jemand solch einen Beitrag und kann den Link posten?

Danke

Soc

[marvin78]

Wenn du Sorgen wegen der Datenkonsistenz hast, musst du vor dem Backup (egal auf welche Weise es erfolgt), meiner Ansicht nach entweder fhem beenden oder das Logging stoppen (das entsprechende DBLog Device per at oder ähnlichem auf disabled setzen). In der Zwischenzeit werden natürlich keine Daten geloggt. Eventuell lässt sich das bei geschickter Planung aber verschmerzen.

[Soc]

Ich denke auch das wahrscheinlich ein temporäres stoppen von fhem sinnvoll ist. Das kann man ja in der Nacht durchführen.
Wie Script dann einen cp durchführen und anschliessend fhem wieder starten.

[marvin78]

Ich würde es zunächst mit der disable Methode versuchen. Aber wie es für dich am besten ist, wirst du heraus finden müssen. Eine Recherche in einer Suchmaschine deines Vertrauens zum Thema Datenbanken kann sicher auch nicht schade. Für so etwas gibt es ja gefühlt 10000e bessere Anlaufstellen.

[blofield]

Hallo,

ich nutze DBLog mit MySQL. Meine Table liegen in InnoDB und zum Backup nutze ich mysqldump http://dev.mysql.com/doc/refman/5.5/en/mysqldump.html, welches per cronjob angeworfen wird. Nach meinem Verständnis lockt mysqldump ggf. eine Row oder einen Table, so dass während des Vorganges nicht geschrieben werden kann und somit ein konsistentes Backup besteht.

Vielleicht gibt es ja für sqlite ähnlich DB tools

blofield

EDIT: Gleiches Thema hier im Forum: https://forum.fhem.de/index.php/topic,46319.0

[betateilchen]

Ich würde es zunächst mit der disable Methode versuchen.

Das wird nichts daran ändern, dass die Datenbankdateien für das Logfile geöffnet bleiben - auch die temporären Arbeitsdateien. Damit wird das Sichern nicht konsistenter.

Ich würde die Datenbanksicherung komplett auf Betriebssystemebene in folgenden Schritten machen:

• Mit der Datenbank verbinden - sql Datenbanken lassen mehr als eine Verbindung gleichzeitig zu
• Dump des Datenbankinhalts in eine Textdatei
• Verbindung abbauen

[marvin78]

Du hast recht. Nach einem disable bleibt das DBLog Device connected. Schade.

[Soc]

Die Idee ist natürlich noch besser.
Da mian davon ausgehen kann das die Datenbank am besten mit der DB umgehen kann ist eine .dump die Lösung.

[rudolfkoenig]

Weiteres Vorteil von mysqldump ist, dass das Ergebnis lesbares SQL ist, die man im Zweifel mit einem Editor bearbeiten kann,
z.Bsp. wenn man nur eine Tabelle oder bestimmte Werte zuruecksichern will. Mit etwas Know-How und Texteditor-Akrobatik kann man die Daten sogar in andere Datenbanken einlesen.

[Soc]

Das gilt aber nur für mySQL? Ich verwende sqlite3.

[betateilchen]

das funktioniert auch mit sqlite.

[Soc]

Hab mich mal in der Doku umgeschaut.
Hast Recht, gibt es auch bei SQLite3.

Das geht dort mit .backup im Gegensatz zu .dump.