Kopano4S (Zarafa 2.0)

[491810]

Am 28.08. hatte ich ein kopano-backup ausgeführt bevor ich die Datenbank Schema "kopano" gelöscht und die Kopano4s v1.04b deinstalliert habe.
Das Dumb ist 1,303.808 MB, heißt "dumb-kopano-201908281635.sql.gz". Entpackt war die darin enthaltene SQL Datei dann 2.567.874 MB groß.

Nachdem ich heute den Kopano4s v1.04 wieder installiert hatte und alles lief habe ich die über 1 Jahr alten vier PSTs in meine vier Postfächer entladen,
dann eine kopano4s-backup erstellt. Das hat eine dumb-kopano-201909021942.sql.gz (817.484 MB) und attachments-201909021942.sql.gz (9.713.109MB)



Worin (sorry für die Frage) liegt der Unterschied zwischen einem kopano-backup und einem kopano4s-backup? Was ich bemerkt habe ist, dass das
kopano4s-backup nebst dem dumb-kopano-xxxxxxxxxxxx.sql.gz zusätzlich auch noch eine attachmets-kopano-xxxxxxxxxxxx.sql.gz mit erstellt hat.

Oder hätte das auch das kopano-backup getan? Dann würde das ja bedeuten, dass das kopano-backup vom 28.08. nicht korrekt beendet worden ist (?)
Das würde dann auch erklären, warum der Import schief gelaufen ist. Da hätte mir hier ja die attachments-kopano-xxxxxxxxxxxx.sql.gz Datei gefehlt.

Denn die PST Dateien (kann man jetzt nicht 1:1 umsetzen aber als Anhaltspunkt schon mal eine größe zum Vergleich) sind insgesamt knapp 17GB groß.

 

[goetz]

Hallo,
@491810
bitte keine Vollzitate und erst recht nicht wenn Du direkt antwortest.
Danke.

Gruß Götz

 

[491810]

[...] wechsel mal in das Verzeichnis wo sie liegt und mach da ein
gunzip dump-kopano-<TS>.sql.gz. Das Ergebnis sollte eine Datei dump-kopano-<TS>.sql sein. Und da kannst du mit einem Editor reinschauen. [...]
gruss,
sky

Endet auch mit dem gleichen Fehler wie wenn ich es liokal mit 7-Zip entpacke - nur das ich dann wenigstens ein entpacktes SQL habe. Hier entpackt er garnichts erst.

 

[Andy+]

Im Falle des "kopano-backup" werden in dem von Dir gezeigten Verzeichnis entsprechende Unterverzeichnisse mit dem jeweiligen Usernamen angelegt und darin wiederum die einzelnen emails abgelegt, in codierter Form. Im Screen kann man im Hintergrund die 4 User als Verzeichnisse erkennen.

Dagegen "kopano4s-backup" macht genau das von Dir beschriebene. Da ich im Rahmen meiner Umsetzung auf die Stable meine DS´n eine mit, eine ohne Datenablage im Filesystem konfiguriert habe, hat jene mit "mit" genau dasselbe gemacht. Ob das nun in früheren Versionen als der v1.0.4 genauso war, weiss ich nicht, da ich das noch nie getestet habe und die Anhangablage in der Datenbank auch beibehalten werde. Ich fühle mich damit sicherer.

Mit "kopano-backup" habe ich bislang keine Erfahrungen gemacht. Damit verbunden habe ich immer wieder Abbrüche und andere Unvollständigkeiten erlebt, letztlich, darauf verlassen habe ich mich noch nie. Bislang habe ich daher Sypex Dumper eingesetzt für Backups und Wiederherstellungen. Das Modul "kopano4s-backup" ist jedoch genauso gut, ich werde das mal eingehend testen und anstatt Sypex Dumper einsetzen. Sypex Dumper verwende ich nun seit einigen Jahren, jedoch "kopano4s-backup" fühlt sich kopanoiger cool an.

 

