Hallo Michael,
bei Ausführung des Backups wird für jeden Nutzer ein Unterordner angelegt. Wenn es also einen Nutzer “abc” gibt, dann befindet sich nach dem Backup ein Ordner “abc” in dem aktuellen Verzeichnis.
Ein Restore ist dann ein “kopano-backup --restore -u abc abc/” (wieder aus dem selben Verzeichnis). Sollte abc auf dem neuen System anders heißen, muss “-u abc” entsprechend angepasst werden.
OK. Hab die Daten gefunden. Aber das man alle Benutzer wieder zurückliest, dafür gibt es keinen Befehl. Ich muss also für jeden einzelnen Benutzer das Restore aufrufen.
Bei 20 Benutzern kein riesen Thema. Aber ich will lieber vorher nochmal nachfragen
LG
Michael
Hallo Michael,
das ist korrekt einen “restore all” Befehl gibt es nicht. Sofern aber der alte Nutzername dem neuen entspricht ist dies ja mit einem einfachen Bash Skript erledigt.
[quote=“fbartels”]Hallo Michael,
das ist korrekt einen “restore all” Befehl gibt es nicht. Sofern aber der alte Nutzername dem neuen entspricht ist dies ja mit einem einfachen Bash Skript erledigt.[/quote]
Hier der passende Script, für alle die das selbe Problem haben 
[code]#!/bin/bash
for i in $(ls /root/); do
echo $i
kopano-backup --restore -u $i /root/$i/
done[/code]
Hallo,
ich habe massive Probleme mit meinem Zarafa-Server. Ein normales Update unter Univention ist nicht möglich.
Außer, dass ich vor ein paar Jahren Z-Push von Hand installiert habe, habe ich keine weiteren Änderungen auf dem Server seit der Installation vorgenommen. Ausgenommen die Updates welche ich über die WebConsole eingespielt habe.
Nun würde ich gerne den Server komplet neu aufsetzen und entweder in diesem Rahmen das Update auf Kopano ausführen oder die alte Zarafa-Version wieder installieren und danach den Updatepfad wie hier beschrieben durchführen:
https://wiki.z-hub.io/display/K4U/Migrating+from+the+old+Zarafa+Univention+Apps+to+Kopano4UCS
Um die Datenbank zu sichern möchte ich einen SQL-dump ausführen. Dieses Kommando habe ich dazu verwendet:
mysqldump --single-transaction -u <user> -p <password> zarafaLeider passen die übergebenen Usercredentials nicht. Weder der Administrator noch irgendein anderer Zarafa-Admin kann die Datenbank dumpen.
Gibt es einen speziellen User der dazu genutzt werden muss? Muss ich einen speziellen Benutzer irgendwo anlegen?
Leider komme ich da derzeit nicht weiter da alle anderen Verfahren eines Backups entweder nicht kompatibel sind oder nicht funktionieren.
Da ich aufgrund jüngster Erfahrungen den Server komplett neu aufsetzen möchte, würde ich mir das Backup einzelner User-Accounts gerne ersparen um diese dann Zeitaufwändig wieder herzustellen.
Am schönsten wäre es für mich den Server einfach neu zu installieren und die Datenbank aus einem Backup wieder herzustellen.
Vielen Dank im Voraus.
Mit freundlichen Grüßen
Hendrik Dreyer
Hallo,
eine Antwort habe ich bereits gefunden:
[url]Kopano SQL dump Password]
Dies werde ich zeitnah testen und schauen ob ich dies genauso auf Zarafa anwenden kann.
Mit freundlichen Grüßen
Hendrik Dreyer
Hallo,
den Dump habe ich nun wie folgt durchgeführt:
mysqldump --single-transaction -u root -p zarafa > zarafa.dump
Enter password:
Das Kennwort ist unter /etc/mysql.secret gespeichert.
Ich werde als nächstes ein vollständigens Backup durchführen und den Zarafa Server dann neu installieren.
Mit freundlichen Grüßen
Hendrik Dreyer
Gibt es irgendwo eine Anleitung, wie man einen solchen dump ab besten in Kopano zurückspielt ?
Ich würde das gerne mit einem dump aus einem Zentyal (Zarafa 7.1) ausprobieren.
Danke.
Rainer Berns
Hallo,
ich bin gerade bei der Migration eines 7.2.2-Zarafa-Systems => UCS/Kompano. Die Attachements habe ich per rsync kopiert, nun bleibt noch die mysql, von der ich einen Dump erzeugt habe. Kann ich diesen Dump einfach in UCS in die mariadb restoren bzw. was hat es mit dieser uuid zu tun? Wird da die Zuordunung der Benutzer zu den Postfächern abgebildet und wo finde ich die?
Ja, einem Import des Dumps sollte nichts im Wege stehen. Eine noch ältere Zarafa Version sollte problematisch sein aber 7.2.2 sollte noch gehen. Siehe dazu auch https://kb.kopano.io/display/WIKI/Migrating+from+ZCP+7.1+or+earlier+to+Kopano+Core+8.5+or+later
Ja, korrekt. Über die die Unique ID des Users erkennt Kopano (bei Zarafa war das identisch) welche Benutzer es in der LDAP Quelle gibt (und dementsprechend Stores erzeugen oder löschen muss). Welches Attribut hierfür genutzt wird ist in der ldap.cfg definiert. Wenn sich dieses Attribut ändert, dann gehen Postfachzuweisungen und u.a. auch ACLs verloren.
Grundsätzlich lässt sich diese Zuordnung aber wiederherstellen. Die Schritte in http://wiki.zarafa.com/index.php/Zarafa_DB_to_LDAP_user_plugin_conversion sind grundsätzlich identisch egal ob das Ursprungssystem das DB Backend oder einfach nur eine andere unique ID verwendet hat. Eine leicht aktualisierte Version des db-upgrade-… Skripts gibt es unter https://stash.z-hub.io/projects/Z4U/repos/zarafa4ucs/browse/scripts/db-upgrade-addressbook-entryids-delegate.pl.
Sollte es hierzu noch Fragen geben empfehle ich ein Ticket bei unserem Support aufzumachen.
Ich stehe vor dem gleichen Problem, habe drei Yaffas Installationen, die nun so langsam zu alt werden. Ich kann also nicht die mysql eines 7.1 nehmen und in die kopano eines aktuellen 8.6 zurückspielen, da sich Änderungen an der Struktur ergeben haben. Ist das richtig?
Jetzt habe ich in diesem Thread die Lösung über kopano-backup gefunden. Ist das in den kostenlosen Varianten verfügbar? Das wäre die perfekte Lösung, da es sich um recht kleine Installationen mit je nur bis zu 5 Nutzern handelt.
Ist kopano-backup bei der UCS sowieso verfügbar? dann könnte ich mein Backup-Scenario überdenken. Bislang habe ich Nachts ein dump und per rsync das /data - Verzeichnis auf einen NFS mount vom Nas geschoben. Läuft seit Jahren einwandfrei und auch die Postfächer waren nach einem zurückspielen immer verfügbar, sofern im Vorfeld die Benutzer identisch angelegt wurden. Auf die LDAP-Einträge habe ich da nicht geachtet. War Yaffas da anders aufgestellt, als UCS?
Danke für die Unterstützung.
VG - Fossi
Fast. Damit die datenbankinterne Struktur aktualisiert werden kann, müsste die Datenbank halt einmalig mit einem 7.2er Server gestartet werden. Neuere Kopano Versionen bringen diese Konvertierung nicht mehr mit.
Kopano ist 100% OSS, die kostenpflichtigen Versionen enthalten keine zusätzlichen Komponenten. Diese erhalten “lediglich” mehr Aufmerksamkeit in Bezug auf Testing und für diese gibt es offiziellen Support durch Kopano.
Ja, siehe oben.
Nein, wie oben schon einmal geantwortet nutzt Yaffas/Zarafa da die selben mechanismen, wie auch Univention/Kopano.
Ich kann da eingeben, was ich will. Ich bekomme einen Haufen Netzwerkfehler. Kann es sein, das die Firewall vom UCS alles blockiert?
Croot@MAR-UCS1:~# kopano-backup -s x.x.x.x:237/zarafa -U Markus -P xxxx
[error ] gsoap connect: ()
[error ] HrLogon server “x.x.x.x:237/zarafa” user “Markus”: network error
2018-11-05 23:19:34,804 - backup - WARNING - could not connect to server at ‘x.x.x.x:237/zarafa’, retrying in 5 sec
Es muss entweder ein http:// oder ein https:// davor
Mensch - Ihr seid aber auf Draht! Vielen Dank.
Die Installation ist schon etwas älter. Die DBs habe ich auch schon mehrfach umgezogen. Da ist wohl ein bisschen Sand ins Getriebe gekommen.
Mit https: habe ich einen Zertifikatsfehler bekommen, da das Zertifikat auf den öffentlichen FQDN zeigt. Dort ist Mapi aber nicht freigeschaltet.
Mit http und Port 236 hats erst auch nicht funktioniert. Jetzt habe ich mal einzellne Mailboxen angesprochen.
So gehts scheinbar. Er zieht die Daten runter. Wenn ich die Sicherungen nun auf den Kopano zurückgeschrieben bekommen - perfekt.
Vielen Dank.
VG - Fossi
Vielen Dank.
Das hat tatsächlich funktioniert. Beim ersten Anlauf gab es leider Probleme. Ich habe die locales auf de_DE.UTF-8 gesetzt. Auch das System habe ich so aufgesetzt und Anpassungen im Apache unter /envars vorgenommen. Beim Erzeugen eines Users sind die Ordner in Kopano jedoch ohne Sonderzeichen angelegt worden. Erst ein Installieren der en_GB.UTF-8 und ein umbenennen in Englisch und Retour auf Deutsch hat die Verzeichnisse korrekt angelegt. Ein zuvor durchgeführter restore hat zusätzliche unterordner angelegt. Das war nicht optimal.
Jetzt lehnt der neue leider noch die Mails von aussen ab. da muss ich noch dran arbeiten. Wenn jemand eine Idee hat: Letzter Fehler: 451 4.4.1 - Connection Time out.
Da ich einen weiteren Server in der Form aufgesetzt habe, habe ich da noch keine Idee dazu. Klingt nach Firewall, 25, 443, 465, 587 sind aber offen. Für das Thema mache ich aber dann ggf. einen neuen Thread auf.
VG - Fossi
Vielen Dank.
All das sollte auf einen Univention System eigentlich nicht notwendig sein. Ist die letzte App Version installiert?
Ich habs soeben nochmal frisch installiert und habe den Fehler an gleicher Stelle gefunden.
Die App Kopano läuft als 8.6.2. Mit wohl 8.6.8 werden die defeaults nicht mehr unter /etc/default/kopano, sondern in /etc/kopano/admin.cfg gesetzt. Die Datei unter /etc/kopano wird angelegt, jedoch kann der core damit “noch” nichts anfangen und es wird gar kein Userstore angelegt und es erscheint ein Fehler auf den falschen Parameter, wenn auf der Cli kopano-admin angesprochen wird. Nach Auskommentieren werden die Stores erstellt, jedoch ohne Sonderzeichen in den Ordnernamen. Für den zuerst angelegten User habe ich dann den Store manuell erzeugt, der dann auch die Sonderzeichen enthielt. Ein testweise danach über die Managementconsole erstellter Benutzer wird ohne Sonderzeichen in kopano erstellt.
Meinen Fehler habe ich übrigens wohl auch gefunden: EWE sperrt wohl per default in ihren Netzen den Port 25. Dann weiß ich nun, warum ich mit meinem Server seit dem Umzug Probleme habe. Bin heute schier verzweifelt. Irgendwann hatte ich dann raus, das tatsächlich der Port 25 bei mir von außen nicht erreichbar ist - natürlich erst nach etlichen Versuchen an anderer Stelle.
Ich richte jetzt erstmal wieder fetchmail ein - auf der neuen Maschine. Am Dienstag soll ich einen Anruf bekommen.
VG - Fossi
Maschine läuft. Gibts eine Möglichkeit, einzelne Standardordner zu löschen, die sich über die Oberfläche nicht löschen lassen?
RSS Feeds
RSS-Feeds
wäre da so ein Beispiel. Danke übrigens für den hervorragenden Support hier.
VG - Fossi
Merkwürdig. Ich habe mal https://jira.z-hub.io/browse/KUCS-38 erstellt um bei Zeit das mal nachzustellen.
Nein, das ist nicht vorgesehen.