cronjob zum Backup fhem.db

[franky08]

Hallo, ich habe einen crontab zum sichern der DbLog Datenbank erstellt, der stündlich ausgeführt wird. Nur wird im Verzeichnis /home/db eine archiv Datei erstellt die keine Dateiextension hat.
Der Programmaufruf in crontab ist folgender:

Code Auswählen Erweitern

*/59 * * * * sqlite3 /home/db/fhem.db .dump > fhem.sql && tar -zcf fhem.sql.tar.gz fhem.sql --remove-files && mv fhem.sql.tar.gz /home/fhem/archiv

Müsste da nicht eine fhem.sql.tar.gz angelegt werden oder hab ich da was übersehen?

VG
Frank

[betateilchen]

Bei sqlite kannst Du Dir den ganzen Umweg über den Dump sparen, da die gesamte Logdatei in einer einzigen Datei steckt. Du kannst also direkt die .db Datei kopieren und die kopierte Datei gzippen (falls wirklich nötig)

Dein Cronjob wird in dieser Form übrigens ohnehin nur funktionieren, wenn fhem in diesem Moment nicht läuft, weil parallel noch das Journal geöffnet ist!

[franky08]

Hallo betateilchen, wenn ich auf der Console den Befehl aufrufe funktioniert er und da läuft fhem doch auch noch?

Dann also nur mit cp /home/db/fhem.db /home/fhem

Würde das bei laufendem fhem funktionieren ?
VG
Frank

[betateilchen]

Der tar bzw. gzip Befehl an sich funktioniert schon, aber er tut nicht zwangsläufig das, was Du erwartest (es ist nicht sichergestellt, dass der tatsächliche Inhalt gesichert wird)

Mach mal ein ls -al in dem Verzeichnis während fhem läuft, dann siehst Du, dass zu der geöffneten Logdatei noch ein paar andere Dateien gehören.

Code Auswählen Erweitern


-rw-r--r-- 1 fhem dialout  911 Mär  9 21:35 logDB.conf
-rw-r--r-- 1 fhem dialout  20M Mär 11 18:25 logDB.db
-rw-r--r-- 1 fhem dialout  32K Mär 11 18:25 logDB.db-shm
-rw-r--r-- 1 fhem dialout 1,1M Mär 11 18:25 logDB.db-wal


nur die Kombination aus logDB.db + logDB.db-wal beinhaltet die komplette Menge aller geloggten Einträge.

[franky08]

Stimmt, da gehört die *.wal und die *.shm noch dazu, dann kopiere ich die eben stündlich nach /home/fhem. Seit es mir vor 2 Monaten die komplette Db zerdeppert hat (tables nicht mehr gefunden) will ich auf Nummer sicher gehen und eine Kopie der Dateien haben.

VG
Frank

[betateilchen]

Code Auswählen Erweitern

usermode = paranoid



Tipp: wenn Du vor dem Sichern ein "set <logName> reopen" machst, wird die Journaldatei weggeschrieben und die Datenbank sofort wieder geöffnet. Danach kann in der -wal kaum was relevantes drinstehen und das Verlustrisiko, wenn man nur die .db sichert, ist minimal.

[Puschel74]

Hallo,

Seit es mir vor 2 Monaten die komplette Db zerdeppert hat (tables nicht mehr gefunden)

na da bin ich aber froh das ich nicht alleine damit bin 

Grüße

[betateilchen]

Komisch, was macht Ihr denn für dubiose Sachen? Bei mir ist noch keine Datenbank abgekackt.

[Puschel74]

Hallo,

Das ist ja das (un)schöne.
Ich hab nichts gemacht (blöder Spruch ich weiß).

Am Abend noch schnell mal ein paar Plots angeschaut und am nächsten Morgen war die Datenbank korrupt - du kennst ja meinen Beitrag dazu (und deine Lösung für die Sicherung  ).
Und die DB liegt bei mir auf einer USB-HDD - diese hängt per aktivem HUB am RasPi und das Netzteil des HUB sollte ein einziges Gerät (ok es ist eine HDD d.h. 2 USB-Anschlüsse am HUB belegt aber trotzdem) doch bewältigen können - hoffe ich.

Grüße

[franky08]

War bei mir ähnlich, am Abend noch alles OK und am nächsten Tag keine Plots mehr und im Charting Frontend habe ich dann gemerkt das alles weg war.

VG
Frank

[betateilchen]

Ok, bei mir ist das Log nie länger als 24 Stunden offen, denn per at-Job wird jede Nacht um 01:30 Uhr ein reopen durchgeführt.
Das vermeidet zuverlässig Speicherüberläufe, mit denen ich ab und zu mal zu kämpfen hatte, aber die Datenbank war dadurch trotzdem nicht kaputt.

Code Auswählen Erweitern


2014.03.11 01:31:01 3: Connecting to database SQLite:dbname=/opt/fhem/log/logDB.db with user
2014.03.11 01:31:01 3: Connection to db SQLite:dbname=/opt/fhem/log/logDB.db established for pid 1894
2014.03.11 01:31:01 3: Connection to db SQLite:dbname=/opt/fhem/log/logDB.db established
2014.03.11 01:31:01 3: reopenDbLog: Reopen executed.


[marvin78]

Bei mir ist das bisher nur passiert, wenn die DB auf einem USB Laufwerk lag und der Mountpoint verloren ging. Allerdings war dann nicht die komplette DB im Eimer sondern nur die history Tabelle gecrasht. Diese lies sich in 2 von 3 Fällen reparieren (MySQL).

Seit es die Möglichkeit auf diese einfache Weise gibt, macht ich Nachts per at ein reopen und erhoffe mir (zusätzlich dazu, dass die DB nun auf SATA-SSD liegt) davon, dass das auch zur Gesamtstabilität beiträgt.

[franky08]

Also zur Sicherheit mittels at ein reopenDbLog: Reopen executed. anlegen? Probier ich mal, musste vor 2 Monaten die sqlite komplett neu anlegen und die Daten von einem halben Jahr waren natürlich futsch.

VG
Frank

[betateilchen]

Datenbanken gehören nicht auf USB Laufwerke.

Code Auswählen Erweitern

define reopenDbLog at *01:31:00 set fhemDbLog reopen

[Puschel74]

Datenbanken gehören nicht auf USB Laufwerke.

Autsch - und nun?