Version 2.4.12 Buggy (Backup)? (General)

by Martin66, Tuesday, July 10, 2018, 16:46 (2088 days ago)

Hallo,

ich habe gestern ein Update auf Version 2.4.12 durchgeführt und anschließend ein komplettes Backup erstellt. Das scheint aber buggy zu sein:

INSERT INTO acc_userdata VALUES (...

  • Die Daten zu "birthday" gehören in einfache Hochkommata, glaube ich.
  • Die beiden Felder "tou_accepted" und "dps_accepted" werden nicht gesichert.


INSERT INTO acc_entries VALUES (
Da scheint auch die Anzahl der gesicherten Felder nicht mit den vorhandenen übereinzustimmen. Wo da genau der Fehler liegt, habe ich jetzt nicht auch noch gesucht.

Martin

Avatar

Version 2.4.12 Buggy (Backup).

by Auge ⌂, Wednesday, July 11, 2018, 07:43 (2088 days ago) @ Martin66

Hallo

Danke für die Meldung.

ich habe gestern ein Update auf Version 2.4.12 durchgeführt und anschließend ein komplettes Backup erstellt. Das scheint aber buggy zu sein:

INSERT INTO [b]acc_userdata[/b] VALUES (...
  • Die Daten zu "birthday" gehören in einfache Hochkommata, glaube ich.
  • Die beiden Felder "tou_accepted" und "dps_accepted" werden nicht gesichert.

Ja, die *_accepted-Felder fehlen im Backup. Daran habe ich nicht gedacht, als ich die Felder einbaute. Was das Feld birthday betrifft, muss ich mal in die Doku schauen. Das Feld kann ja auch den Wert NULL enthalten.

INSERT INTO [b]acc_entries[/b] VALUES (

Da scheint auch die Anzahl der gesicherten Felder nicht mit den vorhandenen übereinzustimmen.

Schau ich mir an und zähle es durch.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Version 2.4.12 Buggy (Backup).

by Martin66, Wednesday, July 11, 2018, 11:37 (2087 days ago) @ Auge

Für Version 2.4.12 wäre dann ein Hotfix toll, so dass man nur eine einzelne Datei austauschen muss oder so.

Für Version 2.5 schlage ich Folgendes vor, falls das mit MYSQL geht: Den gesamten SQL-Code in der Backupdatei in eine Transaktion einbetten, sodass Löschungen zurückgenommen werden, wenn nicht alle Daten aus dem Backup eingelesen werden können.

Martin

Avatar

Version 2.4.12 Buggy (Backup).

by Auge ⌂, Wednesday, July 11, 2018, 12:07 (2087 days ago) @ Martin66

Für Version 2.4.12 wäre dann ein Hotfix toll, so dass man nur eine einzelne Datei austauschen muss oder so.

Es wird mit an Sicherheit grenzender Wahrscheinlichkeit eine Version 2.4.13 geben.

Für Version 2.5 schlage ich Folgendes vor, falls das mit MYSQL geht: Den gesamten SQL-Code in der Backupdatei in eine Transaktion einbetten, sodass Löschungen zurückgenommen werden, wenn nicht alle Daten aus dem Backup eingelesen werden können.

Da gibt es mehrere Dinge zu beachten und zu klären.

1. Nicht alle Tabellen bestehender Installationen sind von einem der Typen, die Transaktionen unterstützen. Das ließe sich aber im Updateprozess klären.

2. Von welchen Löschungen sprichst du? Beim erstellen eines Backups werden keine Datensätze gelöscht. Beim einspielen eines vorhandenen Backups werden ebenfalls keine Daten gelöscht.

Was ich mir als Problem vorstellen kann, ist der Umstand, dass PHP-Skripte in ihrer Laufzeit beschränkt sind und die Erstellung von Backups und/oder die Wiedereinspielungen von Backups unvollständig sein könnten. Da hilft aber auch keine Transaktion, solange die zugrundeliegende Technik PHP mit seinen Beschränkungen bleibt.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Version 2.4.12 Buggy (Backup).

by Martin66, Wednesday, July 11, 2018, 15:07 (2087 days ago) @ Auge

Beim einspielen eines vorhandenen Backups werden ebenfalls keine Daten gelöscht.

Das kann ich so nicht bestätigen.

Ich habe meine Echtdaten komplett gesichert und wollte sie anschließend in meiner Testumgebung einspielen. Dabei wurden die Datensätze der fehlerhaft gesicherten Tabellen gelöscht.

Das klingt für mich erst mal logisch. Wahrscheinlich wird jeder einzelne Datensatz jeweils erst gelöscht und mit den neuen Werten überschrieben, gemäß Primärschlüssel. Und wenn der neue Datensatz nicht zur Struktur passt, ist er halt weg.

Martin

Avatar

Version 2.4.12 Buggy (Backup).

by Auge ⌂, Thursday, July 12, 2018, 07:12 (2087 days ago) @ Martin66

Hallo

Beim einspielen eines vorhandenen Backups werden ebenfalls keine Daten gelöscht.


Das kann ich so nicht bestätigen.

Ich habe meine Echtdaten komplett gesichert und wollte sie anschließend in meiner Testumgebung einspielen. Dabei wurden die Datensätze der fehlerhaft gesicherten Tabellen gelöscht.

Was sind "die Datensätze der fehlerhaft gesicherten Tabellen"?

Datensätze, die schon in den Tabellen waren, bevor ein Backup eingespielt wird, sind natürlich weg. Der jeweils erste Befehl in den Backupdateien leert die Tabellen (Beispiel Einstellungstabelle: TRUNCATE TABLE mlf2_settings;), bevor die Daten des Backups eingespielt werden.

[edit]Diese Aussage widerspricht meiner Aussage im Vorposting, es würden beim zurückspielen eines Backups keine Daten gelöscht. Dort ging es mir aber um die Daten im Backup, nicht um eventuell vorhandene Daten in der Zieldatenbank. Tatsächlich bin ich davon ausgegangen, dass die Zieldatenbank leer ist.[/edit]

Das Backup erzeugt eine Kopie eines zuvor gesicherten Forums. Da haben andere Datensätze, die nicht zum "alten" Forum gehören, nichts zu suchen.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Version 2.4.12 Buggy (Backup).

by Martin66, Monday, July 16, 2018, 16:58 (2082 days ago) @ Auge

Datensätze, die schon in den Tabellen waren, bevor ein Backup eingespielt wird, sind natürlich weg

Dann sind wir uns ja einig :ok:

Avatar

Version 2.4.12 Buggy (Backup).

by Micha ⌂, Thursday, July 12, 2018, 07:26 (2087 days ago) @ Martin66

Hallo,

Für Version 2.5 schlage ich Folgendes vor

... wir sollten meiner Meinung nach überlegen, ob wir dieses Feature nicht besser entfernen sollten. Ich persönlich habe noch nie ein Backup über die Funktion erstellt sondern nutze hierfür PHPmyadmin oder ein anderes Tool, welches mir die gesamte DB und Tabellenstruktur sicher anzeigt und konservieren lässt.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Version 2.4.12 Buggy (Backup).

by Auge ⌂, Tuesday, July 17, 2018, 19:20 (2081 days ago) @ Micha

Hallo

Für Version 2.5 schlage ich Folgendes vor


... wir sollten meiner Meinung nach überlegen, ob wir dieses Feature nicht besser entfernen sollten. Ich persönlich habe noch nie ein Backup über die Funktion erstellt …

Ich habe das "früher" auch nie getan. Tatsächlich schaue ich neuerdings öfter in einzelne erstellbare Backups hinein, zum Beispiel um die Arbeit des Skripts, das eine neue Version vermelden soll, zu kontrollieren. Es ist halt so schön einfach, im Adminbereich ein paar Mal zu klicken und als Ergebnis dessen die Rohdaten eins zwei fix im Editor zu betrachten. Das ist einfacher, als ein neues Tab zu öffnen, sich in phpMyAdmin einzuloggen und sich durch die diversen Bäume und Menüs durchzuklicken.

… sondern nutze hierfür PHPmyadmin oder ein anderes Tool, welches mir die gesamte DB und Tabellenstruktur sicher anzeigt und konservieren lässt.

Ja, phpMyAdmin kann bei weitem mehr und dies sicherer und flexibler, man muss aber – wenn für den fraglichen Zweck normalerweise auch einmalig oder seltenst – mehr tun. Diese Funktion dem normalerweise vorhandenen, fraglos besseren Tool zu überlassen, ist jedenfalls eine Überlegung wert.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Version 2.4.12 Buggy (Backup).

by Micha ⌂, Tuesday, July 17, 2018, 20:34 (2081 days ago) @ Auge

Hi,

ich habe im Moment den Eindruck, dass die Backup-Funktion sehr fehleranfällig ist, da wir sie nur unzureichend pflegen (mich eingeschlossen; ich habe die praktisch nicht auf dem Schirm, da ich sie auch nicht nutze). Letztlich bekommen wir zwar von Anwendern hier das Feedback, dass etwas nicht geht, aber bei der Backup-Funktion(!) ist das in meinen Augen tödlich. Der User erstellt die Sicherung ja nicht grundlos und wenn er diese nicht wieder sicher zurückspielen kann, ist dies wenig vertrauenerweckend. Ich halte den "Schaden", der durch das Verwerfen der Funktion entsteht, für deutlich geringer als den, der entsteht, wenn die Implementierung fehlerhaft ist.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Soll die Backup-Funktion entfernt werden?

by Auge ⌂, Wednesday, July 18, 2018, 07:17 (2081 days ago) @ Micha

Hallo

ich habe im Moment den Eindruck, dass die Backup-Funktion sehr fehleranfällig ist, da wir sie nur unzureichend pflegen (mich eingeschlossen; ich habe die praktisch nicht auf dem Schirm, da ich sie auch nicht nutze).

Ich hatte ja schon bei der Einrichtung des Ersatz-Projekt-Forums und den dortigen Tests ein paar Fehler entdeckt und behoben. Mit der Behebung der Fehler aus Martins Meldung sollten wir mit dem aktuellen Stand des Master-Branches ein vollständiges Backup erzeugen können (auch wenn der gerade nicht einmal installierbar ist). Aber …

Letztlich bekommen wir zwar von Anwendern hier das Feedback, dass etwas nicht geht, aber bei der Backup-Funktion(!) ist das in meinen Augen tödlich. Der User erstellt die Sicherung ja nicht grundlos und wenn er diese nicht wieder sicher zurückspielen kann, ist dies wenig vertrauenerweckend. Ich halte den "Schaden", der durch das Verwerfen der Funktion entsteht, für deutlich geringer als den, der entsteht, wenn die Implementierung fehlerhaft ist.

… mit deiner Argumentation hast du, fernab von Fehlern, die wir selbst machen, völlig recht. Wenn die Funktion da ist, muss sie verlässlich sein. Selbst wenn nicht, wie jetzt von Martin gemeldet, Felder fehlen oder zuviel sind, kann davon ausgegangen werden, dass ein Backup, das mit einem dedizierten Tool für Backups erstellt wurde, zuverlässiger ist. Schließlich werden, von den Realitäten der vorhandenen Datenbank ausgehend, passende CREATE- und INSERT-Statements erzeugt, Feldtypen und mögliche Inhalte zuverlässiger detektiert und passend maskiert, etc. pp.

Ich würde mich über Berichte zu Erfahrungen von anderen Nutzern freuen. Wer benutzt die Funktion wie oft und zu welchen Zwecken? Wird stattdessen ein anderes Tool, wie phpMyAdmin, benutzt? Umzüge sind ja wohl eher selten, aber vielleicht hat ja irgendwer noch andere Einsatzzwecke, so wie ich, wenn ich Einstellungen oder die Ausführung der täglichen Aufgaben überprüfe.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Soll die Backup-Funktion entfernt werden?

by Martin66, Wednesday, July 18, 2018, 20:35 (2080 days ago) @ Auge

Ich würde mich über Berichte zu Erfahrungen von anderen Nutzern freuen. Wer benutzt die Funktion wie oft und zu welchen Zwecken? Wird stattdessen ein anderes Tool, wie phpMyAdmin, benutzt?

Ich nutze die Funktion alle paar Monate, um die Echtdaten in meine Testumgebung zu kopieren. Ist halt so schön bequem.

Ich weiß auf Anhieb gar nicht, ob man mit phpMyAdmin in einem Rutsch alle Tabellen sichern kann? PhpMyAdmin ist nicht gerade meine tägliche Arbeitsumgebung. Und das, obwohl ich mich mit Datenbanken wenigstens auskenne. Wie das wohl mit einem MLF-Forenadmin aussieht, der sich damit überhaupt nicht auskennt? Wäre der nicht mit einer Sicherung überfordert?

Martin

Avatar

Soll die Backup-Funktion entfernt werden?

by Auge ⌂, Thursday, July 19, 2018, 06:54 (2080 days ago) @ Martin66

Hallo

Ich würde mich über Berichte zu Erfahrungen von anderen Nutzern freuen.


Ich nutze die Funktion alle paar Monate, um die Echtdaten in meine Testumgebung zu kopieren. Ist halt so schön bequem.

Ich weiß auf Anhieb gar nicht, ob man mit phpMyAdmin in einem Rutsch alle Tabellen sichern kann?

Definiere "in einem Rutsch"! Man muss ein wenig mehr klicken, als in der MLF-Adminoberfläche, da man von Tabelle zu Tabelle wechseln und dort die Backup-Funktion (Reiter "Export") aufrufen muss.

PhpMyAdmin ist nicht gerade meine tägliche Arbeitsumgebung. Und das, obwohl ich mich mit Datenbanken wenigstens auskenne. Wie das wohl mit einem MLF-Forenadmin aussieht, der sich damit überhaupt nicht auskennt? Wäre der nicht mit einer Sicherung überfordert?

Keine Ahnung. Ich gehe davon aus, dass der Betreiber eines Forums typischerweise auch der Betreiber der jeweiligen Domain ist. Als solcher sollte einem die Verfügbarkeit von phpMyAdmin oder eines ähnlichen Tools zumindest bekannt sein. Zudem werden die meisten Forenbetreiber auch die foreninterne Funktion noch nicht genutzt haben.

Der große Vorteil von phpMyAdmin ist, dass es Themen wie "Die neuen Tabellen oder Felder sind in der Backupfunktion nicht berücksichtigt." oder "Müsste dieser ohne jener Datentyp nicht in Anführungszeichen eingefasst werden?" einfach nicht gibt. Wir könnten neue Tabellen oder Felder nicht vergessen und auch keine kaputten Anweisungen zusammenstöpseln.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Soll die Backup-Funktion entfernt werden?

by Martin66, Friday, July 20, 2018, 18:51 (2078 days ago) @ Auge

Definiere "in einem Rutsch"! Man muss ein wenig mehr klicken, als in der MLF-Adminoberfläche, da man von Tabelle zu Tabelle wechseln und dort die Backup-Funktion (Reiter "Export") aufrufen muss.

Gerade habe ich die Zeit gefunden, ein Backup nur mit phpMyAdmin zu erstellen und in die localhost-Testumgebung einzuspielen. Ja, es geht! :-D

Man muss dabei nur Folgendes berücksichtigen:

  • In der Produktivumgebung die ganze Datenbank auswählen. Nicht einzelne Tabellen.
  • "Exportieren" wählen, und dort "angepasst". Mit den Standardeinstellungen geht es nicht.
  • Komprimierung: "ZIP-Komprimiert" wählen. Ist zumindest bei mir nötig, denn mein Backup wird größer als 4096KiB
  • "TRUNCATE Tabelle vor dem Einfügen" auswählen (Ist eigentlich logisch, aber nicht Standard).
  • Es ist NICHT notwendig, unter "Zu verwendende Syntax bei der Dateneingabe" etwas zu ändern, aber wer es stilistisch lieber so aufgebaut mag, wie bei der in mlf eingebauten Backup-Funktion, kann den letzten Punkt wählen.

Martin

Avatar

Soll die Backup-Funktion entfernt werden?

by Micha ⌂, Thursday, July 19, 2018, 19:50 (2079 days ago) @ Martin66

Hallo,

Danke für Dein Feedback.

Wäre der nicht mit einer Sicherung überfordert?

Vielleicht... aber wie oft sichert dieser unbedarfte Anwender das Forum gegenwärtig?


/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Soll die Backup-Funktion entfernt werden?

by Martin66, Friday, July 20, 2018, 18:55 (2078 days ago) @ Micha

Wäre der nicht mit einer Sicherung überfordert?


Vielleicht... aber wie oft sichert dieser unbedarfte Anwender das Forum gegenwärtig?

LOL. Sehr gutes Argument.

Und mir ist inzwischen sogar noch etwas eingefallen: Wenn man alte Backups im Backupverzeichnis hat, die mit einer älteren mlf-Version erstellt wurden, kann man die ohnehin nicht mehr verwenden.

Von daher: Ja, es spricht eigentlich auch aus meiner Sicht nichts dagegen, die Backup-Funktion aus mlf rauszunehmen.

Martin

Avatar

Soll die Backup-Funktion entfernt werden?

by Micha ⌂, Monday, July 23, 2018, 14:47 (2075 days ago) @ Martin66

Hi,

Wenn man alte Backups im Backupverzeichnis hat, die mit einer älteren mlf-Version erstellt wurden, kann man die ohnehin nicht mehr verwenden.

DAS, ist noch ein weiterer Punkt in der Liste, der m.M.n. gegen diese Art der Sicherung spricht. Ein Backup über ein SQL-Tool wird diesen Umstand aber auch nicht berücksichtigen, das nur der Fairness halber.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Backup-Funktion beibehalten und automatisieren ?

by candleman ⌂, Tuesday, July 24, 2018, 08:52 (2074 days ago) @ Micha

.
man könnte sich auch vorstellen, dass MLF automatisch ein backup vor einem update macht.
Ich weiss nicht, wie aufwendig das zu realisieren ist, geniesse das aber z.B. sehr bei joomla /mit installiertem akeeba/

Avatar

Backup-Funktion beibehalten und automatisieren ?

by Micha ⌂, Tuesday, July 24, 2018, 14:16 (2074 days ago) @ candleman

Hallo,

man könnte sich auch vorstellen, dass MLF automatisch ein backup vor einem update macht.

Ja, dass stimmt. Aber in den meisten Fällen ändern wir in der DB nichts (außer die Versionsnummer).

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Backup-Funktion beibehalten und automatisieren ?

by Auge ⌂, Tuesday, July 24, 2018, 19:16 (2074 days ago) @ candleman

.
man könnte sich auch vorstellen, dass MLF automatisch ein backup vor einem update macht.

… was ohne Änderungen an der Datenbankstruktur unsinnig ist und, zumindest so, wie die Erstellung der Datenbankbackups aktuell funktioniert, nach Änderungen an der Struktur nicht mehr einspielbar wäre. Das lässt sich natürlich recht einfach ändern, ändert aber rein gar nichts an dem Umstand, dass wir immer wieder vergessen, geänderte Datenbankstrukturen im Backupskript nachzupflegen, was zu dieser Diskussion führte.

Es sind offensichtlich nur so wenige Forenbetreiber, die die Backupfunktion überhaupt und wenn, dann nur selten nutzen, dass bestehende Fehler erst nach x Versionen überhaupt gefunden und gemeldet werden. Da es qualifizierten – und eigentlich sehr viel qualifizierteren – Ersatz gibt, ist die Entfernung der Funktion statt ihrer Aufbohrung eine überdenkenswerte Option.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Version 2.4.12 Buggy (Backup)?

by Auge ⌂, Monday, July 16, 2018, 19:27 (2082 days ago) @ Martin66

Hallo

INSERT INTO acc_userdata VALUES (
  • Die Daten zu "birthday" gehören in einfache Hochkommata, glaube ich.
  • Die beiden Felder "tou_accepted" und "dps_accepted" werden nicht gesichert.

Gefixt und gefixt.

INSERT INTO acc_entries VALUES (


Da scheint auch die Anzahl der gesicherten Felder nicht mit den vorhandenen übereinzustimmen. Wo da genau der Fehler liegt, habe ich jetzt nicht auch noch gesucht.

Ich auch noch nicht. ;-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Version 2.4.12 Buggy (Backup)?

by Auge ⌂, Tuesday, July 17, 2018, 19:11 (2081 days ago) @ Martin66

Hallo

INSERT INTO acc_entries VALUES (
Da scheint auch die Anzahl der gesicherten Felder nicht mit den vorhandenen übereinzustimmen. Wo da genau der Fehler liegt, habe ich jetzt nicht auch noch gesucht.

So, ich habe die Felder durchgezählt und das nicht mehr existierende Feld mlf2_entries.tags wurde im Backup-Skript zwar nicht mehr abgefragt, war aber im generierten INSERT-Statement tatsächlich noch aufgeführt.

Das wurde soeben mit dem Pull Request #391 gefixt. Danke für die Meldung.

Dennoch bleibt das von Milo in den Raum gestellte Ansinnen bisher unkommentiert (was ich gleich ändern werde).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

RSS Feed of thread