efa 2.0 beta: Möglichkeit für automatische Backups?

[skc-andreas]

Bei efa2dev (1.9.0) gab es die Möglichkeit, in der Konfiguration unter "Allgemein" / "Backup" neben dem Backup-Verzeichnis auch einzustellen, wann automatisch ein Backup erstellt wird, nämlich:
* Backup bei jedem Speichern
* Backup beim ersten Speichern jeden Monat
* Backup beim ersten Speichern jeden Tag
* Backup beim Konvertieren

Bei efa 2.0 beta kann man unter dem Punkt "Backup" / "Backup erstellen" zwar das Backup-Verzeichnis angeben, ebenso was gesichert werden soll (Projekt und Konfigurationsdatei), und dann manuell ein Backup erstellen lassen. Es gibt aber anscheinend keine Möglichkeit, automatisch bei bestimmten Ereignissen ein Backup erstellen zu lassen. Auf jeden Fall bin ich bisher nicht fündig geworden...

Das automatische tägliche Backup hat uns im letzten Oktober nach dem "Abrauchen" der Festplatte unseres efa-Laptops das "efa-Leben" gerettet, weil wir die Daten regelmäßig auf einen USB-Stick gesichert hatten.

Eine entsprechende Funktionalität sollte es auch unbedingt in efa 2.0 wieder geben.

efa 2.0 beta (1.9.9_28) / Ubuntu 10.04 LTS / Java 1.6.0_20

[nick]

Hallo Andreas,

ich habe den Beitrag mal ins Forum Diskussion verschoben, weil hier erstmal kein Fehler im eigentlichen Sinn vorliegt.

efa1 (bis 1.9.0) hat beim Speichern einer Datenliste die vorherige Version in einen konfigurierbaren Backup-Ordner verschoben - wahlweise bei jedem Speichern, und/oder täglich, monatlich, und beim Konvertieren. Diesen Backup-Ordner konnte man auf einen separaten Datenträger legen, z.B. eine zweite Festplatte oder einen USB-Stick, und somit im Falle eines Datencrashes eine vorherige Version der Daten retten.

In efa2 funktioniert das etwas anders. efa2 schreibt die Dateien im Hintergrund (entgegen efa1), hat dafür aber ein Journal, das synchron mit jeder Änderung auf Platte geschrieben wird. Von jeder Datei behält efa die vorherige und vorvorherige Version. Im Falle eines Crashes oder Stromausfalls kann efa, falls das die zuletzt geschriebenen Daten zerstört haben sollte, den letzten Stand (i.d.R. ohne jeglichen Verlust von Änderungen) automatisch wiederherstellen. Dazu ist noch nichtmal der Eingriff des Administrators nötig. Du kannst das gerne mal testen, indem Du eine Datei verstümmelst und efa dann startest.

Allerdings liegen diese Daten (d.h. die vorherigen Kopien und Journals) bei efa2 alle im selben Verzeichnis. Gegen einen Plattencrash hilft das also nicht.

Darüber hinaus bietet efa2 die Möglichkeit, Backups zu erstellen (das oben beschriebene sind keine Backups, sondern ein Mechanismus zur Crash Recovery). Backups können interaktiv erstellt werden - auch Remote. Außerdem hat efa2 ein Command Line Interface (CLI), über das sich Backups auch skriptgesteuert triggern lassen. Mit dem Kommando

Code: Alles auswählen

./efaCLI.sh admin@localhost/projectname -cmd "backup create all /my/directory"

erstellt efa ein Backup aller Daten des Projekts projectname sowie der Konfiguration im Verzeichnis /my/directory (analog mit efaCLI.bat unter Windows).
Um nicht interaktiv das Admin-Paßwort eingeben zu müssen, kann das Paßwort per Kommandozeile mitgegeben werden (admin:password@localhost...) - nicht empfohlen, oder besser - in einer Credentials-Datei ablegegt werden. Standardmäßig wertet efa die Datei .efacred im Home Directory des Benutzers aus (z.B. /home/username/.efacred unter Linux). In diese Datei muß in einer Zeile

