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:
*/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
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!
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
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.
-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.
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
usermode = paranoid
8)
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.
Hallo,
ZitatSeit 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 8)
Grüße
Komisch, was macht Ihr denn für dubiose Sachen? Bei mir ist noch keine Datenbank abgekackt.
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 ;D ).
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
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
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.
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.
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.
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
Datenbanken gehören nicht auf USB Laufwerke.
define reopenDbLog at *01:31:00 set fhemDbLog reopen
ZitatDatenbanken gehören nicht auf USB Laufwerke.
Autsch - und nun?
Ich würde den Satz erweitern und sagen "Datenbanken in einer Produktivumgebung gehören nicht auf USB Laufwerke". Und dann unterschreibe ich das zu 100%. Auch gehören sie nicht auf SD-Karten.
wenn man am Verzweifeln ist, weil das fhem-Log abkackt, ist das fhem in diesem Fall wohl eine Produktivumgebung 8)
Bei mir werden alle Logdaten älter als 1 Woche jede Nacht automatisch gelöscht. Ich hab sie noch nie vermißt.
Bei mir nach 15 Tagen. Ein paar Temperaturdaten sichere ich vorher weg. Für den Rest habe ich noch keine längerfristige Verwendung ausmachen können.
Stimmt, wenn man verzweifelt ist, dann war es wohl was wichtiges ;) - Bei meinem Problem handelte es sich damals noch um erste Tests mit einem Raspberry, deshalb war ich nicht so traurig als die Daten weg waren.
Mmh, dann hätte ich aber auch keine Verlaufsgrafiken vom Strom, über´s Jahr.
VG
Frank
Es sei den du sicherst diese vorher ;D
Man kann Daten aus einer DB ja auch selektiv löschen. ODER man schreibt die Daten, die man über einen längeren Zeitraum benötigt, regelmäßig in eine andere Tabelle. So mache ich es mit einigen Temperaturwerten.
Oder Du legst Dir eine zweite LogDb an, in der Du nur die Werte aufzeichnest, die Du wirklich länger brauchst.
Na dann werd ich mal schauen wie ich meine DB auf eines meiner NAS bekomme.
Noch ein kleiner Hinweis für Aufrufe in ein einem crontab:
Ein Job, der per cron aufgerufen wird, hat nicht seine normale Userumgebung. Vorallem ist die PATH-Variable nicht gesetzt, d.h. viele programm findet das Unix-System NICHT mehr automatisch.
Hier dürfte z.B. der Befehl "sqlite3" nicht gefunden werden.
Das ist doch nun wirklich keine neue Erkenntnis. In der crontab sollte man ohnehin nur mit vollständigen Pfadangaben arbeiten - wie auch in fhem bei qx() - oder den Pfad einfach direkt in der crontab setzen.
Oder man legt sich einen symbolischen Link von /usr/bin/sqlite3 nach /bin/sqlite3.
Dann Gucke Dir bitte Seine crontab im ersten Beitrag an.
Und auch wenn es "bekannt" sein sollte, 90% der Anfänger-Crontab-Fehler kann man mit diesem Hinweis "lösen"
Ja, Du hast ja Recht.
Trotzdem ist der cronjob hier grundsätzlich der falsche Ansatz. Da spielt auch der Fehler in der crontab keine Rolle mehr 8)
Oder noch genauer gesagt:
Eine solche Komplexer Befehlskette gehört in ein eigenständiges Proggi /bash-Datei)
Wir sind wieder mal auf einer Linie :D
P.S. (Sorry fürs Kapern)
Ich hatte mal vor kurzen in einem Beitrag einige Unix-Befehle kurz beschrieben. Weißt Du eventuell, welcher Beitrag es war? Finde den nicht wieder .....
Hat sich erledigt. Komisch .. man fragt jemanden und gleich darauf findet man die Lösung