Backup wird nicht erstellt

[Kleimes]

Hallo,

ich wollte gerade ein Backup meiner Seite durchführen um sie auf einem anderen Server zu installieren. Leider öffnet sich nur ein Fenster mit dem Text "Erstelle Website-Template ..." und dann tut sich nichts mehr. Im Verzeichnis "templates" wurde auch nichts generiert.

Ich habe die Version 2.8.1 und das Modul ist auch aktuell. Hat jemand eine Idee? Ist meine Datenbank evtl. zu groß?

Schöne Grüße,
Andreas Kellermann

[do_while]

Hallo Kleimes,

ich habe es gerade noch einmal ausprobiert:

• TYPOlight 2.8.1
• diverse Erweiterungen
• BackupDB 1.1.3 stable Build 10
• erhaltene Templategröße 1,2 MB

Hast Du den SafeMode-Hack in Betrieb?
Ist der richtig eingerichtet? SMH-Check?

[Kleimes]

Hallo Hagen,

vielen Dank für die Antwort. Bin leider erst gestern Abend dazu gekommen, es zu testen.

Ich habe den SafeMode-Hack nicht in Betrieb. Vor ein paar Monaten hat es bereits mit dem Backup geklappt und auch andere Webseiten beim gleichen Provider (one.com) laufen ohne Probleme und ein Backup ist ebenfalls kein Problem.

Ich vermute, daß die Datenbank einfach zu groß wird. Wenn ich sie über phpmyadmin exportiere wird sie schlappe 20,9 MB groß. Ich habe nun "von Hand" die Seite auf einen anderen Webspace verlagert.

Gruß,
Kleimes

[xchs]

Hallo Kleimes,

Ich vermute, daß die Datenbank einfach zu groß wird. Wenn ich sie über phpmyadmin exportiere wird sie schlappe 20,9 MB groß. Ich habe nun "von Hand" die Seite auf einen anderen Webspace verlagert.

Die Datenbank wird wahrscheinlich wirklich etwas zu groß sein, hängt aber auch von der eingestellten maximalen Scriptlaufzeit ab:

Bei größeren Datenbanken kann es passieren, dass die maximale Scriptlaufzeit überschritten wird, dann kann das AutoBackupDB leider nicht verwendet werden.

Du hättest z.B. mit Hilfe des TYPOlight Systemdiagnosetools noch überprüfen können, welchen Wert die "Maximum execution time" aktuell hat. Gleichzeitig hast Du über den System-Check auch die Möglichkeit, Deine Installation auf etwaige Fehler oder fehlerhafte Dateien hin zu überprüfen.

Darüberhinaus könntest Du ev. auch mal probieren, im myPHPAdmin die Tabellen Deiner Datenbank über die dort verfügbaren Optionen "Überprüfen" und "Optimieren" entsprechend aufzuräumen; u.U. kannst Du so die DB-Größe auch nochmals etwas verringern (aber wahrscheinlich eh nur wenig).

[Hauge]

Hallo zusammen - auch ich habe in der 2.8.1er Version das gleiche Problem - gibt's hier bereits einen Lösungsansatz?

[xchs]

Hallo zusammen - auch ich habe in der 2.8.1er Version das gleiche Problem - gibt's hier bereits einen Lösungsansatz?

Eine der möglichen Alternativen wäre "MySQLDumper", der auch mit recht großen Datenbanken (und gleichzeitig eingeschränkten Scriptlaufzeiten) zurechtkommen sollte.

[Zobbl]

Diese ~21mb Dumpgröße kommen sehr wahrscheinlich von der Tabelle tl_log, da dort ziemlich alle Aktionen gespeichert werden.
Ich bin mir nicht sicher welche Daten dort genau gespeichert sind, aber wenn du auf die Versionierung (ich nehme an, diese wird dort gespeichert) fürs erste verzichten kannst, lass die Tabelle tl_log weg. Dann sollte sich dein Dump erheblich verkleinern.

Zum Template-Export kann ich nicht all zuviel sagen, mein Beitrag bezieht sich eher auf das allgemeine

mfg ZobbL

[xchs]

Diese ~21mb Dumpgröße kommen sehr wahrscheinlich von der Tabelle tl_log, da dort ziemlich alle Aktionen gespeichert werden.