Code: Alles auswählen

admin password

stehen.

efaLive integriert das Backup von efa und ermöglicht, z.B. beim EInstecken eines USB-Sticks ein solches Backup auf dem Stick zu erzeugen. Außerdem kann efaLive durch einen Cron-Job gesteuert zu beliebigen Zeiten - z.B. einmal täglich - solch ein Backup erzeugen, und bei Bedarf (und Internetanbindung) auch per email verschicken. Natürlich kann man sich einen solchen Cron-Job auch ohne efaLive basteln, oder diese Funktionalität auch auf anderen Betriebssystem realisieren.

Was efa2 bislang nicht tut:

• efa2 hat keinen Job Scheduler, über den sich periodische Aufgaben, wie z.B. das Erstellen eines Backups, aus efa heraus konfigurieren lassen. Zur Zeit überläßt efa das dem Benutzer, bzw. efaLive.
• efa2 erstellt die Journals und Kopien zur Crash Recovery im selben Verzeichnis wie die Live-Daten. Die Angabe eines anderen Verzeichnisses (auf einem anderen Datenträger) ist nicht möglich.

Für den ersten Punkt sehe ich im Augenblick nicht so dringenden Handlungsbedarf, da efa2 hier alle Schnittstellen bietet, um die Aufgabe zu lösen, und mit efaLive auch ein Angebot da ist, in dem das bereits alles integriert ist.

Über den zweiten Punkt werde ich nochmal nachdenken. Ein alternatives Verzeichnis für die Journals etc. möchte ich ungerne anlegen, weil dann wieder die Gefahr besteht, daß ein Benutzer dort aus Versehen oder mit Absicht drin rumpfuscht. Eventuell könnte ich in efa2 aber ein Mirroring einbauen - daß efa optional alle Daten doppelt schreibt - einmal im Verzeichnis data, und einmal an einem beliebige, konfigurierbaren Ort. Letzterer könnte auf einem separaten Datenträger liegen. efa würde in dem Fall dort nur schreiben, und niemals lesen - d.h. ein automatisches Recovery würde immer nur von dem Primärverzeichnis erfolgen. (Möglicherweise könnte man auch nur die aktuellen Kopien dort schreiben, und auf die Journals etc. verzichten...).

Feedback und Meinungsäußerungen willkommen.

Gruß,
Nicolas

[skc-andreas]

Hallo Nicolas, (und alle anderen interessierten Leser)

mit deinem im letzten Absatz beschriebenen Vorschlag, die Daten für das Crash Recovery doppelt zu speichern, kann ich mich anfreunden. Das dürfte von der Umsetzung her vermutlich auch nicht so aufwändig sein.

Nach einem Plattencrash müssten man nach der Installation von Betriebssystem und efa auf einer neuen Festplatte nur das Spiegelverzeichnis zurück ins Primärverzeichnis ("data"?) kopieren und anschließend efa neu starten und alles ist wieder "schön"?

Wir verfahren bzgl. Datensicherheit derzeit so, dass wir mit dem von uns eingesetzten efa 1.9.0 im Bootshaus täglich und monatlich Sicherungskopien auf einem externen Datenträger (USB-Stick) automatisch erstellen lassen und zusätzlich ein-/zweimal pro Monat manuell Kopien auf einem weiteren externen Datenträger erstellen, welcher nicht im Bootshaus gelagert wird. So sind wir einerseits gegen Ausfall der Festplatte gesichert (max. Datenverlust: Fahrten eines Tages) und andererseits gegen Totalverlust des efa-Laptops (z.B. durch Diebstahl oder Brand).

Eine manuelle Datensicherung kann man mit efa2_beta bereits über die Backup-Funktion erstellen. Nur für die regelmäßige, automatische Datensicherung auf einen anderen Datenträger fehlt bisher in efa2 eine Lösung, die meines Erachtens aber wichtig für den produktiven Betrieb im Bootshaus ist. Hier kann man derzeit nur mit Betriebssystem-Bordmitteln für eine automatische Datensicherung sorgen.

