Kopano4S (Zarafa 2.0)

[491810]

Sieht schon besser aus ... mal abwarten, ob er den SQL-Import Mängelfrei zu Ende bringt.

 

[491810]

Bekomme folgende Meldung. Danach bekommt Outlook keine MAPI Connection mehr.
Kann mir jemand sagen, wie ich den Fehler im SQL beheben und die Daten retten kann?

 

[491810]

Hat noch wer eine Idee, wie ich das defekte Kopano-backup retten kann?

Macht ihr eigentlich in irgendeiner Form täglich oder wöchentlich Backups der Kopano-Datenbank?

Das dürfte doch ganz simpel über kopano-backup gehen. Da gibt es doch laut Hilfe auch eine Option "--incremental". Hat dad wer eingerichtet

 

[Andy+]

Ich fertige 2 mal täglich ein Backup an und lösche Backups, die älter als eine Woche sind. Das insbesondere auf dem Produktivsystem, jedoch auch auf dem Testsystem. Aus diesem rollierenden System entnehme ich einzelne Backups, zB. jetzt von der Umstellung von

C-Core-8.7.82_Webapp-3.5.9_Z-Push-2.5.1_WMeet-0.29.5

zu

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

um in jedem Falle Sicherheit zu haben.

Die Umstellung hat ansich einwandfrei funktioniert, alles geht, wie zuvor, keinerlei Einschränkung ist ersichtlich. Ich habe nur das Thema, mit der Grössenangabe der Datenbank in phpMyAdmin, die ich bislang nicht nachvollziehen kann. Die Datenbank läuft bei mir auf SSD und im entsprechenden Verzeichnis habe ich gesehen, dass dort die Gesamtgrösse iO. ist. Weshalb nur wird dann in phpMyAdmin die falsche Grösse angezeigt? Auch mit Workbench, HeidiSQL stimmt das nicht überein. Das ist wirklich seltsam.

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

 

[Andy+]

Ich wusste nicht, dass die Angaben abweichen können. Auf dem Testsystem war das genauso, dass die Tabellenanalyse nun die richtigen Werte in phpMyAdmin anzeigt. Die richtigen Angaben nun:

Testsystem (Anhänge im Filesystem)

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


Produktivsystem (Anhänge in Datenbank)

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

 

[491810]

Wie machst Du das Backup denn? Über die Jobs? Oder hast Du das in die Crontab direkt? Mit welchem Befehl?

Ach ja ... Kann mir vielleicht noch jemand sagen, ob ich mein Backup (Fehlermeldung s.o.) und somit alle meine Daten noch retten kann???

 

[Andy+]

Ich mache das zwar alles mit der crontab, das Handling mit dieser Datei ist aber nicht so jedermanns Sache. Im DSM gibt es dafür in der Systemsteuerung den Aufgabenplaner, dort kann man ebenso solche Dinge, vor allem "anwenderfreundlich", hinterlegen. Die Befehle und Zusatzparameter sind dieselben, wie im WebAdmin. Am besten Testen.

.......... Backup (Fehlermeldung s.o.) und somit alle meine Daten noch retten ........

Ich denke, das wird nicht so einfach. Mal Googeln bezüglich Auslesen oder Datenrettung usw.

 

[sky63]

Wie machst Du das Backup denn? Über die Jobs? Oder hast Du das in die Crontab direkt? Mit welchem Befehl?

Ach ja ... Kann mir vielleicht noch jemand sagen, ob ich mein Backup (Fehlermeldung s.o.) und somit alle meine Daten noch retten kann???

Hast du denn mal reingeschaut in das SQL-File?

gruss,
sky

 

[491810]

Muss ich noch machen. Die Frage ist, wie "schaue" ich in ein 2,5GB großes SQL File rein? Import in SQL-Lite? Für Notepad++ ist das ja zu groß.

 

[Andy+]

Versuch mal mit Excel, damit können auch DBase-Datenbanken gelesen werden.

 

[sky63]

Muss ich noch machen. Die Frage ist, wie "schaue" ich in ein 2,5GB großes SQL File rein? Import in SQL-Lite? Für Notepad++ ist das ja zu groß.

Auf der Kommandozeile der Syno mit less <Dateiname>

 

[491810]

Kann ich Kopano4s für Testzwecken auch auf einer alten DS411 Slim installieren? Oder geht Docker oder MariaDB10 nicht auf der alten Maschine? Dann kann ich da mal rumspielen und mein Backup reparieren. Den "Validierungsfehler" hatte ich übrigens auch beim entpacken des Dumps unter Windows nachdem ich unter 1.04 einen frischen Dump gemacht hatte. Oder hat kopano-backup hier einen Fehler? Ich nehme eher mal an, dass mir unter Windows ein Parameter beim entpacken fehlte, oder? Ebenso unter Linux. Denn auch auf der Synology bekam ich beim entpacken mit Gunzip den gleichen Validierungsfehler.

 

[Andy+]

Da musst Du Dich erkundigen und testen.

 

[sky63]

