Optimierung Restore mit Akeeba Backup

  • Hallo,

    die Seiten mit J4 sichere ich mit Akeeba Backup.
    Nach meinen Kenntnissen soll das Verzeichnis, in welches das Restore stattfinden soll, leer sein außer der jpa-Datei und der kickstart.php.
    Das Löschen der vorhandenen Dateien und Verzeichnisse mach ich mit FileZilla, die DB leere ich per phpMyAdmin


    Da dieses Löschen reichlich Zeit benötigt (soviel Pausenkaffee kann ich gar nicht trinken) , meine Frage, ob es da etwas besseres gibt, z.B. ein Script?

    Das wäre schön, da das eigentliche Restore danach in wenigen Minuten erfolgreich abgeschlossen werden kann.


    Christian

  • Ich benutze Akeeba-Backup-Pro und kann die damit die Dateien überschreiben sowie die Datenbank löschen.

    Aus Sicherheitsgründen muß hier die kickstart.php umbenannt werden, z.B. update.php. Die Pro Version besteht aus kickstart.php bzw. update.php und cacert.pem.

    Diese Dateien kopiere ich mit der .jpa Datei auf die Website und rufe dann "meinewebsite/update.php" auf.

    Nach dem entpacken auf der Seite "Restoration of site's main database" gibt er rechts eine Spalte "Advanced options" mit dem Feld "With existing tables" und daneben ein Menükästchen mit "Drop" voreingestellt. Hier wähle ich "Drop All" und klicke oben auf "Next".

    Akeeba Backup löscht dann erst die Datenbank bevor die neuen Daten geschrieben werden.



    Gruß Gindi

  • Es kommt darauf an, welche Änderungen das Akeeba-Archiv oder andere wie EJB enthält, ob man immer den Webspace komplett löschen muss. Handelt es sich um die selben Joomla- und Erweiterungsversionen und wurden Dateien nur geändert und keine gelöscht oder Erweiterungen nur neu installiert oder Dateien hinzugefügt, kann man auch einfach "drüberbügeln".


    Aber, da man dabei den Überblick behalten muss, was man eigentlich gemacht hat, ist löschen meist doch meine favorisierte Variante ;)

  • Ich benutze Akeeba-Backup-Pro und kann die damit die Dateien überschreiben sowie die Datenbank löschen.

    Löscht die Pro-Version alle Dateien von Joomla und sichert dann zurück oder werden vorhandene Dateien nur überschrieben, wenn diese zur Rücksicherung gehören. Letzteres wäre ja fatal, denn dann würden typische Hacker-Backdoors größtenteils bestehen bleiben.


    Grundsätzlichg bin ich kein Fan von Akeeba und anderen internen Backup-Scripten eines CMS, die dann meistens auch noch innerhalb der jeweiligen CMS-Ordnerstruktur sichern, anstatt in einem externen Ordner außerhalb des Webs. Ja ich weiss man kann Akeeba und andere Tools oft auf andere Ordner einstellen, aber in der Praxis macht das kaum jemand.

    Als Ergebnis hat man dann sehr häufig extrem aufgeblähte Datenmengen in seinem CMS - hauptsachlich bestehend aus Backupfiles. Das ist ein grunsätzliches Designproblem dieser Backuplösungen.


    Rücksicherungen sind dann auch oft mit langwierigen Vorbereitungszeiten verbunden, wie das löschen des Altbestands (mit FTP bei zehntausenden Files eines typischen CMS dann eine Geduldsprobe) und der Bereitstellung von Setupscripten samt einer oder mehrere Backupfiles (sofern man die nicht aus Versehen vorher mit weggelöscht hat).

    Eine weitere Gefahr ist das Liegenlassen dieser Rücksicherungsfiles - ich weiss nicht wie oft ich schon auf eine kickstarter.php samt jpa-Daten in Webroot gestossen bin - kann es nicht mehr zählen.... Hacker-Bots suchen genau solche Files und was dann passiert ist nicht lustig.


    Meines Erachtens sollte es Aufgabe des Providers sein, schnelle und effektive Backuplösungen anbieten - als Bestandteil eines Hostingtarifs. Backups erzeugen und Rücksichern per Klick und ohne Vorbereitungen und ohne Abhängigkeiten zu einem CMS. Bereinigung vor einer Rücksicherung automatisch etc. Viele machen das ja, aber offenbar längst nicht alle oder User vertrauen diesen Lösungen nicht (ob das im Einzelfall berechtigt ist, kann ich nicht beurteilen).