Viele Grüße
Andreas

[florian]

Hallo,

ist teste grade efa2 auf meinem Windows-Rechner und wollte mal das Backup ausprobieren.
Nach diesem Aufruf (PROJEKT ist ersetzt mit existierendem Projektnamen):

Code: Alles auswählen

efaCLI.bat admin@localhost/PROJEKT -cmd "backup create all d:\Temp\efa2_backup"

erhalte ich diese Fehlermeldung:

Code: Alles auswählen

INFO    - EVT001 - PROGRAMMSTART
INFO    - INF002 - Version efa: 1.9.9_30 -- Java: 1.6.0_29 (JVM 20.4-b02) -- OS: Windows 7 6.1
INPUT   - CLI003 - Password for admin:
INFO    - CLI001 - Connecting as admin to localhost:3834 ...
ERROR   - RMT006 - configuration.efa2config: efaRemote-Anfrage IsObjOpen fehlgeschlagen: Connection refused: connect (Code -1)
ERROR   - COR001 - PROGRAMMENDE (Error Code 1)
Der Befehl "S" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.

Ist das ein Windows-Problem bzw. Bug in den batch-files?

Ist efaCLI dafür vorgesehen, auch aufgerufen zu werden, wenn efa bereits läuft? Habe es einfach mal ausprobiert und bekomme eine längere Ausgabe, wobei zunächst "Starte Wiederherstellung von Projekt" abläuft, zum Ende dann "Backup mit 10 Fehlern abgeschlossen."

Nutzt efaLive in den cronjobs auch diese Art von Backup? Im Boothaus läuft efa (z.Zt. noch efa1) unter Linux und mich interessiert, wie die cronjobs für regelmäßige Backups aussehen müssen.

Viele Grüße
Florian

[nick]

Hallo!

mit deinem im letzten Absatz beschriebenen Vorschlag, die Daten für das Crash Recovery doppelt zu speichern, kann ich mich anfreunden. Das dürfte von der Umsetzung her vermutlich auch nicht so aufwändig sein.

Nach einem Plattencrash müssten man nach der Installation von Betriebssystem und efa auf einer neuen Festplatte nur das Spiegelverzeichnis zurück ins Primärverzeichnis ("data"?) kopieren und anschließend efa neu starten und alles ist wieder "schön"?

Genau so! Ich habe das mal eben hingebastelt in Version 1.9.9_31. Den Test überlasse ich Dir...
In der efa-Konfiguration kannst Du jetzt ein Spiegelverzeichnis angeben. Wenn dort etwas eingetragen ist, dann erstellt efa dort bei jedem Schreiben dieselbe Verzeichnis- und Dateistruktur wie im Nutzerdaten-Verzeichnis von efa (inkl. der Sicherungsdateien für Recovery, aber ohne die Journals). Das bezieht sich auf sämtliche Daten, die efa schreibt, ausgenommen Logfiles, Backups und sonstige Ausgabedaten. Mit anderen Worten: Konfiguration und sämtliche Projektdaten.

Eine manuelle Datensicherung kann man mit efa2_beta bereits über die Backup-Funktion erstellen. Nur für die regelmäßige, automatische Datensicherung auf einen anderen Datenträger fehlt bisher in efa2 eine Lösung, die meines Erachtens aber wichtig für den produktiven Betrieb im Bootshaus ist. Hier kann man derzeit nur mit Betriebssystem-Bordmitteln für eine automatische Datensicherung sorgen.

Ja. Aber im Gegensatz zu efa1 bietet efa2 immerhin eine Schnittstelle, mit der man das mit Betriebssystemmitteln machen kann. Ich habe heute schonmal ein wenig nachgedacht, wie ich quasi ein cron für efa bauen könnte. Idealerweise sollte der generisch sein, d.h. zu beliebigen Zeiten ein Kommando ausführen können, das z.B. identisch mit den Kommandos des CLI ist. Dann könnte man den benutzen, um periodisch Backups zu erstellen, Statistiken zu erstellen, oder was auch immer das CLI so unterstützt. Wäre schick - aber wohl erst nach Version 2.0.

