Also ich hab mit Akeeba nur negative Erfahrungen gemacht und nutze es nicht mehr!
EJB erstellt ein komplttes Zip und/oder ein DB Backup. wer das Zip nicht auf dem Server entpacken lassen kann muss es halt runter laden (was bei einen ZIP immer noch wesentlich schneller geht als alle Dateien einzeln) und lokal entpacken und wieder hoch laden.
Man hat aber eine Sicherung - und das relativ flott!
und lokal entpacken und wieder hoch laden.
Aber da ging es doch drum! Dass der TE ewig lange Uploadzeiten hat. Seine Frage war, wie man möglichst nur serverseitig arbeiten kann. Und Zeit sparen kann. Kein Tool entpackt so schnell wie Akeeba B seine jpa-Archive. Ist halt mal so... Und, wenn der Provider Dateigrößen-Limits hat, muss man eben splitten können.
Kopier- und Uploadzeiten sind mit Einzeldateien weitaus größer als wenige Archivdateien, selbst, wenn sie in Summe die selbe Größe haben.
PHP-ZIP-Entpacker laufen oft in's time_limit und sind so nutzlos.
Ich bin bekanntermaßen kein großer Freund von Akeeba, eher, weil der Chef dort etwas "arg arrogant" ist (wie man auch am einen oder anderen Kommentar in seinen Codes sehen kann 
), dennoch arbeite ich viel damit, auch, weil es für viele meiner Kunden einfach die praktikabelste Lösung ist.
Bei der Verwendung selbst hatte ich noch nie Probleme, außer, mal ein kaputtes Archiv, was einem mit EJB-Archiv auch passieren kann, wie ein Job zeigte, den ich kürzlich gemacht habe (Wiederherstellen einer Seite aus unvollständigem Archiv.)
Und bei fehlerhafter Konfiguration wie bspw. bei Strato regelmäßig zu sehen. Da bin ich auch kein Freund von, BTW.
Aber da ging es doch drum! Dass der TE ewig lange Uploadzeiten hat.
Bestreitet ja keiner, aber kann ja sein dass er auf dem Server entpacken kann, und dann hat er eine schnelle Lösung - Wissen wir beide ja nicht
Damit entpacke ich auf dem Server: https://joomla-extensions.kubi…p-script-for-zip-archives
Danke für die vielen Meldungen.
Nein, ich kann nicht auf dem Server entpacken.
Ich konnte den Fehler jetzt eingrenzen. Dabei ist es völlig egal, ob ich von 3.5.1 auf 3.6.0, 3.6.1 oder 3.6.2 update.
Es liegt definitiv am Update der Datenbank von 3.5.1 auf eine höhere Version.
Sobald ich auf "Reparieren" klicke, ist die Installation nicht mehr lauffähig.
Es treten die oben benannten Fehler auf.
Solange ich die DB-Reparatur nicht durchführe, funktioniert das geupdatete Joomla auch unter V 3.6.0 bis 3.6.2
Hm, das ist ein bisschen komisch, weil die Dateien in 3. und 4. Zeile der Meldung sich ja genau darum kümmern sollen, dass die fehlenden Spalten hinzugefügt werden.
Ist dein Speicherplatz vielleicht aufgebraucht? Was ja auch die Datenbanken betrifft.
Kannst jetzt nat. versuchen anhand der beiden genannten Dateien in
/administrator/components/com_admin/sql/updates/mysql/
die Spalten selbst anzulegen.
Poste mal die paar Zeilen unter
System > Systeminformationen > Reiter Systeminformationen
Ansonsten bleib ich bei dem Vorschlag, die Seite wie sie jetzt ist oder halt die 3.5.1 mit Akeeba-Backup zu sichern, lokal mit XAMPP (PHP-Version 5.4), UWamp oder ähnlich, mit Akeeba kickstart.php zu installieren, dann updaten, wieder mit Akeeba-Backup sichern und auf dem Server mit Akeeba kickstart.php installieren.
Schalte nach Installatio von Akeeba-Backup das Plugin
System - Backup on update | system | backuponupdate
unbedingt aus. Es wird dich in deiner Situation nur zu Tode nerven.
