Kopano4S (Zarafa 2.0)

[Andy+]

Ich habe die beiden Vorgänge "kopano-backup" und "kopano-downgrade" hintereinander in einen Task im Aufgabenplaner hinterlegt und gestartet. Der Start erfolgte auch, jedoch hat das Backup wohl nach rund 15 Minuten angehalten. Ich weiss nicht warum, jedenfalls ist es unvollständig und die Ausführungskette wurde abgebrochen.

 

[491810]

Also ich bekomme auch unter der 1.03 noch immer die daily logrotate Fehlermeldung
Ich dachte, die wäre mit der 1.01 oder 1.02 Vergangenheit. Still a work in progress (?)

 

[Tosoboso]

Neues Paket k4s v. 1.0.4

Hallo zusammen,
ein neues Paket k4s. v.1.0.4 wurde hochgeladen auf cphub.net und wartet auf die Freigabe. Es ist ein Bug-Fix bzgl. User Anlegen, siehe hier: https://www.synology-forum.de/showthread.html?103396-User-anlegen
EDIT das Paket is nun seit 20:45 verfügbar
-TosoBoso

 

[491810]

Löst das auch das Problem mit dem Mobile Device Plugin in der v1. 03? Oder war da die Lösung die gleiche wie damals schon als das Problem auch bereits einmal auftrat (muss ich mir Mut nochmal raus suchen, wie das behoben werden musste)?

 

[Tosoboso]

Hi, MDM funktionert m.W. seit einigen Relases. Bei Neuinstallation wird die Plug-In-Config richtig gesetzt, sonst muss man im mdm-plug in Folgendes setzen: define('PLUGIN_MDM_SERVER', 'localhost:9080');
-TosoBoso

 

[Andy+]

Irgendwas war für mich nicht so ganz nachvollziehbar an meiner Datenbank. Daher habe ich alle Inhalt über den Zarafa-Client in eine PST exportiert, die D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1_WMeet-0.29.5 installiert und wieder importiert. Das funktionierte auch alles, nur eines kann ich mir nicht erklären:

Die Datenbankexport auf dem Rechner ist für mich nachvollziehbare rund 10 GB gross. Auf meinem Testsystem habe ich die attachments im Filesystem, auf dem Produktivsystem in der Datenbank. Und wenn ich vom Produktivsystem die Datenbank sichere, ist diese ca. ebenso rund 10 GB gross

Wenn ich jedoch in phpMyAdmin schaue, ist diese nur rund 1,5 GB (!) gross. Wie kann das sein? Ist diese komprimiert? Ich habe dafür keine Erklärung, da bislang auch dort die Grösse rund 10 GB betragen hätte. Und wie gesagt, die Sicherung hiervon unkomprimiert, ist rund 10 GB gross. Die komprimierte Version ist rund 6,7 GB gross.

 

[491810]

Boah ... jetzt habe ich den "kopano-backup" laufen lassen und wollte dann den "kopano4s-downgrade start" laufen lassen.

Wollte er dann erstmal ein Backup (hatte ich doch schon gemacht. Und ich schon die DB gedropped. Toll). also den anderen.

Also habe ich den "kopano4s-restore-user" versucht. Auch Fehlanzeige. Also Kopano4s beta deinstalliert und stable 1.04 installiert.

Jetzt wollte ich statt dem Docker Kopano4s neu installieren. Da bekam ich dann erstmal eine dumme Fehlermeldung angezeigt:



Nachdem ich das jetzt als Docker-Image installiert habe und er auch gestartet ist bekomme ich die folgende Fehlermeldung:



Was will er denn jetzt? Bekomme ich wenn ich versuche Webapp aufzurufen. Mein SSL Zertifikat muss ich natürlich noch einbinden.

Vielleicht kann mir mal jemand sagen, was hier los ist. Lokal nicht installierbar. Docker startet aber config.php fehlt. Was ist hier los???

 

[Andy+]

...... D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1_WMeet-0.29.5 .........

Nochmal zum Überblick

Testsystem (Anhänge im Filesystem)

Postfachgrösse WebAdmin 9 GB
Outlook Postfachgrösse 10,69 GB
Datenbanksicherung unkomprimiert 1,34 GB
Datenbanksicherung komprimiert 0,24 GB
Anhänge komprimiert 6,34 GB
Datenbankgrösse in phpMyAdmin 0,62 GB


Produktivsystem (Anhänge in Datenbank)