[491810]

Okay. Das erklärt es dann. Ich hatte nach dem kopano-backup nur die Zip Datei aber nicht die Ordner kopiert. Und beim deinstallieren hatte ich die Haken nicht drin gelassen, da ich ja eine Sicherung hatte. Und dann löscht er leider den /volume1/kopano Ordner mitsamt dem Unterordner /backup mit. Sehr unschön. Sollte man anders programmieren. Dennoch. Das kopano-backup habe ich danach nochmal laufen lassen (daher habe ich ja die erstellten Ordner bemerkt). Das Gz-File kann ich jedoch in beiden Fällen nicht entpacken. Jedes Mal bekomme ich den oben angezeigten Fehler. Ist da was mit dem kopano-backup Skript nicht in Ordnung???

 

[Andy+]

........ Gz-File kann ich jedoch in beiden Fällen nicht entpacken......

Betrifft "kopano4s-backup"

 

[491810]

Die erste Sicherung hatte ich aber definitiv mit "kopano-backup" gemacht. Da hatte ich aber nur das dump und nicht die Ordner gesichert. Und das kann ich auch nicht fehlerfrei auspacken. Wenn ich es auspacken und die sql Datei öffne kann ich nur Maschinencode sehen. Per myphpadmin kann ich die Datei auch nicht importieren da sie größer als 1024MB ist. Habe gestern mal die php.ini angepasst und höher gesetzt. Muss nach der Arbeit mal den Server neu starten. Dann mal sehen, ob es geht. Habe den Wert auf 4096MB hoch gesetzt.

 

[sky63]

erstens: Bitte mal gunzip -v <Dateiname> und das Ergebnis mitteilen.
zweitens: Ich weiss gerade nicht ob zcat installiert ist auf der Syno aber versuche mal zcat <Dateiname> und teile das Ergebnis mit. Wenn zcat nicht verfügbar versuche zless.
gruss
sky

 

[491810]

Zu 1.) probiere ich aus. Zu 2.) zcat ist installiert. Hatte ich auch schon probiert (Bild siehe einer meiner vorherigen Postings einige Seiten zurück). Ging auch nicht.

 

[sky63]

Du hattest bei deinem zcat eine Umleitung in eine Datei gemacht. Steht in der Datei anschließend was drin?

 

[Andy+]

Du kannst auch mal versuchen, die SQL-Dateien mit Workbench oder HeidiSQL zu öffnen. Das sind mit die besten Programme, die auf Windows laufen.

 

[sky63]

Du kannst auch mal versuchen, die SQL-Dateien mit Workbench oder HeidiSQL zu öffnen. Das sind mit die besten Programme, die auf Windows laufen.

Er hat doch keine vernünftige SQL-Datei. Er hat doch nur die gz die sich nicht bzw. nur mit Fehlern entpacken lässt.

 

[Andy+]

............Nachdem ich in phpMyAdmin eine Tabellenanalyse durchgeführt habe, stimmt es wieder überein mit rund 10 GB, damit ist alles iO..........

Diesen Vorgang habe ich heute wiederholt. In phpMyAdmin habe ich in der Datenbank von Kopano alle Tabellen markiert, unten über "Alle markieren" und dann im Auswahlmenü über "Analyse Tabelle" den Vorgang ausgelöst. Es war auch alles okay.

Jedoch wurde die Grösse erneut korrigiert. Ich hatte auch einiges laufen diese Tage, ist auch plausibel soweit. Ich Frage mich nur, weshalb in phpMyAdmin nicht gleich die korrekten Werte angezeigt werden, denn dort, wo die Datenbank abgelegt ist, stimmt es in der Summe in etwa überein mit der Angabe in phpMyAdmin, wenn die obige Analyse abgeschlossen ist.

