Hallo,
wir planen gerade Backup und evtl. aufsetzen eines FallBack-Servers für einen Typo3-Auftritt (der erst noch entsteht).
Nun ist die Frage aufgetaucht, wie gross eine Typo3-Datenbank werden kann. Daher würde mich interessieren wie gross Eure Datenbanken sind - es wäre super wenn einige Leute URL und Datenbankgrösse (ungezippter Dump) posten könnten ...
Vielen Dank !
Tom
1. Du planst zu wenig Platz ein.
2. Auch 50% Aufschlag reichen nicht.
3. Ungezippter Dump ist unrealistisch, der ist bei meine T3-Projekten im Schnitt andertalb mal so groß wie die Datenbank.
Die DB zu http://www.dresden-exists.de ist 66 MB groß, der ungezippte Dump 102 MB, mit bzip2 behandelt sind es immerhin noch 59 MB. Also hinreichend groß, dafür sind da auch ein paar Logfiles usw. drin. Regelmäßiges Löschen der Systemstistiken kann bspw. auch Platz sparen.
4. Du brauchst noch jede Menge Platz für Grafiken usw.
5. Die Datenbanklogs füllen sich immer schneller, als man den Plattenplatz kontrolliert.
Reicht das? 😃
1. sorry, dass ich mich hier einmische
2. verstehe ich punkt bei 1,2,4,5 nicht den zusammenhang zur db-größe
3. warum verfasst du eine aufzählung?
4. ich habe einen kleinen auftritt im intranet liegen; sind 42 seiten. ein sql dump hat 3,5mb und gezippt gerade mal 400kb.
dabei sollte man aber erwähnen, dass ich so ca 4 extensions mit datenbankerweiterung installiert habe.
schönen abend noch
(die 2. halbzeit geht weiter 🙂)
Ganz einfach - die reine DB-Größe ist das eine, der _tatsächliche Platzbedarf etwas völlig anderes.
Geschrieben stand:
wir planen gerade Backup und evtl. aufsetzen eines FallBack-Servers für einen Typo3-Auftritt (der erst noch entsteht).
Dazu gehört natürlich die Datenbank, dazu gehört das fileadmin-Verzeichnis, /uploads, und zumindest im Fall von Fallback auch der Platzbedarf für eventuelle MySQL-Logs. Im Optimalfall bezieht man die auch in Backups mit ein, da man so einen (fast) beliebigen Zustand wiederherstellen kann.
Die Aufzählung bezog sich nur auf das typische Abarbeiten dieses Problems 🙂
Hallo,
also meine DB ist ca. 340 MB groß, unkompremiert. Gemessen hab ich das, indem ich mir die Größe des Ordners /var/lib/mysql/typo3 anzeigen lassen hab. Weiß nicht genau, wie ich anders messen soll. Wenn ich ein mysqlhotcopy (erzeugt doch ein dump, oder?) und ein tar -z -cf durchführe, sinds noch schwache 150 MB.
Meine DB ist aber nur deshalb so groß, weil ich die Indexed Search Engine verwende. Alle Index Tabellen zusammen haben so um die 300 MB. 40 MB hat also der Rest. Wenn du also ne einigermaßen umfangreiche Seite hast und die Indexed Search E. nicht einsetzen willst, solltest du also ca. mit 20-40 MB rechnen.
In dem Zusammenhang:
Gibt es die Möglichkeit, bei der Dump-Erstellung bestimmte Tabellen (konkret die Index-Tabellen) auszulassen? Dann hätte ich nicht so ein riesiges File, das ich uploaden muß...
Ich weiß halt nur nicht, wie es ist, wenn die Tabellen dann beim Provider auf einmal fehlen...
Hat da schon jemand Erfahrung?
Danke!
bnai schriebGibt es die Möglichkeit, bei der Dump-Erstellung bestimmte Tabellen (konkret die Index-Tabellen) auszulassen? Dann hätte ich nicht so ein riesiges File, das ich uploaden muß...
Das kannst Du z.B. ganz einfach per PHP-MyAdmin erledigen:
1. Datenbank auswählen
2. Reiter "Exportieren" wählen
3. Gewünschte Tabellen angeben
4. Evtl. als Kompression gzip oder zip angeben
CU
maxhb
Du kannst im phpMyAdmin ja die zu sichernden Tabellen auswählen, dort lässt Du die Suchindizes halt weg und exportierst die Daten. In Schritt 2 exportierst Du dann nur die Struktur der Suchindizes ohne Daten. Damit hast Du die komplette Webseite und alle nötigen Strukturen online - ready set go!
danke für eure tipps.
ich hab jetzt zuerst die komplette Struktur ohne Daten gedumpt und danach die Tabellen ausgewählt, die m.E. nötig sind. Mit gzip gepackt sinds nur noch 1,9 MB :o
Ich glaub ich kanns noch weiter runterschrauben, denn ich glaube, es mach keinen Sinn, die Daten der Tabellen sys_log und sys_history mit hochzuladen, oder?
Weiß jemand genau wozu die Tabelle sys_stat gut ist? Ich hab mal reingeschaut, stehn halt Informationen (Browser, OS, etc.) über die einzelnen User die die Seite aufrufen drin, vermute ich, aber wozu sie genau gebraucht wird, weiß ich nicht. Ich glaub aber auch hier macht es wenig Sinn, sie zu übertragen... oder doch?!
Darin wird die Statistik gespeichert.
Wer wann mit was welche Seite aufgerufen hat.
Über Extensions kann man diese Statistik dann wunderbar darstellen lassen.
Also ist die Tabelle für die T3 Funktion nicht von nöten, denke ich.
Hoffe aber, dass das erstmal einer bestätigen kann. 🙂
das ist auch meine vermutung, imho machts kein sinn, die zu übertragen.
hab eine extension installiert (Visitor Tracking System), die darauf zugreifen könnte. die extension hat aber noch zusätzliche tabellen, deswegen war ich etwas verwirrt. die muß ich mir dann vielleicht mal genauer anschauen.
Wenn noch andere Exts auf die Tabelle zugreifen solltest Du sie samt daten mitnehmen, ansonsten müsste die Struktur reichen.
Ansonsten sollte man zumindest alle Strukturen mit übernehmen, da irgend eine ext die ja schließlich angelegt hat ...
thoko schriebWenn noch andere Exts auf die Tabelle zugreifen solltest Du sie samt daten mitnehmen, ansonsten müsste die Struktur reichen.
hmm.. wenn es wirklich das ist, wofür wir es halten, dann ist es nicht logisch, die daten mit zu übertragen, weil es ja verschiedene Server sind. und ich will ja keine geloggten daten auf meinem "neuen" server, die ihn gar nicht betreffen. und wenn ich nur die struktur überneheme, sollte es auch kein Problem sein, denn nach der Installation war die Tabelle ja auch leer (vermute ich zumindest).
Wenn aber in anderen Tabellen Daten sind, die zusammen mit dieser Tabelle ausgewertet werden (sollen) - was dann? Grade das VTS würde ich da schon verdächtigen, darauf zuzugreifen. Und dann liegt es an der Intelligenz von Ext-Entwickler und Errorhandling was passiert - gar nichts, Fehler, unsinnige Ausgaben, ...
Natürlich die Tabellen zu anfang leer - aber eben alle dazugehörigen.
naja, ich werd ja sehn was passiert. die welt wird wohl nicht untergehn 😉
hmm... die tabellen die mit "cache" beginnen, müsste ich ja glaub ich auch nicht hochladen. denn wie der name schon sagt, handelt es sich nur um einen zwischenspeicher bzw. um einen speicher in dem seiten abgelegt werden, um sie schneller anzeigen zu können. oder was meinst du?
Also die Daten wirst Du sicher nicht brauchen, aber die Strukturen vmtl. schon.
Und natürlich solltest Du im Backend sicherheitshalber auf "alle chaches löschen" gehen da ich nicht weiß, ob T3 ein "Diese Seite liegt im Cache"-Flag irgendwo gesetzt hat...