....Denn auch auf der Synology bekam ich beim entpacken mit Gunzip den gleichen Validierungsfehler.

Das kopano4s-backup restore <timestamp> hat doch sauber entpackt(so würde ich jedenfalls den Screenshot interpretieren). Also würde ich jetzt mal in das kopna4s-backup script schauen was da aufgerufen wird und dann den gleichen Aufruf auf der Kommandozeile machen.

gruss,
sky

 

[491810]

Ihr würdet mi hier sehr helfen, wenn mir mal jemand sagen würde, WIE ich den Inhalt des .gz-Archives aufrufen und editieren kann, um den Fehler in Zeile 3543 prüfen zu können.
Ich habe mir Ultraedit runtergeladen. Das kann zwar das .sql File laden. Da sehe ich aber nur Maschinencode. Da kann man ja 0,0 lesen. Und mit SQL-Lite geht der Import nicht.

Gerne schaue ich mir auch das Skript vom Kopano-backup an. Das muss ich erstmal finden. Vielleicht lasst ihr mich nicht im Dunklen tappen sondern gebt mir auch die Information.
Ich würde nämlich gerne schnell ans Ziel kommen und mir nicht erst alle Daten zusammensuchen müssen. Mit welchen Programm kann ich die SQL-Dump denn nun editieren ????

Vielleicht kann mir auch jemand sagen, was ich editieren muss, damit ich das nicht in Kopano Schemata zurücksichere (und mir meinen Emailserver wieder grille) sondern in ein neues
Schemata, damit ich die Daten erstmal ansehen kann. Daher hatte ich ja auch gefragt, ob Kopano4s (und somit auch Docker und MariaDB10) auf einer veralteten Synology DS411s läuft.

 

[sky63]

Du hast doch das Backup-Script ausgeführt dann weisst du doch auch wo es liegt?!?. Egal. Ich hab gerade keinen Zugriff auf meine Kiste, kann also nicht in das Backup-Script schauen. Ich schaue heute Abend mal nach wie das Script das *.gz erstellt und mit welchen Optionen wieder entpackt. Mit der gepackten Datei kannst du natürlich im Editor nichts anfangen. Du brauchst die entpackte SQL-Datei und da kann man dann mal reinschauen was denn da nicht geht.

gruss,
sky

 

[491810]

Den Befehl "kopano-backup" kannst Du direkt - egal wo Du stehst - ausführen. Ist in den Umgebungsvariablen gesetzt.
Muss mich da jetzt wieder durchgoogeln, wie man die Einstellungen unter Linux (speziell auf der Syno) aufrufen kann.
Daher hatte ich ja gefragt, wo die liegt. Denn in /etc/kopano und /volume1/kopano" konnte ich das Script nicht ad hoc finden.
Ich habe auch schon versucht, das Dump via myphpadmin zu importieren. Das lässt aber nur 1024MB File Size zu.
Habe jetzt mal die php.ini in /etc/php/ so angepasst, dass er nun mehr als 4GB zuläßt und die Uploaddauer hoch gesetzt:

max_execution_time = 240
max_input_time = 240
memory_limit = 1024M
post_max_size = 4096M
upload_max_filesize = 4096M
[/QUOTE]

Jetzt muss ich nur noch warten, bis der Import meines letzten (über 1 Jahr alten) PST Datei abgeschlossen ist damit ich
dann PHP neu starten kann, um zu sehen, ob das greift. Dann werde ich das Dump in die Datenbank "kopano2" importieren.
Die habe ich mir extra dafür parallel im phpmyadmin angelegt. Hast Du sonst eine Idee, wie ich in das Dump schauen kann?

 

[sky63]

Nochmal. Da kannst du nur sinnvoll reinschauen wenn du das *.gz entpackt hast.
Hast du die *.gz noch auf der Syno liegen? Dann 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. Im Zweifel auf der Kommandozeile mit more oder auch vi.

Du kannst den dump dann aber auch mal versuchen in eine andere Datenbank zu pumpen mit Ausgabe dann siehst du eventuell wo das fehlschlägt. Aber du brauchst erst die entpackte Datei

Hattest du nicht gesagt du hast das backup mit kopano4s-backup gemacht?

gruss,
sky

 

[491810]

Dank Dir. Das probiere ich morgen mal aus. Wobei mein kopano-backup "nur" 1.3GB gepackt hat ohne eine attachment. Gz Datei. Das hat er diesmal erzeugt. Wobei das dump hier nur knapp 800mb war. Kann das sein? Dann wäre er damals nach dem dump vor erstellen der attachments.gz abgebrochen worden? Was würde passieren wenn das so wäre? Kann ich dann dennoch Inhalte aus dem dump retten wie Notizen oder das Adressbuch? Oder liegt das verschlüsselt ab. Nein, oder?

 

[sky63]

Verschlüsselt nein. Aber ich glaub wir müssen nochmal genau auflisten was du gemacht hast und was für Dateien du hast.

Ich hatte verstanden das du ein kopano4s-backup ausgeführt hast. Wenn das so ist was liegt dann unter </volume>/kopano/backup?