ist teste grade efa2 auf meinem Windows-Rechner und wollte mal das Backup ausprobieren.
Nach diesem Aufruf (PROJEKT ist ersetzt mit existierendem Projektnamen):

Code: Alles auswählen

efaCLI.bat admin@localhost/PROJEKT -cmd "backup create all d:\Temp\efa2_backup"

erhalte ich diese Fehlermeldung:
...
Ist das ein Windows-Problem bzw. Bug in den batch-files?

Oops... Das mit dem S ist falsch geschrieben ist ein Windows-Bug. Da habe ich wohl mal in der Batchdatei SHIFT-S statt CTRL-S gedrückt...
Das andere, siehe unten.

Ist efaCLI dafür vorgesehen, auch aufgerufen zu werden, wenn efa bereits läuft?

Ja, das hatte ich vergessen zu erwähnen. Das CLI funktioniert ausschließlich, wenn efa bereits läuft, da es sich als Client an efa (Server) connected. Und es soll ja z.B. auch cron-gesteuert eingesetzt werden können - das macht nur Sinn, wenn es parallel laufen kann. Außerdem hat das viele schicke Nebeneffekte - Du kannst so z.B. auch von zu Hause per CLI ein Backup aus dem Bootshaus ziehen, oder sogar ein Backup einer Datenbank, falls efa die Daten in der Datenbank ablegt (kann efa heute noch nicht, aber bald).

Habe es einfach mal ausprobiert und bekomme eine längere Ausgabe, wobei zunächst "Starte Wiederherstellung von Projekt" abläuft, zum Ende dann "Backup mit 10 Fehlern abgeschlossen."

Ein Fehler, den ich mit der Crash Recovery eingebaut habe. Manchmal frage ich mich, ob ich eigentlich mehr Fehler behebe als ich neu programmiere, oder umgekehrt?! Naja, ist in 1.9.9_31 gefixed.

Nutzt efaLive in den cronjobs auch diese Art von Backup? Im Boothaus läuft efa (z.Zt. noch efa1) unter Linux und mich interessiert, wie die cronjobs für regelmäßige Backups aussehen müssen.

efaLive 2.0 wird mit efa 2.0 cron-Jobs nutzen, um mit dem CLI Backups zu erstellen. EIn einfacher Eintrag in der Crontab, der efaCLI so aufruft, wie Du es auf der Kommandozeile auch tun würdest, plus vielleicht Ausgabeumlenkung, sollte es tun. Wie in meinem vorherigen Beitrag beschrieben natürlich mit Credentials-Datei - sonst bleibt das CLI bei der Paßworteingabe hängen.

Gruß,
Nicolas

[skc-andreas]

Hallo Nicolas,

ich habe das neue Feature, dass die Datenänderungen optional in ein weiteres Verzeichnis gespiegelt werden können, gleich mal ausprobiert - und es funktioniert so weit!

Allerdings werden dort nur die Datenänderungen gespeichert, d.h. man muss vor der Nutzung des Spiegel-Verzeichnisses die bisherigen Daten aus dem efa-Datenverzeichnis ("data") in das Spiegelverzeichnis kopieren. Ansonsten kann man im Fall eines Festplatten-Crashes nicht einfach den Inhalt des Spiegel-Verzeichnisses ins efa-Datenverzeichnis einer neuen efa-Installation zurück kopieren, weil dann evtl. einige Dateien fehlen.

Das Gute ist jedoch, dass die Daten im Unglücksfall bis kurz vor Exitus der Festplatte (und Absturz des Betriebssystems) ins Spiegelverzeichnis kopiert werden, ein möglicher Datenverlust also denkbar klein sein wird (max. die aktuell eingegebene Fahrt).

