Backup in 1.7 scheitert, weil cronjob zu lange dauert - splitten des Scripts möglich?

Re: Backup in 1.7 scheitert, weil cronjob zu lange dauert - splitten des Scripts möglich?

von Maik Riecken -
Anzahl Antworten: 0
"Ob die Sicherung nun (wie in moodle vorgesehen) über einen cronjob angestoßen wird oder ob sich jemand von außen mit einem vielleicht sogar automatisiert laufenden FTP-Tool einloggt, sollte doch für die Serverlast das Gleiche sein, oder?"

Nein. FTP ist für den Datenaustausch optimiert. Das macht kaum Prozessorlast oder benötigt viel RAM. Lediglich ein paar Sockets werden belegt. Das Lastverhältnis "Backup über FTP" vs. "Backup über PHP (Moodle)" liegt mindestens bei 1:20, d.h. letzteres braucht die 20-fache Performance, da ja noch gepackt werden muss, 1000sende von Datenbankabragen via PHP generiert werden usw..

Zum Vergleich:
Ein lokales Sicherungsscript (Shell) braucht bei mir für eine komplette Sicherung der Installation 15-20 Sekunden (incl. Datenbankdump). Der cronjob läuft 4-5 Minuten.

Wenn dein Provider deinen cronjob für dich länger laufen lässt, bedeutet das für ALLE anderen Webseiten von anderen Kunden auf dem Server immense Performanceverluste zu dieser Zeit. Technisch ist das machbar, aber nicht gerecht - du bist ja nicht allein auf der Maschine und wenn du das darfst, müssen das alle anderen ja auch dürfen.

Übrigens kann smartftp Verzeichnisse remote periodisch sichern. Den Datenbankdump solltest manuell mit Bigdump (PHP-Script) anlegen - das ist sicherer. Und noch eine Grundregel: Niemand will ein Backup, alle wollen ein Restore im Schadensfall. Die wenigsten testen aber, ob ihr Backup zu einem Restore taugt...

Gruß,

Maik