Hi Pedro.
Sind deine Cache-Tabellen so groß dass es das Backup spürbar beeinflusst oder geht es dir lediglich um die Frage, welche Tabellen im Notfall weg gelassen werden könnten? Ich würde vermeiden, an der Datenbank zu fummeln wenn es nicht notwendig ist. Insbesonere die Cachetabellen von RealURL würde ich nicht anfassen. Ich kann dir den genauen Zusammenhang der einzelnen Tabellen gerade nicht nennen. Dazu brauche ich den zu wenig. Grundsätzlich ist der RealURL-Cache aber auch dafür zuständig, eingehende Klicke auf Seiten zuzuordnen, selbst wenn die Seite mittlerweile eigentlich nicht mehr unter diesem Link erreichbar ist. Manchmal ist das unerwünscht, zum Beispiel wenn man an das Märchen vom Duplicate Content glaubt. Wenn ich allerdings eine Seite im TYPO3- Seitenbaum verschiebe finde ich es allerdings sehr angenehm, wenn Google die Seite weiterhin (auch noch) über die alte Adresse findet anstatt sofort alle Klicks auf 404-Seiten zu lenken. Außerdem würde ich mal ausprobieren, was die Suche so treibt wenn man den Seitencache leert. Der Index der Suche ist zwar grundsätzlich ein ganz anderer, allerdings könnte der auf Cacheseiten zurückgreifen. Es werden ja immerhin auch nur solche Seiten indiziert die in den Cache wanert. Ob die Suche auch nur solche Seiten findet die sich noch im Seitencache befinden oder ob der Cache lediglich den Indexzeitpunkt bestimmt wäre jedenfalls ein Aspekt den ich vorher ausprobieren würde. Bei gut besuchten Seiten ist das vielleicht nicht ganz so tragisch. Bei großen Seiten mit mäßig vielen Besuchern kann es schon unangenehm werden. Deshalb meine Empfehlung: Nimm den Cache mit ins Backup. Natürlich kann man argumentieren, dass der Cache wohl dein geringstes Problem ist wenn du auf dein Backup zurückgreifen musst. Ich halte das allerdings für einen unnötigen Risikofaktor. Grüße, Stephan Schuler Web-Entwickler Telefon: +49 (911) 539909 - 0 E-Mail: stephan.schu...@netlogix.de Website: media.netlogix.de -- netlogix GmbH & Co. KG IT-Services | IT-Training | Media Andernacher Straße 53 | 90411 Nürnberg Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 E-Mail: i...@netlogix.de | Internet: http://www.netlogix.de netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338) Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634) Umsatzsteuer-Identifikationsnummer: DE 233472254 Geschäftsführer: Stefan Buchta, Matthias Schmidt ________________________________________ Von: typo3-german-boun...@lists.typo3.org [typo3-german-boun...@lists.typo3.org]" im Auftrag von "Philipp Gampe [typo3.li...@philippgampe.info] Gesendet: Montag, 25. April 2011 18:00 Bis: typo3-german@lists.typo3.org Betreff: Re: [TYPO3-german] DB-Backupt Optimieren Hallo Pedro, Pedro Julio wrote: > zu erst frohe Orstenferien an alle... > Um die Datenbank zu Sichern, versuchen meine Kollegen jede Nacht > folgende Tabelle zu löschen: "cache_hast, cache_imagesizes, > cache_md5params, cache_pages, cache_pagesection, cache_treelist, > cache_typo3temp_log, tx_realurl_chashcache, tx_realurl_pathcache, > tx_realurl_urldecodecache, tx_realurl_urlencodecache" Grundsätzlich kann man Caches jederzeit löschen, allerdings muss dann auch die entsprechende Seite neu generiert werden. Außerdem muss du darauf achten, dass du auch alle löschst. Sonst kann es passieren, dass das System sagt "oh, Cache Eintrag A.2 gefunden, zusätzlich brauch ich noch Teil B.42 aus Cache B", aber B gibt es nicht mehr ==> Fehler. Der bessere Ansatz ist sicherlich nur die Tabellen zu sicher die kein Cache im Namen haben. Zusätzlich kann man dann noch weitere Tabellen ausschließen, wie die für die Liste der Extensions. Viele Grüße -- Philipp Gampe _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