Was diese Variante der automatischen Datensicherung gegenüber der von efa1 nicht bietet, ist, dass man auf einen Datenstand zu einem bestimmten Datum zurückgehen kann. Das ist aber denke ich zu verschmerzen. Schließlich gibt es dafür die manuellen Backups und die Logfiles.

Vielen Dank für die schnelle Umsetzung!

Viele Grüße
Andreas

P.S.: Schön finde ich übrigens auch, dass bei jedem Online-Update auch automatisch ein Backup der Daten erstellt wird.

[nick]

Hallo Andreas,

ich habe das neue Feature, dass die Datenänderungen optional in ein weiteres Verzeichnis gespiegelt werden können, gleich mal ausprobiert - und es funktioniert so weit!

Allerdings werden dort nur die Datenänderungen gespeichert, d.h. man muss vor der Nutzung des Spiegel-Verzeichnisses die bisherigen Daten aus dem efa-Datenverzeichnis ("data") in das Spiegelverzeichnis kopieren. Ansonsten kann man im Fall eines Festplatten-Crashes nicht einfach den Inhalt des Spiegel-Verzeichnisses ins efa-Datenverzeichnis einer neuen efa-Installation zurück kopieren, weil dann evtl. einige Dateien fehlen.

Ja, da hast Du Recht. Gestern war es schon zu spät, da war ich müde und hatte ich keine Lust weiter darüber nachzudenken, ob und wie ich das noch verbessern könnte. Aber jetzt habe ich es so erweitert, daß efa beim Öffnen einer Datei schaut, ob es schon eine Kopie im Spiegelverzeichnis gibt - und falls nicht gleich einer erstellt. Da bei jedem Öffnen eines Projekts alle Dateien geöffnet werden, passiert das also bei jedem Öffnen des Projekts. Wenn Du also im laufenden Betrieb ein (neues) Spiegelverzeichnis konfigurierst, liegen die Daten dort spätestens nach dem nächsten Start von efa. [Kommt mit 1.9.9_32 - in den nächsten Stunden.]

Falls Deine Platte noch früher abraucht, hast Du einfach mal Pech gehabt...

Das Gute ist jedoch, dass die Daten im Unglücksfall bis kurz vor Exitus der Festplatte (und Absturz des Betriebssystems) ins Spiegelverzeichnis kopiert werden, ein möglicher Datenverlust also denkbar klein sein wird (max. die aktuell eingegebene Fahrt).

Genaugenommen, maximal die letzten 10 Sekunden. Für noch mehr Sicherheit, müßte ich auch die Journals dort speichern - das habe ich aber gestern nicht mehr geschafft zu implementieren, und weiss auch nicht, ob das nötig ist. Denn wenn die primäre Platte kaputt geht, d.h. Schreibfehler liefert, stirbt ja nicht gleich efa. Der Plattenfehler wirkt sich vermutlich erst beim nächsten Start des Rechners fatal aus, aber zuvor wurde i.d.R. efa und das OS noch ganz normal beendet, und somit alle Daten auf die Spiegelplatte geschrieben. Ein Szenario, in dem die primäre Platte stirbt und gleich den ganzen Rechner mit sich reißt (und somit die Änderungen der letzten 10 Sekunden), scheint mir recht unwahrscheinlich. (Deutlich unwahrscheinlicher als ein recht wahrscheinlicher Plattencrash.)

Was diese Variante der automatischen Datensicherung gegenüber der von efa1 nicht bietet, ist, dass man auf einen Datenstand zu einem bestimmten Datum zurückgehen kann. Das ist aber denke ich zu verschmerzen. Schließlich gibt es dafür die manuellen Backups und die Logfiles.

Das bietet auch efa1 nur sehr begrenzt, und auch nicht konsistent. efa speichert nicht täglich oder monatliche die aktuelle Version der Datei im Backup-Verzeichnis, sondern die vorherige. Wenn Du also am 1.3. und am 15.4. die Datei veränderst, ist Deine "April-Sicherung" auf dem Stand vom 1.3.