Postfachgrösse WebAdmin 9 GB
Outlook Postfachgrösse 10,71 GB
Datenbanksicherung unkomprimiert 10,27 GB
Datenbanksicherung komprimiert 6,64 GB
Anhänge in der Datenbank -- GB
Datenbankgrösse in phpMyAdmin 1,6 GB

Die Datenbankgrösse in phpMyAdmin sollte ebenso ca. zwischen 9-10 GB liegen. Wo ist der Rest von ca. 8 GB sichtbar?

 

[491810]

Ich nochmal. ich habe jetzt die 1.04 sauber installiert. Webapp läuft jetzt auch sauber. Kein config.php Fehler mehr. Soweit so gut.
Jetzt habe ich beim deinstallieren aber - da er ja den Backup gemacht hat - die Haken für die Sicherung der Config rausgenommen.

Dabei scheint er den Ordner /backup nicht behalten zu haben (wusste ich nicht). Aber ich habe die Sicherung vorher auf lokal kopiert.
Die habe ich dann in den Ordner /backup zurück kopiert. Restore eines 1,3GB große Backup von vier Postfächern in 3 Sekunden ???





Das hat dann wohl eher nicht geklappt. Die Accounts sind auch nicht wiederhergestellt. Oder muss ich die vorher extra noch anlegen?

Nachtrag: Habe jetzt die vier Postfächer vorher wieder angelegt und den "kopano-restore-user all" laufen lassen. Auch direkt fertig.
Er macht also keinen Restore. Jetzt habe ich zwar die vier Accounts wieder. Aber leer. Wie bekomme ich die Daten wieder restored???

 

[Tosoboso]