Glaub ich - ehrlich gesagt - nicht. In der Standard-Einstellung werden Log-Einträge nämlich nur 14 Tage lang gespeichert und dass in dieser Zeit allein durch Log-Einträge die DB auf eine derartige Größe anwachsen kann, ist wohl eher unwahrscheinlich.

Die "Rückgängig"-Schritte (Tabelle "tl_undo") werden auch nur einen Tag vorgehalten, die Versionierung der Datensätze (Tabelle "tl_version") wird nach 90 Tagen verworfen.

[do_while]

Meist sind die Tabellen tl_search und tl_serach_index die größten Tabellen. Diese Tabellen müssen nicht gesichert werden, wenn man im Fall der Fälle einfach den Suchindex neuaufbauen läßt.

Die Verwendung von tl_log, tl_undo und tl_version hat ja xchs schon beschrieben. Ich würde sie in einer Datensicherung drin lassen, soweit es geht. Bei Verwendung als Transferdatei in eine andere Installation bruachst Du diese Tabellen allerdings nicht.

Die maximale Datenbankgröße für eine BackupDB-Sicherung scheint etwa bei 10-12 MB zu liegen, das hängt natürlich auch stark von der PHP-Runtime, der Server-Performance und Datenbankverbindung ab.

Wenn es nicht geht könntest Du auf den MySQLDumper ausweichen.

[xchs]

Meist sind die Tabellen tl_search und tl_serach_index die größten Tabellen.

Das kann ich auch bestätigen. Insbesondere im Zusammenhang mit der "Catalog"-Erweiterung und dort speziell beim Einsatz der Filter-, Sortier- und Suchmöglichkeiten, welche allesamt zusätzliche URL-Parameter bzw. URL-Fragmente erzeugen, können so mitunter unzählige zusätzliche Einträge im Suchindex generiert werden. Das führt natürlich zu einem teilweise beträchtlichen Overhead, da die selben Keywords bzw. Suchergebnisse dann mehrfach im Index vorhanden sind.

Wenn ich z.B. in der Contao Systemwartung die beiden Tabellen "tl_search" und "tl_search_index" bereinige (sprich: komplett leere) und anschließend den Suchindex neu aufbauen lasse, dann sind Pi mal Daumen ca. 6.000 Einträge im Index vorhanden, d.h. die einzelnen Katalog-Seiten wurden nur über die jeweiligen Links und Verknüpfungen aufgerufen und indiziert. Sofern nun aber im Katalog diverse Such-, Filter- bzw. Sortieroperationen durchgeführt werden, die natürlich jedesmal einen andere Seiten-URL erzeugen und infolgedessen vom Contao Indexer auch entsprechend indiziert werden, dann steigt diese Zahl der Index-Einträge locker auf über 20.000 an.

Das gegenständliche Verhalten ist natürlich nicht auf die Catalog-Erweiterung allein beschränkt, sondern betrifft im Prinzip sämtliche manuell durch den Benutzer erzeugte URL-Fragmente (wie auch immer die zustande kommen).

[Zobbl]

Oh dann muss ich für Fehlinformationen entschuldigen ^^.
Bei mir war es so, dass ein Dump von 3,5mb auf 150kb geschrumpft war, als ich tl_log ausgeschlossen hatte (vorher in der Systemwartung alle Daten bereinigt). Mein Gedanke war, dass sich das auch auf größere Dateigrößen ähnlich übertragen lässt

Aber wieder was dazu gelernt

mfg ZobbL

[do_while]

Hallo ZobbL,

das kommt natürlich immer darauf an, wieviele Meldungen gerade im Log eingetragen sind. Die Suchtabellen sind auch nur vorhanden, wenn die Suche in den Einstellungen bei TYPOlight aktiviert ist. Wenn die Suche aber aktiv ist, sind das meist die größten Tabellen und die brauchen dann auch entsprechend Zeit beim Sichern, um sie in der SQL-Datei in ASCII abzulegen.

[deerwood]

Hallo alle,

in diesem Zusammenhang finde ich es auch erwähnenswert, dass die Tabellen tl_undo und tl_log NICHT per cron regelmäßig bereinigt werden, sondern erst dann, wenn deren Datensätze angezeigt werden sollen. Vergleiche Forum Speicherzeit "Undo"-Schritte. Versucht man also niemals ein Undo und schaut sich niemals das Log an, dann werden diese beiden Tabellen voller und voller.

LG, Georg