naja incremental bringt auch nicht den haufen an speicherplatzersparnis. Aber alle 2 Tage ist ne Idee. Wir könnten auch vorerst mal jede Änderung saven.
ja schon. aber wenn eine page innert 2 tagen mehrmals geändert wird, dann gibt das schon mehr daten.
man muss die einzelnen teile natürlich auch wieder überschreiben, um speicherplatz zu sparen. wenn du das nach einer gewissen anzahl updates machst, dann besteht die gefahr, dass eine page einfach x mal upgedatet werden muss, um sie endgültig zu verhunzen. bei der alle-2-tage (oder auch länger) besteht diese gefahr nicht.
aber wenn man das mit der alle-2-tage backup methode macht, können ja grosse änderungen, die man am 1. tag gemacht hat, am 2. tag verhunzt werden. dann muss man ja wenn man es zurücksetzt nochmals coden...
wenn man jeden tag 1 backup macht, kann man ja die backups für 1 woche behalten. wenn jetzt ein tpl für 1 woche nicht geändert wird, behält man einfach nur noch das letzte backup dieses tpl.
das würde vom speicherplatz her funktionieren?
ja, so funktioniert das schon (7 tage incremental backup). das war ja auch mein vorschlag. aber mit 14 tage full backup funktionert es nicht. meiner meinung nach.
uhm, komprimierter text ist ziemlich klein! Ansonsten könntet ihr ja etwas mit diff basteln, aber ich bezweifle dass 2 wochen full backups wirklich so grob sind. was soll den alles backuped werden? auch pics und so?
Nein, wirklich nur der Tempalte/Wiki Text. Es ist nur so, dass wenn ich mir die aktuellen Grössen der Tabellen anschaue, diese mal 14 rechne (für 14 Tage full Backup) und das dann mit unserem verbleibenden Webspace vergleiche, dann sind wir drüber...
Die smarty-table hat auch noch kaum Einträge. Ich orientiere mich an der Wiki-Table. die hat jetzt 2.3 MB. da die smarties doch ein etwas zentralerer bestandteil werden, dürfte diese table doch noch um einiges grösser werden. sagen wir mal 5 MB. das mal 14 = 70MB. so viel webspace haben wir im Moment nicht mehr frei. Wenn Webers upload/download Tool (wo ist das eigentlich?) aktiv genutzt wird, wird der Webspace noch knapper
Gut, man könnte noch die comments_read table optimieren. Die hat jetzt über 70MB. ich glaube die bringt man locker auf unter 10MB. (schauen wir dann an der Coding-Session an)