Wollte er dann erstmal ein Backup (hatte ich doch schon gemacht. Und ich schon die DB gedropped. Also habe ich den "kopano4s-restore-user" versucht. Auch Fehlanzeige. Also Kopano4s beta deinstalliert und stable 1.04 installiert.
Jetzt wollte ich statt dem Docker Kopano4s neu installieren. Da bekam ich dann erstmal eine dumme Fehlermeldung angezeigt: "Fatal Build Error Download Unavailable https://serial@download.kopano.io/supported/coder:/"

Hi die Fehlermeldung bedeutet, dass du versucht die Kopano Supported Stabe Edition zu laden, anstatt der Default. Für die Supported Edition bruachst due eine echte Serien-Nr und nicht einfach "serial" (bitte die Fehlermeldung bei echter SNR nicht posten)
Also versuche doch bitte die Default zu Laden. Ebenso funktioniert bei der k4s v.1.0.4 der Downgrade in einem Stück. Also bitte nochmals die k4s beta 1-0.4 istallieren, per Datenbank restaurieren (>kopano4s-backup restore TS) und dann in einem Rutsch den Downgrade via kopano-backup und kopano4s-downgrade.
TosoBoso

 

[491810]

Dann ist da was falsch programmiert. Ich hatte den Haken auf der "Community" Edition belassen und nicht mal angerührt. Eine "supported" habe ich ja nicht. Dafür müsste ich ja auch die Seriennummer eintragen.
Als ich dann das Docker anstelle das lokale Image (ich wollte diese 443->9443 Port-Umleitung und Reverse-Proxy mir sparen) angeklickt hatte hat er auch (im 3. Anlauf) das Image sauber runtergeladen und installiert.
Leider bekomme ich jetzt mein Dump meiner vier Postfächer (s.o.) nicht mehr restored. Kannst Du mir hier noch helfen? Sonst habe ich alle meine Emails verloren. Hätte sonst nur noch 1-2 Jahre alte PST-Files.

 

[Andy+]

Da ist nichts falsch programmiert, beide SPKs sind korrekt. Nimmst Du die v1.0.4, wird das Image für die Default und bei der v1.0.4b wird das Image für die Community angezogen.

Ansonsten würde ich Deine lokale Backupkopie mit 7-zip mal entpacken und zusehen, was drin ist.

 

[491810]

Schaue ich gleich mal nach. Gemacht habe ich sie in der 1.03b mit dem Befehl "kopano-backup" und wollte sie jetzt in der 1.04 mit "kopano-restore-user" wiederherstellen. Oder habe ich da was falsch gemacht? Habe gesehen im K-CMD gibt es auch noch ein "kopano4s-backup". Was macht das denn???

Nachtrag:
habe eben mal das dump entpackt. Und bei 99% erzählt der mir "unerwartetes Datenende". Ist jetzt nicht wahr, oder? Wieso das denn??? Wurde anstandsfrei rüber kopiert.



Er hat aber ein rund 2,5GB große SQL Datei entpackt. Kann ich die irgendwie auf Konsistenz überprüfen und vy phpmyadmin direkt in die Kopano Schema importieren ???

 

[Andy+]

........"kopano4s-backup"......

.....fertigt von allen Usern ein Backup an als 1 Datei. Das finde ich zB. besser.

 

[491810]

Okay. Dafür ist es jetzt ja nachweislich zu spät. Kann ich mit der via 7-Zip extrahierten SQL Datei irgendwie die Daten restoren? Wenn ja, wie?

Ich habe mal probiert, das dump auf der Synology und packe es dann erneut zu packen. Bekomme hier aber leider die selbe Meldung angezeigt:



Macht es Sinn die Datei, die ich lokal mit 2,5GB rausbekommen habe, auf Linux neu zu packen? Oder sind die Daten in den 2,5GB nicht konsistent?

 

[Tosoboso]

Ich nochmal. ich habe jetzt die 1.04 sauber installiert. ... Restore eines 1,3GB große Backup von vier Postfächern in 3 Sekunden ???
Nachtrag: Habe jetzt die vier Postfächer vorher wieder angelegt und den "kopano-restore-user all" laufen lassen. Auch direkt fertig. Er macht also keinen Restore. Jetzt habe ich zwar die vier Accounts wieder. Aber leer. Wie bekomme ich die Daten wieder restored???

Nein, das dauert nich 3 Sekunden, sondern ist ein Heintergrund / long running Background Job. In den Logfiles sieht man dann, wenn die Aktionen abgeschlossen sind und bekommt ggf. auch eine Synology Nachricht.
In dem Fall wie Oben macht man ein >tail -f /volume1/kopano/backup/restore-user.log von der Kommandozeile aus, um den Fortschritt zu verfolgen. So ein Job kann locker 1 Stunden dauern.
-TosoBoso

 

[491810]

Wie erwähnt (s.o.) scheint es Probleme mit dem dump File zu geben. Bekomme hier die Meldung "dump-kopano-201908281635.sql.gz: unexpected end of file".
Konnte es lokal mit 7-Zip entpacken und bekam so das SQL File. Aber auch hier die Meldung. Nun weiß ich nicht, ob die entpackten Daten nun konsistent sind (?)
Ich versuch es gerade mit "zcat dump-kopano-201908281635.sql.gz > log" in eine Datei umzuleiten, um diese dann zu nehmen. Aber auch hier die gleiche Meldung:



Geht es denn wenn ich die Datei "dump-kopano-201908281635.sql" neu zu einer "dump-kopano-201908281635.sql.gz" zippe und dann nochmal kopano-restore-user ausführe?

 

[Tosoboso]

Okay. Dafür ist es jetzt ja nachweislich zu spät. Kann ich mit der via 7-Zip extrahierten SQL Datei irgendwie die Daten restoren? Wenn ja, wie?

Arrg bitte nicht fie Datei auspacken und Ändern. Statt dessen: >kopano4s-backup restore 201908281635 Ausführen; am besten von der Kommandozeile aus. Der 2. Parameter ist der Timestamp des Datenbank-Backups.
Übrigens wird so ein Datenbank-Backup von kopano4s-downgrade Erstellt, als Fallback..
EDIT: was passiert bei Ausführen von kopano4s-backup restore, wie oben beschrieben? Auch unexpected EOF? Das backup / restore Skript verwendent übrigens gunzip und nicht 7Zip und Ja das Ergebnis ist eine SQL Datei
-TosoBoso

 

[491810]

Dank Dir. Probiere ich gleich mal aus. Dürfte er das auch mit dem "unexpected end of file" importiert bekommen?
Das "kopano4s-downgrade" funktionierte bei mir nicht richtig. Daher habe ich das Schema gedropped, dann das
Paket deinstalliert und neu installiert. Dann hatte ich versucht den Restore zu machen. Aber der war ja sofort fertig.
Als ich dann - was Andy+ vorgeschlagen hatte - das dump lokal mit 7-zip entpackt habe bekam ich die Fehlermeldung.

 

[Andy+]

......Wo ist der Rest von ca. 8 GB sichtbar?.......[/B]

Könnte es sein, wenn Anhänge in der Datenbank ablegen angewählt ist, die Anhänge zwar dann nicht mehr im rdner "attachments" abgelegt wird, dann aber vlt. in der Containerumgebung?