Hi zusammen,
ich habe es durch die "save as" Funktion unter "edit files" geschafft, meine 99_myUtils.pm zu löschen bzw. zu leeren...
Ein nur wenige Tage altes komplettes Image meiner VM (Proxmox) existiert zwar. Da es aber noch keinen Neustart gab, frage mich, ob ich den Inhalt der Datei nicht einfach aus dem laufen Betrieb wiederherstellen kann?
Da die Funktionen ja alle noch zur Verfügung stehen, müsste der Code doch eigentlich irgendwo noch schlummern? Ich kenne mich mit Perl und Caching etc. leider null aus.
Da merkt man mal wieder, was einem fehlt. fhem.cfg und save habe ich täglich separat gesichert. Aber keine nicht die 99_myUtils.
So etwas hatten wir hier mal vor 2 Jahren, ich glaube es war Jörg der damals Code dafür lieferte. HermannJ.
Vielleicht findest du was.
tar cvfz fhem_${DATUM}.tgz --exclude "*.zip" --exclude "*restoreDir*" --exclude "*.log" --exclude "*backup*" /opt/fhem/* >/dev/null 2>&1
... täglich!
Kostet Speicher noch viel Geld? Nein!
"Was Du nicht gesichert hast, kannst Du getrost als gelöscht betrachten."
Sorry, aber in diesem Zusammenhang sollten Leser dieses auch lesen.
Ich drücke die Daumen, dass das Wiederherstellen weniger aufwändig ist als Restore plus erneutes Coden.
Grüße
Zitat von: CoolTux am 12 November 2021, 21:34:50
So etwas hatten wir hier mal vor 2 Jahren, ich glaube es war Jörg der damals Code dafür lieferte. HermannJ.
Vielleicht findest du was.
Stimmt, auf die Idee bin ich nicht gekommen, dass schon einmal jemand anderes so einen Mist gebaut hat. Falls du [url title="diesen Beitrag"]https://forum.fhem.de/index.php/topic,110530.msg1046326.html#msg1046326[/url] meinst, den Code hattest Du sogar geliefert. :)
Allerdings über die Funktionsnamen da ranzukommen ist ein schwerlicher Weg.
Aber egal, ich konnte meine wenige Tage alte LXC Backup Datei ohne Komplettrestore einigermaßen einfach öffnen bzw. entpacken mit Peazip und 7Zip und die 99_myUtils.pm rausholen. Hoch lebe ein Backup.
Aber: Aus meiner Sicht ist die Funktion "save as" dann doch wenig robust. Ich ging davon aus, dass "save as" eine weitere Datei mit dem dort gewählten Dateinamen erstellt. Habe aber versehentlich einen ungültigen Dateinamen angegeben (99_myUtils.
js), überschrieben wurde aber die 99_myUtils.
pm mit dem aktuellen (leeren) Inhalt.
Gut das Du es retten konntest. Und nun weißt Du auch das ein tägliches Backup sind macht. Ich nutze den proxmox Backup Server dafür.
Zitat von: alanblack am 12 November 2021, 21:53:32
tar cvfz fhem_${DATUM}.tgz --exclude "*.zip" --exclude "*restoreDir*" --exclude "*.log" --exclude "*backup*" /opt/fhem/* >/dev/null 2>&1
... täglich!
Kostet Speicher noch viel Geld? Nein!
"Was Du nicht gesichert hast, kannst Du getrost als gelöscht betrachten."
Sorry, aber in diesem Zusammenhang sollten Leser dieses auch lesen.
Ich drücke die Daumen, dass das Wiederherstellen weniger aufwändig ist als Restore plus erneutes Coden.
Grüße
Wie gesagt, ich sichere die fhem.cfg und state File nach jeder Änderung. Die myUtils hatte ich nur leider nicht auf dem Schirm, ändere sie aber inzw. auch recht selten. Alle paar Wochen Imagebackup insbesondere vor Fhem-Updates haben mir nun den A... gerettet. Also alles gut. Übertreiben will ich's ja auch nicht. Auch wenn ich noch 76 GB frei habe auf der internen SSD und 4 TB auf dem gemounteten NAS Share..
Aber Dein Backup Kommando ist echt elegant und erstellt nicht zu große Backups.
Zitat von: CoolTux am 12 November 2021, 22:09:34
Gut das Du es retten konntest. Und nun weißt Du auch das ein tägliches Backup sind macht. Ich nutze den proxmox Backup Server dafür.
Der kostet aber Geld, oder?
Zitat von: FHEMAN am 12 November 2021, 22:11:17
Wie gesagt, ich sichere die fhem.cfg und state File nach jeder Änderung. Die myUtils hatte ich nur leider nicht auf dem Schirm, ändere sie aber inzw. auch recht selten. Alle paar Wochen Imagebackup insbesondere vor Fhem-Updates haben mir nun den A... gerettet. Also alles gut. Übertreiben will ich's ja auch nicht. Auch wenn ich noch 76 GB frei habe auf der internen SSD und 4 TB auf dem gemounteten NAS Share..
Aber Dein Backup Kommando ist echt elegant und erstellt nicht zu große Backups.
Der kostet aber Geld, oder?
Nein das ist auch Lizenzkostenfrei für Privatleute zu bekommen.
Zitat von: FHEMAN am 12 November 2021, 22:11:17
Übertreiben will ich's ja auch nicht. Auch wenn ich noch 76 GB frei habe auf der internen SSD und 4 TB auf dem gemounteten NAS Share..
Aber Dein Backup Kommando ist echt elegant und erstellt nicht zu große Backups.
Auch wenn das Backup Kommando recht schlanke Backups liefert, ist das Restore schnell gemacht und liefert ein vollständig laufendes FHEM.
Aber ich behalte natürlich nicht alle Backups. Einmal pro Woche kopiere ich das letzte auf meinen externen Webserver. Lokal lösche ich alles, das älter als 60 Tage ist.
Grüße
Zitat von: CoolTux am 12 November 2021, 22:16:48
Nein das ist auch Lizenzkostenfrei für Privatleute zu bekommen.
Dann schaue ich mir das auf jeden Fall mal an!
Zitat von: alanblack am 12 November 2021, 22:29:21
Auch wenn das Backup Kommando recht schlanke Backups liefert, ist das Restore schnell gemacht und liefert ein vollständig laufendes FHEM.
Aber ich behalte natürlich nicht alle Backups. Einmal pro Woche kopiere ich das letzte auf meinen externen Webserver. Lokal lösche ich alles, das älter als 60 Tage ist.
Grüße
Ich habe es jetzt für mich angepasst und einen täglichen Job definiert. Nachdem ich 2 Jahre alte cfg und save Backups gelöscht habe und sinnige Exclusions integriert habe, bin ich von 1,3 GB auf 30 MB runter (beides komprimiert), perfekt!
Auch wenn ich an den automatischen Aufräumjobs noch feilen muss.
Hat sich gelohnt, mal wieder an die Backup Thematik "erinnert" zu werden...
Zitat von: FHEMAN am 12 November 2021, 23:04:33
Auch wenn ich an den automatischen Aufräumjobs noch feilen muss.
# Alte Dateien im Backup nach 60 Tagen loeschen
find /<backup-pfad>/fhem* -mtime +60 -exec rm -f {} \;
Zitat
Hat sich gelohnt, mal wieder an die Backup Thematik "erinnert" zu werden...
"Ein Backup ist nur so gut wie das Restore dazu."
Mein Rat: nimm Dir eine ruhige Stunde, fahr den FHEM-raspi runter, nimm die SD-Karte/HDD/SDD weg und nimm eine neue.
Wie lange brauchst DU, bis FHEM wieder läuft quasi wie vorher?
Grüße
Zitat von: alanblack am 12 November 2021, 23:35:35
# Alte Dateien im Backup nach 60 Tagen loeschen
find /<backup-pfad>/fhem* -mtime +60 -exec rm -f {} \;
Das baue ich gleich mit in mein daily at ein ;)
Zitat
"Ein Backup ist nur so gut wie das Restore dazu."
Mein Rat: nimm Dir eine ruhige Stunde, fahr den FHEM-raspi runter, nimm die SD-Karte/HDD/SDD weg und nimm eine neue.
Wie lange brauchst DU, bis FHEM wieder läuft quasi wie vorher?
Nur ein Klick und keine 10 Minuten. Wenn ein Backup erstellt wurde.. ;)
Zitat von: FHEMAN am 12 November 2021, 20:49:16
ich habe es durch die "save as" Funktion unter "edit files" geschafft, meine 99_myUtils.pm zu löschen bzw. zu leeren...
Zitat von: FHEMAN am 12 November 2021, 22:03:36
Aber: Aus meiner Sicht ist die Funktion "save as" dann doch wenig robust. Ich ging davon aus, dass "save as" eine weitere Datei mit dem dort gewählten Dateinamen erstellt. Habe aber versehentlich einen ungültigen Dateinamen angegeben (99_myUtils.js), überschrieben wurde aber die 99_myUtils.pm mit dem aktuellen (leeren) Inhalt.
Das kann ich nicht nachvollziehen. Ich habe gerade folgendes gemacht:
- "Edit files" für meine 99_myUtils.pm ausgeführt
- den Dateinamen auf 99_myUtils.js geändert
- "Save as" geklickt
- Das Speichern unter dem Namen 99_myUtils.js wurde korrekt bestätigt
Ergebnis dieser Aktion:
- im Verzeichnis ./FHEM/ befindet sich die unveränderte Datei 99_myUtils.pm
- im Verzeichnis ./www/pgm2 befindet sich die neu angelegte Datei 99_myUtils.js mit dem korrekten Inhalt
Um das zu verstehen, muss man wissen, dass "Edit files" anhand einer vorhandenen Liste von Dateiendungen automatisch entscheidet, wohin eine Datei gespeichert wird.
Schau doch mal nach, ob es in Deinem Verzeichnis ./www/pgm2/ nicht auch plötzlich eine Datei 99_myUtils.js gibt :)
...
In ./www/pgm2 liegt tatsächlich die JS-Datei!
Ich habe gerade versucht, meine Schritte noch einmal zu reproduzieren. Es ist grundsätzlich so, wie Du es beschreibst.
Vermutlich habe ich nach Vergabe das Dateinamens unter "save as" einfach ENTER gedrückt - und damit den save (only) Button getriggert.
Ich erinnere mich nämlich an eine Fehlermeldung - und die (Codeanalyse) folgt sicher nur, wenn es sich um eine .pm Datei handelt.
Da wir schon Backupcodes posten, der Vollständigkeit halber hier noch mein Backup-Notify, das nach jedem Speichern die fhem.cfg und fhem.save und 99_myUtils.pm wegsichert. (Den Ursprung fand ich mal hier im Forum):
global:SAVE|global:FILEWRITE.*99_myUtils.pm {
my $now = TimeNow();
$now =~ s/ /_/g;
if ($EVENT =~ "SAVE") {
qx("cp $attr{global}{configfile} /opt/fhem/backup/fhem.cfg.bck.$now");
qx("cp $attr{global}{statefile} /opt/fhem/backup/fhem.save.bck.$now");
Log 3, "Backed up fhem.cfg + fhem.save";
} elsif ($EVENT =~ "FILEWRITE") {
qx("cp /opt/fhem/FHEM/99_myUtils.pm /opt/fhem/backup/99_myUtils.pm.bck.$now");
Log 3, "Backed up 99_myUtils.pm";
}
}
(Ich verwende anstelle von qx jedoch eine non-blocking Variante)
haarsträubend...
Bzgl. fhem.cfg macht das fhem doch selber automatisch (oder?)...
Ansonsten reicht mir fhem backup.
Das ist schnell angeworfen und da ist ALLES drin was ich brauche (weil ich alles was ich so für fhem brauche [auch] unter /opt/fhem habe und das wird ja komplett gesichert)...
...ja, evtl. mehrfach auch "unveränderliche" Sachen...
...aber lieber 3 Dateien (unnötig) zu viel als nachher ein Gejammer, wnn doch was fehlt...
Damit ziehe ich nun schon jahrelang von Plattform (HW udn OS) zu Plattform...
Weil es damit egal ist "wo man herkommt" und "wo man hingeht" :)
Gruß, Joachim
Da wir schon mal bei Backup sind, hoffentlich speichert Ihr die Backup auch "Extern", also nicht auf dem gleichen System. Sonst wird euch ein "Plattenschaden" alles zerstören (ja auch SSDs **) könne per Hardware und/oder Software zerstört *) werden)
Hinweise:
*) zerstört nicht immer im Physikalischen Sinne, sondern auch eine Logische, d.h. unlesbares Dateisystem. Also wirklich im Sinne: Alles Weg .. egal wer der Übeltäter wird
**) Hatte sogar schon beruflich damit zu tun. Die "Offiziellen" Hoster sprechen aktuell im professionellen Umfeld SSD und HDD die gleiche Haltbarkeit zu.
Zitat von: Wernieman am 13 November 2021, 12:24:20
Da wir schon mal bei Backup sind, hoffentlich speichert Ihr die Backup auch "Extern", also nicht auf dem gleichen System.
Voellige Zustimmung. Und wenn wir schon bei Backup sind, hier mein Werkzeug auf einem separaten Raspberry mit dem ich sehr zufrieden bin: "rsnapshot". Das ist fuer TutNix-Einsteiger sicher anspruchsvoll, mit Anleitungen wie in diesem Artikel aber nicht unmoeglich. Der Anmerkung des Autors "Sog. Pull-Backups über SSH sind durchaus möglich, dass heißt einen Remote-Server lokal über SSH zu sichern"[sic] schliesse ich mich nicht an; fuer mich ist das der normale Einsatzfall.
https://www.thomas-krenn.com/de/wiki/Backup_unter_Linux_mit_rsnapshot
Ich sichere damit seit einem Dreivierteljahr stuendlich diverse Pfade von meinem fhem-Rechner, meinem Linux-Desktop-Rechner und dem Windows-Rechner meiner Frau auf einer 1 TB SSD. Der Platzbedarf auf der Sicherungsplatte ist dank der Hardlinks moderat.
root@rp42:~# ls -t /rsnapshot
hourly.0 hourly.4 hourly.8 hourly.12 hourly.16 hourly.20 daily.0 daily.4 weekly.1 monthly.1 monthly.5
hourly.1 hourly.5 hourly.9 hourly.13 hourly.17 hourly.21 daily.1 daily.5 weekly.2 monthly.2 monthly.6
hourly.2 hourly.6 hourly.10 hourly.14 hourly.18 hourly.22 daily.2 daily.6 weekly.3 monthly.3 monthly.7
hourly.3 hourly.7 hourly.11 hourly.15 hourly.19 hourly.23 daily.3 weekly.0 monthly.0 monthly.4 monthly.8
root@rp42:~# ls /rsnapshot/hourly.0
bathdesk rp44 localhost beate
Das Ganze ist dem Zugriff des zu sichernden Rechners entzogen, sehr zuverlaessig und vor allem sind die gesicherten Daten einfach zu restaurieren.
Gruss Helmut
Gibt einige Produkte wie rsnapshot, welche die Hardlinkfähigkeit von rsync ausnutzen. Ich verwende hier seit Ewigkeiten dirvish, habe sogar schon beruflich damit Backupsystem im TB-Bereich aufgebaut.
Sind alle im Prinzip "nur" Front-Ends von rsync und können damit auf allen Wegen sichern, welche auch rsyn kann.
Zitat von: Wernieman am 14 November 2021, 10:10:06
Ich verwende hier seit Ewigkeiten dirvish
Das kannte ich nicht, danke fuer den Hinweis. Es sieht auch interessant aus. Ich sehe bei beiden Produkten leichte Vor- und Nachteile. Daher werden wir wohl beide bei unserer Wahl bleiben. Einzig rdiff-backup habe ich sehr schnell verworfen.
Zitat von: Wernieman am 14 November 2021, 10:10:06
Sind alle im Prinzip "nur" Front-Ends von rsync
Das
nur hast Du zu Recht in Anfuehrungszeichen gesetzt ;-)
Gruss Helmut
Zitat von: Wernieman am 13 November 2021, 12:24:20
Da wir schon mal bei Backup sind, hoffentlich speichert Ihr die Backup auch "Extern",
Na logisch, immer für die letzten 30 Tage in einem S3-Bucket bei AWS :)
32 1 * * * udo /home/udo/fhembackup/fhembackup
#!/bin/sh
cd ~/fhembackup
find ./*.tar.gz -type f -mtime +30 -delete
backname=`date "+backup_fhemrpi3_%Y%m%d-%H%M.tar.gz"`
tar -czvf $backname /opt/fhem/sqldb/
aws s3 sync . s3://<s3_bucket_name>/<folderName> --delete