Als zweites habe ich zur Zeit eine CPU-Belegung von über 20% nur auf MariaDB 10. Ich habe zwar 14, davon 6 gerade nicht aktive Datenbanken, im Zusammenhang jedoch m.E. nennenswert ist Kopano, Nextcloud, Owncloud und Wordpress. Wie sind bei euch die Werte im Schnitt?

 

[honk013]

Moin Moin,
auch ich, als nahezu IT-Vollpfosten, möchte mich jetzt an das Downgrade wagen.
Vorgehensweise ist einigermaßen klar.
Frage haben ich aber trotzdem noch:
1. Tosoboso hat in einem Post geschrieben (keine Ahnung wo; habe so viel gelesen...) das man den Verlauf bzw. das Ergebnis von den Admin GUI K-CMD Befehlen ("kopano-backup" und "kopano4s-downgrad") in einem Log-file überprüfen kann. Also Befehl starten und nach einiger Zeit in dem Log-file nachschauen, ob der Task beendet ist und wie das Ergebnis ist. Frage: Wo finde ich diese Log-files und was muss bei erfolgreichem Ergebnis darin stehen?
2. Nach erfolgreichem Downgrade und anschließendem installieren der Version 1.0.4 (ohne Beta!!), was muss dann noch gemacht werden? Da war doch was mit USER wiederherstellen, oder so? Wird das jetzt alles durch den kopano4s-downgrad-Befehl gemacht?

Vielen Dank und fingers crossed

 

[Andy+]

Nach meinem Verständnis musst Du da nichts mehr machen. Nach dem Downgrade vlt. ein Reboot, aber dann sollte das laufen. Backup machen vorher von allem, für alle Fälle. Ich habe Downgrade einige male gestartet, aber meine Datenbank hatte irgendwo einen Fehler und das blieb immer wieder hängen. Daher habe ich schlussendlich die Outlook-Methode gewählt mit dem Zarafa-Client. Dort gab es auch einmal einen Hänger, den ich durch Übertragungswiederholung beheben konnte und einen zweiten durch Ignorieren. Dann lief das dann durch. Ansonsten hätte ich das gerne schon auch mit dem Downgrade erledigen wollen.

Andererseits, wenn man nur einen Account auf Kopano hat, ist das auch eine gute Methode, wenns hakt, wie bei mir: Mit ZC im Offlinemodus den kompletten Inhalt rüberholen in Outlook, in eine PST exportieren, die Community komplett deinstallieren, die Stable installieren, ZC connecten, PST importieren und zusehen, dass alles wieder drüben ist. Hat bei 11 GB und zwei Accounts etwas gedauert, war aber auch nicht übel.

Ich habe gestern erst mit ActiveSync wieder erlebt, dass das zwar grundsätzlich läuft, aber es ist einfach aus der Reihe zu bringen und dann ist das nicht mehr Synchron und ein neues Anlegen der Outlook-OST ist erforderlich. Daher sollte man besser mit dem ZC arbeiten, welches einfach zuverlässiger ist. Und wenn AS, dann starten und nicht anfassen, bis der erste Sync vollständig abgeschlossen ist, dann mag das wohl gut sein.

Im Ergebnis ist meine ehemals fragmentierte Datenbank nun rund 11 GB statt 23 GB gross, im Grunde seit ZarafaJD hatte ich noch nie einen solchen Datentausch gemacht, hat sich aber gelohnt.

 

[491810]

Nach meinem Erfahrungen folgende Vorgehensweise:

1. Entweder mit "kopano-backup" die Datenbank sichern. Dann die Datei "dump-kopano2019xxxxxxx.gz inklusive der Unterordner sichern, die mit angelegt wurden lokal runterkopieren (Zur Sicherheit) . Da sind nämlich die Anhänger drin. Oder gleich mit" kopano4s-backup" sichern und die "dump-kopano2019xxxxxxx.gz und die attachments-kopano-2019xxxxx.gz runterladen.

