Hallo,
ich möchte meine Log-Dateien auf eine USB-Stick der direkt am Raspberry angeschlossen ist speichern lassen!
Ich habe das alte lgo - Verzeichniss auf dem USB stick kopiert!
Der Pfad heißt jetzt:
media/pi/log
Doch wenn ich im Device Logfile das Verzeichniss von z.B.:
./log/Katze-%Y-%m.log Katze.*
auf
media/pi/log/Katze-%Y-%m.log Katze.*
ändern möchte, kommt die Meldung:
Can't open media/pi/log/Katze-2017-08.log: No such file or directory
Der Besitzer von media/pi/log/Katze-2017-08.log ist FHEM!!!
LG
Marlen
P.S.: Der USB Stick wurde automatisch erkannt!
Mach mal log-folder mit /media/pi/log. da fehlt der slash am anfang
Gesendet von meinem SM-J510FN mit Tapatalk
Mache doch gleich ein
attr global logdir /media/pi/log
Dann bist Du auch auf der sicheren Seite, wenn mal in der Zukunft per Autocreate
ein neues Device dazu kommt.
Ja, so hab ich jetzt auch gemacht!
Der Fehler warum es nicht ging war, dass der Besitzer des Verzeichnisses pi root war!
LG und vielen Dank,
Marlen
Zitat von: bergadler am 12 August 2017, 21:32:58
Mache doch gleich ein
attr global logdir /media/pi/log
Dann bist Du auch auf der sicheren Seite, wenn mal in der Zukunft per Autocreate
ein neues Device dazu kommt.
Welchen Sinn hat es, logs auf einen USB Stick zu schreiben? Für mich ist das völlig absurd.
Hab mal gelesen, dass das ständige schreiben auf der SD-Karte diese irgendwann dadurch den Geist aufgibt!
LG
Malen
Zitat von: Marlen am 12 August 2017, 21:59:05
Hab mal gelesen,
achso, ich dachte, es hätte wirklich einen Grund...
Naja, über Jahren hinweg hab ich da schon meine bedenken!
Zitat von: Marlen am 12 August 2017, 21:59:05
Hab mal gelesen, dass das ständige schreiben auf der SD-Karte diese irgendwann dadurch den Geist aufgibt!
LG
Malen
Dito. Meine ganze cfg inkl log liegt auf usb stick.
ich zieh jetzt aber um auf ssd platte.
Gesendet von meinem SM-J510FN mit Tapatalk
SD-Karte, SSD und USB Sticks sind alle NAND Storage. Sprich.... eine gute SD-Karte (mit wear levelling) hält genauso lange wie ein USB Stick. Das Vorteil von der SSD Festplatte ist die Grösse. Damit hat das wear levelling mehr Platz, um effizient zu sein.
Kleine Doku: https://web.archive.org/web/20150326122100/http://ugweb.cs.ualberta.ca/~c274/resources/hardware/SDcards/WPaperWearLevelv1.0.pdf
Sinnvoller wäre m.A. die SD Karte mit f2fs zu formatieren. Oder RAM Speicher zu optimieren... oder... oder. Aber auf USB Stick auslagern... hmmm... skeptisch
Moin,
ich habe in den Anfängen aus gleichem Grund auch auf USB-Stick ausgelagert, bis der dann gehimmelt war.
Danach bin ich auf SSD umgestiegen. Seitdem toitoitoi
Vieles Glaubensfrage ... ich habe Logs von Fhem, Syslog (/var/log) und die Datenbankfiles als Ramdrive und synchronisiere diese, ich glaube, 2 mal am Tag. Meine SD-Card läuft seit 2013 oder 2014. Und sie war damals schon gebraucht.
Viel wichtiger ist es, regelmäßige Backups zu machen :)
Ich hab einfach alles auf der SD Karte und mache automatisch regelmäßige Backups auf ein NAS.
Die Kosten für eine neue SD Karte (Sandisk Ultra 16GB für 10€) kann man doch getrost ignorieren.
Meine 4 raspberry laufen seit 2 Jahren ohne Probleme auf SanDisk 16GB. Backuo jede Nacht aufs Netzwerk. Werd aber dennoch die Karten bis zum Jahresende prophylaktisch austauschen.
Gesendet von meinem S3_32 mit Tapatalk
Zitat von: gloob am 14 August 2017, 17:07:23
Ich hab einfach alles auf der SD Karte und mache automatisch regelmäßige Backups auf ein NAS.
Die Kosten für eine neue SD Karte (Sandisk Ultra 16GB für 10€) kann man doch getrost ignorieren.
Es geht mir auch nicht um die 10€ sondern um den kompletten Systemausfall!
Ich mach auch das Standart FHEM Backup auf ein NAS, aber damit lässt sich ja nicht das gesamte System wiederherstellen!
Ich mach auch in unregelmäßigen abständen ein IMG von der gesamten SD-Karte!
LG
Malren
Zitat von: Marlen am 16 August 2017, 14:02:42
Es geht mir auch nicht um die 10€ sondern um den kompletten Systemausfall!
Ich mach auch das Standart FHEM Backup auf ein NAS, aber damit lässt sich ja nicht das gesamte System wiederherstellen!
Ich mach auch in unregelmäßigen abständen ein IMG von der gesamten SD-Karte!
Das Sichern der kompletten SD-Card kannst auch automatisieren ... schau dir mal das an ... https://www.linux-tips-and-tricks.de/de/schnellstart-rbk (https://www.linux-tips-and-tricks.de/de/schnellstart-rbk) Mach ich Wochenende per Crontab. Im Fehlerfall Image der SD-Card zurückspielen, Fhem-Sicherung einspielen und du hast ein laufendes System. Für den Fall, dass du DBLog verwendest musst du das auch sichern.
na eben.
nen Image von der ganzen SD
plus
das Tägliche backup von der NAS
plus
eine Reserve SD Karte im Schieber.
damit hast innerhalb kurzer Zeit das System wider am laufen.
Zitat von: Frank_Huber am 16 August 2017, 15:19:30
das Tägliche backup von der NAS
das ist aber ein bisschen viel speicherplatzverbrauch, oder? :o 8) 8) 8)
Ja, wollte das schon mal testen, aber das Image von einer 32GB Karte passt nicht unbedingt wieder auf eine 32GB Karte! :o
Nils, volles sd Backup separat. Täglich auf die nas sind je nach Instanz 40 bis 90 MB.
Marlen, auf jeden Fall ne identische Karte nehmen. Dann passt das zu 99,9 Prozent. Zur Not ne größere. 😉
Gesendet von meinem S3_32 mit Tapatalk
Zitat von: Frank_Huber am 16 August 2017, 16:31:45
Nils, volles sd Backup separat. Täglich auf die nas sind je nach Instanz 40 bis 90 MB.
ja schon klar....
du hattest nur vorher
Zitat von: Frank_Huber am 16 August 2017, 15:19:30
das Tägliche backup von der NAS
geschrieben. ::)
und das fand ich dann etwas viel 8)
Klar, war evtl missverständlich. 😉
Gesendet von meinem S3_32 mit Tapatalk
Bei USB,SD und SSD kommen aber unterschiedliche "Quallitäten" von Flash-Speicher zum einsatz.
Bei SD die teueresten (und besten), bei USB-Sticks die "Rampschware". SDCards sind etwa dazwischen. Es macht also keinen Sinn, die SDCarte zu schonen in dem die Logs auf USB landen. Es hat sogar den Nachteil, das bei USB-Problemen der Pi (bzw. FHEM) ein gaaans großes Problem hat und damit die Systemsicherheit sich verringert.
Habe schon länger mit SDCards zu tuhen, vor Pi Zeiten, also Fotografie. Die Meisten Fehler von SDCards war im Kontroller der Kamera zu suchen (Hinweis: Nicht alle!). Umgesetzt auf dem Pi: Abschalten beim Schreibvorgang elementiert zuverlässig (und nachvolziehbar) die SDCard. Haben es testweise mal mit Freunden ausprobiert. Was eine SSD (im Dateisystem) noch verträgt, geht meistens bei USB-Sticks und SDCards daneben. Wobei diese dann nicht technisch defekt, sondern einmal neu formatieren wieder zuverlässig zu Verfügung standen.
P.S. SDCars und USB-Sticks haben (meist) kein Wear leveling, da dazu der Controller zu teuer wäre ;o)
Zitat von: Marlen am 16 August 2017, 16:29:33
Ja, wollte das schon mal testen, aber das Image von einer 32GB Karte passt nicht unbedingt wieder auf eine 32GB Karte! :o
kannst du verhindern indem du die Datenpartition der SD-Card ca. 100 mb verkleinerst (z. B. mit GParted). In dem von mir gelinkten Script gibt es eine Funktion zum Shrinken des Images. Dabei wird das "leere" Ende der SD-Card abgeschnitten. Dann sind ein paar MB Unterschied beim Wiederherstellen kein Problem. Geht mit DD genau so (Script nutzt auch DD).
Zitatkannst du verhindern indem du die Datenpartition der SD-Card ca. 100 mb verkleinerst (z. B. mit GParted). In dem von mir gelinkten Script gibt es eine Funktion zum Shrinken des Images. Dabei wird das "leere" Ende der SD-Card abgeschnitten. Dann sind ein paar MB Unterschied beim Wiederherstellen kein Problem. Geht mit DD genau so (Script nutzt auch DD).
Wo find ich das Script?
Das geht aber jetzt nicht mehr, dazu muss die SD-Karte leer sein, oder?
LG
Marlen
Zitat von: Marlen am 18 August 2017, 07:18:25
Wo find ich das Script?
Das geht aber jetzt nicht mehr, dazu muss die SD-Karte leer sein, oder?
LG
Marlen
Nein, es muss nur noch ungenutzter, somit freier Speicher verfügbar sein.
Anstatt die Log Dateien zu exportieren, würde ich lieber jede Nacht ein Backup machen. Dann ist es auch nicht so schlimm, wenn die SD Karte mal abraucht.
SD Karten Image auf neue SD -> Fhem Backup drauf = unter 30 min arbeit und alles ist wieder wie vorher.
Zitat von: Marlen am 18 August 2017, 07:18:25
Wo find ich das Script?
Das geht aber jetzt nicht mehr, dazu muss die SD-Karte leer sein, oder?
LG
Marlen
raspiBackup.sh
Script incl. Anleitung hier ... https://www.linux-tips-and-tricks.de/de/schnellstart-rbk (https://www.linux-tips-and-tricks.de/de/schnellstart-rbk) Link war in meinem ersten Post. Das Scipt selbst heißt raspiBackup.sh jedoch findest du auf der genannten Seite auch ein installer-script bzw. die Anleitung dazu.
Folgenden Punkt beachten, dann wird das Image geshrinkt ... https://www.linux-tips-and-tricks.de/de/faq#a16 (https://www.linux-tips-and-tricks.de/de/faq#a16)
Partition verkleinern geht auch bei fertiger Installation, würde aber vorher trotzdem eine Sicherung machen. Partitionen verkleinern wie gesagt mit GParted. Da gibt es auch eine Live-CD, dann bruachst du keinen Linux-Rechner dazu. http://gparted.org/livecd.php (http://gparted.org/livecd.php)
Wobei man auch ein image (auf einem Linux-Rechner) per ro mounten kann und somit auch verkleinern kann ...
hi,
wie richte ich denn das raspi backup oder fhem backup auf ein nas ein? (komme von windows und habe da keinen plan)
Ich habe auch schon überlegt ob es nicht eine kleine Windows basierte Box für FHEM als server gibt. Hat das jemand oder nutzt hier jeder Pi?
Zitat von: screetch82 am 18 August 2017, 14:58:20
wie richte ich denn das raspi backup oder fhem backup auf ein nas ein? (komme von windows und habe da keinen plan)
Ich habe auch schon überlegt ob es nicht eine kleine Windows basierte Box für FHEM als server gibt. Hat das jemand oder nutzt hier jeder Pi?
Ich habe es so umgesetzt:
http://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/ (http://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/)
Wobei genau folgende Zeile ALLE Sicherheitseinstellung durch den Lauf als User fhem auslöscht:
fhem ALL=(ALL) NOPASSWD: ALL
Wenn ein (böser) Hacker dieses liest, graucht er 5 Minuten um das System zu übernehmen .. davon 4,5 Minuten, um sicherzugehen, das er keinem Scherz aufliegt ....
Besser also, dieses Backup nicht per fhem,. sondern per eigenem User zu machen!