eigene Sicherung nur von Messwerten, Tageswerten, Monatswerten... ....

[Ihaglc]

Es gibt bei mir als Nightly User immer wieder die Notwendigkeit auf eine ältere dann noch funktionierende SW-Version zurückzufallen.
Leider gehen dann auch die aktuelleren Werte ab dem letzen GesamtBackup verloren.

Ich hätte gerne eine Funktion, wo nur die Werte mit einer eigenen Backup Funktion gespeichert und wieder hergestellt werden können, so das man im Bedarfsfall nach Rückschwenk keine Messwerte verliert und so die reine DatenSicherung nicht mit der SW Version verknüpft ist

[Thomas aus W]

Genau genommen würde es ja reichen, wenn die Log-Daten beim Wiederherstellen des Backup nicht zurück geschrieben werden, wenn das Verzeichnis schon existiert...

Edit: https://github.com/snaptec/openWB/pull/2719

bye
TW

[Ihaglc]

Vielen Dank für Deinen Lösungsvorschlag.

Was passiert aber, wenn die Datendatei selbst defekt geworden ist und erneuert werden muss?
Dann sind wir wieder am Eingangs beschriebenen Datenverlustverhalten.
Ich fände es sauberer, wenn man das Firmwaresystem sepaparat von den Messwertdaten speichern könnte.
Man könnte die Werte dann z.B per Script täglich speichern lassen.
Was halten die Anderen davon?

[Gero]

Da erinnere ich mich noch gut dran, damals zu den beginnenden Windows-Zeiten. Da waren Daten und Programme auch immer bunt gemischt, was die ganze Unixer vollkommen verständnislos zurück gelassen hat. Die waren es ja schon seit Jahr und Tag gewohnt, dass da mehrere User auf einem System gearbeitet haben und von daher die Trennung von Code und Daten seit jeher notwendig war. Windows hat dann die Userdaten irgendwann in die Benutzerprofile reingepackt, wo sie eigentlich auch nichts zu suchen hatten…

Von daher: klares Voting dafür, Daten und Coding getrennt halten!

[derNeueDet]

Hmm, macht das Backup/Recovery für den Otto Normaluser aber schwieriger zu durchschauen bzw. Sicher zu bedienen.

VG
Det

[hhoefling]

Das getrennt halten wird aber problematisch wenn das Update auch ein Update der Datenstructuren enthält.
Dann sind die "neuen" Daten für die "alten" Programm unverträglich.

[Ihaglc]

Hmm, macht das Backup/Recovery für den Otto Normaluser aber schwieriger zu durchschauen bzw. Sicher zu bedienen.

VG
Det

Das sollte eigentlich kein Problem sein und man könnte ja die Messdaten auch weiterhin mit dem Backup speichern und zusätzlich hätte man die Möglichkeit mit der Wertesicherung die alten Werte aus dem Backup zu aktualisieren.

Das getrennt halten wird aber problematisch wenn das Update auch ein Update der Datenstructuren enthält.
Dann sind die "neuen" Daten für die "alten" Programm unverträglich.

Nun das mag in einigen wenigen Fällen so sein, wo die Datenstruktur wirklich geändert wird, aber wie oft kommt das vor?
Ich denke, viel öfter müssen die User Backups einspielen und müssen dann mit dem Datenverlust leben.
Gerade wenn man eine korrupte SW hat, wäre es von Vorteil, die Werte vorher zu sichern, bevor ein Backup eingespielt wird, um danach die Werte des Backups auf den Stand bringen zu können.

[Thomas aus W]

@owbAdmin: Ich bin ein wenig entäuscht, dass ein PR nach kurzer Diskussion ohne zweites internes Review abgelehnt wird, weils dem einem Bearbeiter nicht passt.

bye
TW

[openWB]

@owbAdmin: Ich bin ein wenig entäuscht, dass ein PR nach kurzer Diskussion ohne zweites internes Review abgelehnt wird, weils dem einem Bearbeiter nicht passt.

bye
TW

Aber es gab doch sogar für dein spezielles Problem einen Lösungsweg.
Einfach vor dem Downgrade ein Backup machen, Log Dateien extrahieren und in das "alte" Backup packen. Damit dann ein Restore.
Gab es keine Änderung in der Struktur hast du alle Daten wieder vorhanden.

[LutzB]

Ich hatte in dem PR um weitere Diskussion hier im Forum gebeten. Das sollten wir dann auch machen. Der Einzeiler aus dem PR wird definitiv nicht so übernommen. Die Gründe hatte ich erläutert und eine Alternative vorgeschlagen. Also jetzt dann bitte genau beschreiben, was aktuell nicht geht und was gewünscht ist.