2.) kopano-downgrade aus dem Kopano-Admin im Gui ausführen. Wenn das - wie bei mir - nicht klappt - Kopano deinstallieren. Wichtig : die Haken bei der Deinstallation für die Sicherung belassen! Sonst ist Der komplette "/kopano" Ordner im "/volume1" weg und somit auch der Unterordner "/backup" mit Deiner Sicherung. Nach der Deinstallation Kopano4s in der v1. 04 stable per "manueller Installation" hochladen und installieren.

3. Datenbank "kopano" über phpmyadmin löschen

4. Alle Parameter wie bei der Erstinstallation eingeben und danach über die Kopano Admin Gui in K-CMD den "kopano-restore" eingeben.

Sollte so passen. Falls ich was vergessen habe mich gerne korrigieren.

 

[Andy+]

Vorsicht (!) im Umgang mit "kopano-backup" und "kopano4s-backup" und "kopano-restore":

"kopano-backup" legt Unterverzeichnisse an mit den Usern, keine *.sql.gz

"kopano4s-backup" legt nur *.sql.gz an, eine, wenn die Anhänge in der Datenbank sind, zwei, wenn die Anhänge im Filesystem sind (1 gz für Datenbank, 1 gz für Anhänge)

"kopano-restore" hat als Voraussetzung "kopano-backup", um rücksichern zu können, daher hängen diese zusammen.

 

[honk013]

Nach meinem Verständnis musst Du da nichts mehr machen. Nach dem Downgrade vlt. ein Reboot, aber dann sollte das laufen. Backup machen vorher von allem, für alle Fälle.

Moin Andy,

habe gerade erst einmal auf die Version 1.0.4Beta upgedated; so wie Du es mir beigebracht hast. Das hat schon mal funktioniert.
Jetzt werde ich mal das "kopano-backup" anstoßen. Weißt Du, welches Log-file Tosoboso gemeint hat und wo das liegt? Ich würde gerne nach dem Anstoßen der Arbeiten und vor dem nächsten Schritt immer überprüfen, ob der vorhergehende Task richtig beendet wurde!

Und was die Backups angeht; Du weißt doch, dass ich etwas paranoid bin. Besser fünf Backups zu viel, als eins zu wenig

VG
Frank

 

[491810]

Besser paranoid ... sonst geht es Dir wie mir. Hast ein Backup, kanntest Dich nicht aus und wusstest nicht, dass Du die Odner ebenfalls runterladen musst und wusstest ebenfalls nicht, dass wenn Du die Haken beim Deinstallieren von Kopano der Ordner mit Deinem Backup verschwindet und Du bist am Ende im Arach und kannst froh sein wenn Du PST Sicherungen hast die ein Jahr alt sind. Passiert mir auch nicht nochmal.

 

[Andy+]

Mit "kopano-backup" bekomme ich nach wie vor keinen schlüssigen Ablauf hin, die Geschichte startet und bleibt nach einigen Minuten irgendwo stehen. Mit "kopano4s-backup" ist das anders, das läuft. Ich weiss nicht, woran das liegt.

Ich denke das Problem liegt in der Datenbank. Im Verzeichnis

/volume1/kopano/backup/backup-user.log

liegt die LOG dafür und hat lauter Einträge, wie

2019-09-05 19:50:46,807 - backup - ERROR - Too many retries, skipping change
2019-09-05 19:50:46,908 - backup - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=0/5)
2019-09-05 19:50:49,483 - backup - WARNING - Received a MAPI error or timeout (error=0x8004010f, retry=4/5)
2019-09-05 19:50:53,428 - backup - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=1/5)
2019-09-05 19:50:55,973 - backup - WARNING - Received a MAPI error or timeout (error=0x8004010f, retry=5/5)
2019-09-05 19:51:00,033 - backup - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=2/5)

Da weiss ich nicht weiter. Deshalb geht es da nicht weiter. Das hatte ich in der Konsole auch schon gesehen.