Das Spiegelverzeichnis in efa2 soll gegen einen Plattencrash schützen. Bei dem willst Du normalerweise den aktuellsten Stand wiederherstellen, nicht einen früheren. Der Usecase mit einem früheren Stand hat m.E. nichts mit einem Plattencrash zu tun, sondern ist eher eine Folge von logischer Korruption der Daten, also Software- oder Bedienfehlern. Dafuer sind die Journals da - die erlauben einen sekundengenauen Rückfall auf einen beliebigen Stand - derzeit bis maximal 3000 Änderungen zurück. Ein Recovery (bzw. Flashback, Time Machine oder wie auch immer (tm)) dieser Art habe ich zwar noch nicht implementiert, aber die Daten erlauben das (und ist geplant für > 2.0). Dafür genügt es aber aus meiner Sicht, die Daten in einem Verzeichnis zu haben - daß eine logische Korruption mit einem Plattencrash zusammenfällt, erscheint mir äußerst unwahrscheinlich.

Ein paar technische Gründe gibt es auch noch, warum ich die Journals nicht so gerne doppelt schreiben möchte (oder wenn dann doch irgendwann mal, eventuell konfigurierbar): Während das Schreiben der eigentlichen Dateien asynchron im Hintergrund erfolgt und somit keine Auswirkungen auf die Reaktionszeiten von efa hat, werden die Journals synchron geschrieben. Doppelt schreiben bedeutet also doppelte Reaktionszeit. Für ein einzelnes Update vielleicht nicht so wild, aber bei Massenupdates (z.B. Datenimport) vielleicht schon. Wenn dann das Journal noch auf einem Flash-Device liegt, das bei vielen kleinen, ungepufferten I/Os auch noch extrem schlecht performt, ist das noch schlechter für die Antwortzeiten...

Aber wie Du schon selbst geschrieben hast, ist die primäre Lösung für den Rückfall auf einen beliebigen Datenstand ohnehin das Backup. Schon jetzt kann das Erstellen eines solchen Backups automatisiert werden (cron-Job o.ä.), und ich werde auch wie bereits geschrieben drüber nachdenken, einen generellen Job-Scheduler in efa einzubauen.

Viele Grüße und danke für die Anregungen,
Nicolas

[florian]

Hallo,

ich habe nochmal das Kommando-basierte Backup ausprobiert. Ich habe testweise 2 Projekte in efa2 angelegt. Über die Kommandozeile kann ich nur ein Backup eines Projekt erzeugen, wenn dieses auch in der efa2-GUI geöffnet ist. Ist dies so gewollt?

Gibt es eigentlich schon eine Doku zu anderen Kommandozeilen-Optionen? Ich habe festgestellt, dass statt eines Verzeichnisses auch direkt ein Dateiname angegeben werden kann:

Code: Alles auswählen

efaCLI.bat admin@localhost/PROJEKT -cmd "backup create all d:\Temp\test.zip"

Denke mal, dieses Feature ist für zip-files so gewollt und ich finde es in dieser Form sehr nützlich.

Grüße
Florian

[nick]

Hallo Florian,

das CLI greift niemals direkt auf Dateien zu, sondern verbindet sich immer (remote oder lokal) an ein efa-Bootshaus. Das efa-Bootshaus agiert als Server. Der Zugriff vom CLI ist damit immer nur auf das Projekt möglich, das in efa-Bootshaus derzeit geöffnet ist. Falls Du aber z.B. mehrere efa-Bootshaus Installationen in mehreren Bootshäusern betreibst, die alle ein eigenes Projekt öffnen, kannst Du natürlich mit demselben efaCLI auf die Projekte in all diesen Bootshäusern zugreifen.

Eine Dokumentation zu den CLI-Optionen gibt es nicht , dafür fehlt mir bislang die Zeit. Aber Du bekommst zumindet die Übersicht aller Optionen mit dem Kommando help. Also z.B. backup help usw...

Gruß,
Nicolas