Cronjob :: Backup - Festlegung der Tabellen

[skerbis]

Bestimmte Tabellen müssen nicht im Backup erfasst werden, da sie ggf. vom AddOn neu erzeugt werden oder ggf. zu große Daten enthalten.
Hierzu zählen ggf. der Suchindex von SearchIt oder auch YFeed-Daten.

Ideen:

• Die AddOns teilen dem Backup-Job mit, welche Tabellen nicht gesichert werden müssen
• Der Admin erhält die Möglichkeit die gewünschten Tabellen im Cronjob auszulassen

[olien]

Fände ich sehr gut! ich habe eine Webseite mit zwei Tabellen a 12MB, die dazu führen, dass das Backup nicht funktioniert.

[staabm]

Fände ich sehr gut! ich habe eine Webseite mit zwei Tabellen a 12MB, die dazu führen, dass das Backup nicht funktioniert.

ist das mit dem aktuellen redaxo auch noch so, oder ist das eine aussage von vor 2 jahren?

[olien]

Gestern getestet ...

[staabm]

wäre super wenn ich einen export einer solchen db/tabelle bekommen könnte um das zu testen/optimieren

[olien]

ok

[alxndr-w]

ich kann's ebenso bestätigen.

[danspringer]

Hatte auch Probleme bei großen DBs oder Table-Views. Habe dann einen neuen Reiter gebastelt, in dem man die zu exportierenden Tabellen auswählen/abwählen kann.

Funktioniert bei mir gut in 3 Projekten. Ob es sauber programmiert ist: hmm.. aber bei Interesse kann vllt mal jemand reinschauen.

[alxndr-w]

imho muss man irgendwo - in der package.yml oder in der rex_config - hinterlegen können, dass Tabellen vom Backup ausgeschlossen werden. Der Addon-Entwickler weiß ja am besten, welche Tabellen ausgeschlossen werden sollen.

Zudem wäre es u.U. wichtig, die Tabellenstruktur dennoch mit ins Backup zu nehmen, nicht jedoch die Datensätze - gerade wenn es darum geht, ein Backup einspielen zu können.

[marcohanke]

+1 Habe gerade eine ziemlich große Tabelle von "History"

[staabm]

@marcohanke ggf. kannst du mal #2760 testen und im pull request feedback geben ob die Änderung für deinen aktuellen use-case ausreicht

[alxndr-w]

Ich hab' da mal was vorbereitet...

[staabm]

hier vllt noch als Ergänzung zur urspr. Anforderung:

Addons können bereits selbst entscheiden ob tabellen im backup enthalten sein sollen.
Dazu muss man im tabellen namen den prefix rex_tmp_ verwenden, siehe:

redaxo/redaxo/src/addons/backup/lib/backup.php

Lines 340 to 349 in 68e6741

	if (null === $tables) {
	$tables = [];
	foreach (rex_sql::factory()->getTables(rex::getTablePrefix()) as $table) {
	if ($table != rex::getTable('user') // User Tabelle nicht exportieren
	&& substr($table, 0, strlen(rex::getTablePrefix() . rex::getTempPrefix())) != rex::getTablePrefix() . rex::getTempPrefix()
	) { // Tabellen die mit rex_tmp_ beginnne, werden nicht exportiert!
	$tables[] = $table;
	}
	}
	}

[alxndr-w]

Danke für die Ergänzung, @staabm!

tmp_ ist für mich nicht ganz eindeutig, denn Log-Tabellen oder bspw. die History sind ja nicht "temporär", sondern ein permanentes Archiv. Im Fall von search_it bspw. kann der Index ja kinderleicht frisch erstellt werden, würde mich aber dabei komisch fühlen, das als eine temporäre Tabelle zu führen.

Das Wording ist imho da nicht ideal, hat der tmp_-Präfix noch eine andere Aufgabe?

[staabm]

Das Wording ist imho da nicht ideal, hat der tmp_-Präfix noch eine andere Aufgabe?

siehe https://github.com/redaxo/redaxo/search?q=getTempPrefix&unscoped_q=getTempPrefix

dateien die mit temp-prefix ist, werden nicht vom medienpool sync beachtet.

tmp_ ist für mich nicht ganz eindeutig, denn Log-Tabellen oder bspw. die History sind ja nicht "temporär", sondern ein permanentes Archiv. Im Fall von search_it bspw. kann der Index ja kinderleicht frisch erstellt werden, würde mich aber dabei komisch fühlen, das als eine temporäre Tabelle zu führen.

tmp meint in diesem sinne dass es tabellen sind die keine nutzdaten tragen. search-index wäre ein idealer use-case dafür da die daten dafür aus anderen tabellen erzeugt werden.

tabellen die ein permanentes archiv darstellen sind nicht in als temporär in diesem context zu verstehen (du willst das archiv sicher auch im backeup mit drinnen haben?)

[alxndr-w]

Jetzt ist es für mich klar, das mit den Nutzdaten ist anschaulich.

Die Archiv-Daten von article_slice_history und yform_history sind für mich nicht so relevant, als dass ich davon ein Backup benötige - betrachte sie dennoch als Archiv. Aber genau das kann ich ja dann selbständig einstellen und bspw. sagen, dass diese Tabellen viel seltener oder gar nicht in ein Backup müssen.