Darf man joomla cache files löschen

  • Im Joomla Installationspfad gibt es sehr file cache direktories z.B

    /httpdocs/joomla/cache

    /httpdocs/joomla/cache/preview

    /httpdocs/joomla/cache/template

    /httpdocs/joomla/cache/thumb

    /httpdocs/joomla/cache/widgetkit

    /httpdocs/joomla/cache/.tmb

    /httpdocs/joomla/cache/com_imagemanager

    (Das ist ein Plugin, welches alle Bilder auch nochmal cached)


    /httpdocs/joomla/libraries/src/cache

    /httpdocs/joomla/administrator/cache

    /httpdocs/joomla/administrator/components/com_cache

    /httpdocs/joomla/k2/items/cache

    /httpdocs/joomla/

    /httpdocs/joomla/

    joomla\plugins\editors\jckeditor\jckeditor\includes\ckedithor\cache

    Kann man die Inhalte von caches löschen und bei Bedarf wieder erzeugen lassen.? bzw. darf man die beim Backup excludieren und kann sie dann wieder erzeugen.

    Mein Verständnis von cache files ist, dass es sich um statische Inhalte von dynamischen Inhalten handelt, die eigentlich jederzeit
    wieder erzeugt werden, wenn sie nicht vorhanden sein sollten. In den meisten Fällen handelt es sich um Kopien von Bildern, previews, oder thumpnails
    die aber jede Menge Platz brauchen.


    Hintergrund meiner Frage ist, dass die Backupzeit über FTP am Monatsende beim Gesamtbackup extrem lange dauert.
    Das liegt einerseits an meiner langsamen Übertragungsleitung und an der immensen Anzahl von Bilddateien und deren caches,
    die gefühlt 10 x kopiert werden.

    Meine ersten Test mit dem löschen von cache waren nicht erfolgreich und ich konnte mehrmals den restore - prozess üben.
    Von daher die Frage ins Forum, ob man die cache Daten löschen und wieder erzeugen kann, oder ob man von cache Daten
    generell die Finger lassen muss. Evtl. kann man einige löschen, andere hingegen nicht. Ist auch schwer zu testen, wenn
    man die Funktion der cache Daten nicht kennt. Hat da jemand bereits Erfahrung gesammelt? thx

  • Hintergrund meiner Frage ist, dass die Backupzeit über FTP am Monatsende beim Gesamtbackup extrem lange dauert.
    Das liegt einerseits an meiner langsamen Übertragungsleitung und an der immensen Anzahl von Bilddateien und deren caches,
    die gefühlt 10 x kopiert werden.

    Du solltest Deine Backupstrategie überdenken.

    Über FTP fehlt Dir immer noch die Datenbank, das Herzstück in Joomla. Und wie Du schon bemerkt hast, dauert das sehr lange.


    Teste mal Akeeba-Backup, das kann vieles automatisch für Dich erledigen und ein installierbares Backup erzeugen.
    Desweiteren kannst Du ganze Verzeichnisse (tmp/cache) ausschließen, wobei das in Akeeba schon standradmäßig vorkonfiguriert ist.
    Und, Du musst nicht dabei sitzen bis alles fertig ist.


    Auch https://kubik-rubik.de/de/ejb-easy-joomla-backup ist nicht schlecht.


    Ach ja, Du kannst die Inhalte im Cache (/httpdocs/joomla/cache/) ohne Probleme löschen. Die werden automatisch wieder angelegt.

  • Zitat

    /httpdocs/joomla/libraries/src/cache

    ...

    /httpdocs/joomla/administrator/components/com_cache

    ...

    Die darfst du keinesfalls löschen. Es sind weitere dabei, die ich nicht kenne, z.B. jckeditor, die du natürlich vorher sichten musst, ob da nicht Dateien drinnenliegen, um den Cache zu verwalten, also PHP-Bibliotheken bzw. -Klassen.


    Cache-Dateien sind meist hieroglyphische Lange-Würmer-Dateinamen im Unterschied zu sauber benannten Dateien.


    /httpdocs/joomla/cache

    /httpdocs/joomla/administrator/cache


    und Unterordner sind jedenfalls erlaubt, aber die werden eh über Backend per "Cache löschen"-Feature gelöscht oder man verwendet Plugin https://extensions.joomla.org/extension/cache-cleaner/ , wo man auch tmp-Ordner aus Backend per Klick mitlöschen kann (und anderes).


    Auch EJB sichert Cache-Ordner und tmp-Ordner nicht mit. Wenn du beide von Indigo66 genannten Backup-Erweiterungen testen willst, musst du aber den Backuppfad der jeweils anderen Erweiterung in der Konfiguration ausschließen! Sonst werden deren Backups mitgesichert.

  • Danke für die guten Antworten.

    Es geht hauptsächlich darum den Backup zu reduzieren und das geht am besten, wenn Bilddaten in caches
    erst gar nicht mitgesichert/restored werden müssen. Sobald man aber andere caches, die nicht unter images stehen
    löscht wird es kritisch. Die werden meist micht mehr reconstruiert, wie immer die zu Beginn angelegt werden. Ich werde
    aber das eine oder andere ausprobieren, wenn der Cache eine entsprechende Größe hat.

    Werde mir anschauen was akeeba oder ejb an Direktories excludieren dann kann ich das ja auch anpassen.
    FYI, mein Provider benutzt plesk, sodass ich einfach vorher die Datenbank exportiere und unter dem Backuppfad
    auf dem Server speichere, dann wird die immer auch über ftp mitgesichert. Das mache ich zeitlich gestaffelt, sodass die
    beiden Datensätze DB und files immer gut und aktuell zusammen passen.

    Thx

  • Du solltest daran denken, dass per FTP das Runterladen der Einzeldateien immer extrem länger dauert, als das Runterladen eines einzelnen ZIP mit allen Dateien, das bspw. mit EJB gesichert wurde (auch das enthält die DB als einzelne sql-Datei).


    Und das hängt nur etwas damit zusammen, dass die ZIP-Datei ingesamt etwas kleiner ist als alle Einzeldateien. Ist generell bei Datei-Kopieraktionen zu bedenken, dass das so ist. Auch lokal.


    Wenn du nach Herunterladen das Ergebnis zügig lokal entpacken willst, ist EJB die praktischere Variante, da "stinknormale" ZIP-Datei, im Unterschied zu Akeeba, wo man zwar auch als ZIP speichern kann. Aber Datenbank-Inhalte, sind auf mehrere Text-Dateien verteilt und Sicherungen, die in mehrere Archive gesplittet sein könnten, lassen sich nicht mit herkömmlichen Entzip-Programmen entpacken. Sind ja auch eher für eine einfache Wiederherstellung der kompletten Seite via grafischer Oberfläche auf einem Webserver gedacht.


    Der "Akeeba eXtract Wizard" zum "stinknormalen", lokalen Entpacken von Akeeba-Archiven arbeitet nicht immer verlässlich bei größeren Archiven.


    Kurz. Hängt auch etwas davon ab, was du mit Sicherungen vorhast. Und von der Größe der Webseite, ob EJB FREE ausreicht (ich habe 2 x-Gigabyte-Seiten, wo das nicht mehr klappt, wegen Timeouts).

  • Hallo re:Later et all
    Ja natürlich bekommt man mit zip das Backup kleiner bevor man es mit ftp überträgt. Aber wie schon erwähnt
    läuft man bei großen Websites und langsamen Leitungen in timeouts rein. Wie kann man also
    Joomla Backups verlustfrei verkleinern .z.B durch exkludieren von cache im image Bereich, excludieren
    von statischen Bereichen, die sich sowieso nicht ändern.


    Von daher meine Frage, welche caches Joomla automatisch wieder rekonstruiert.
    "Jedes File was man gar nicht backupen muss ist ein gutes File"

    Abscheinend hat sich da noch niemand genauer beschäftigt. Ich mache gerade tests mit einer leeren Joomla
    und schaue dann was nach Löschung eines cash directories crashed. Ist aber mühsälig und man weiss auch nicht
    100% ob man alles getestet hat. Besonders bei image plugins, widgetkit etc.


    Insgesamt komme ich mit incrementellen Backups noch hin, aber die Full Backups machen mir Sorgen und laufen
    zu lang. Und auf 50/100 Mbit Datenleitung warte ich vermutlich noch ein wenig.....


    Thx

  • Ich kann dein Problem nicht nachvollziehen. Seit Jahren arbeite ich mit Akeeba. Der Download des Backupfiles hat auch früher mit meiner lahmen Leitung ohne Fehler funktioniert. Bei den asynchronen Leitungen war auch eher das Upload das Problem als der Download.

    Und Automatisches und kostenloses Akeeba Backup erstellen (Anleitung) ist sogar ein automatisches Backup beschrieben.

    Bei Updates werden diverse Dateien geändert, so dass es kaum möglich ist, zu wissen welche. Der Seiteninhalt steht in der DB und muss natürlich immer gesichert werden. Bleiben noch die Ordner, wo Bilder, pdf etc. abgelegt werden. Die müssen natürlich nur bei Änderungen gesichert werden. Da wäre mir aber der Aufwand zu groß, das im Blick zu haben.

    Was hast du den für eine Leitung, dass es so problematisch ist.

  • Abscheinend hat sich da noch niemand genauer beschäftigt.

    Bisher haben sich alle, die bisher geantwortet haben, damit genauer beschäftigt ;-)


    Akeeba läuft in keine TimeOuts, weil es mit AJAX arbeitet. Bei 1und1 gabs kürzlich mal Probleme, weil paar derer Server komische Konfigurationseinstellung haben. Gabs aber mehrere Lösungen hier im Forum, die funktionieren.


    EJB kann AJAX in der Pro-Version.


    Und Cache-Dateien in den beiden Standard-Cache-Ordnern werden in Normalfall erneuert, wenn sie nicht mehr da sind, sozusagen. Solltest du eine Erweiterung haben, die zu blöde dafür ist... Woher sollten wir das wissen, welche das sein könnte.


    Bei K2 oder jck-Editor musst dich an die Hersteller wenden, wenn das wirklich Cache-Ordner sind, die du oben nennst, und eben nicht nur "cache" heißen.


    Extrem ist Sobipro, das tatsächlich den Webspace unnötig zumüllt und dafür eigene Ordner verwendet, die aber auch nicht "cache" heißen. Macht die Suche noch aufwendiger.


    Außerdem musst ja bei einem FTP-Download nicht die ganze Zeit daneben sitzen und zuschauen.


    Falls du Windows verwendest:

    Ich mach das mit SyncBack für Windows und geh dann ins Bett nach dem Start. Kann man auch so einstellen, dass es den Rechner dann runterfährt. Und, wenn tatsächlich mal Fehler, geht der Browser auf und man sieht eine Ergebnisliste, die aber auch gespeichert wird. Mehrere Profile parallel abarbeiten oder hintereinander. Ordner, Dateien ausfiltern... Viele weitere nette Einstellungen, in die man sich halt 1x einarbeiten muss. Aber nicht das Drama, wenn man sich die Zeitersparnis unterm Strich anschaut...

  • Aber wie schon erwähnt
    läuft man bei großen Websites und langsamen Leitungen in timeouts rein.

    Das kann ich auch nicht nachvollziehe.
    Unter 1und1 z.B. kann ich im KAS-Dateimanager aus allen Dateien/Verzeichnissen und deren Ausschluss, direkt auf dem Server ein ZIP generieren und dieses entweder über HTTP oder FTP ohne Probleme runterladen.


    Bei STRATO hatte ich mal ein TimeOut Problem mit Akeeba, aber auch dann lässt sich das Backup in mehrere Dateien aufteilen und der Spuk ist vorbei.