Hi,
das ist 'wizig' Kopano4S benutzt Debian als Unterbau im Docker und Kopano UCS wird auch nur von wenigen (massgeblich Felix B.) weiter entwickelt, so wie K4S massgeblich von mir.
Das ist alles nicht als Vorwurf gemaint, aber wenn man auf Debian geht, braucht man viel Unix Wissen für den Betrieb und Skripted sich einiges selbst, was in K4S integriert ist.
Das mit dem K4S für Heimgebrauch stimmt insoweit, dass es keine große Gemeinde gibt, die auf Synology entwickelt und K4S eben einen Großteil der Komplexität kapselt (auf Shultern einer Person).
Ich habe viel Zeit verbracht, alte Synology JS Zarafa Migrationen zu Supporten, Datenbank und User Backup Restore und das sogenannte Downgrade von Community auf Default / Supported zu skripten, das gibt es alles sonst nicht...
Bei Kopano hat sich mitlerweile eine Community gebildet, die Docker Container pflegt, weit moderner mit Docker Compose und weniger monolytisch als k4s, aber eben nur mit einer Community Edition, mit LDAP und Kommandozeilen Aktionen.
Das gab es alles 2016/17/18 nicht, als ich Zarafa / Kopano für Synology am Leben gehalten habe und der vernünftige weg ist: Kopano4S zu Re-Engineeren und Ent-Kernen, was ich begonnen habe, teilweise mit anderen kleineren Projekten.
Wenn du und Andere an der Entwicklung und Testen teilnehmen wollen: Welcome, denn alleine brauche ich dafür 6-12 Monate. Andrerseits ist das aktuelle k4s Projekt auf Github (
https://github.com/TosoBoso/Kopano4s) für Einsteiger schwer zu verstehen.
Wie ein modernisiertes Synology Paket aussehen kann, das Docker Compose verwendet und die Schichten Docker-Container ala Microservices, Configuration / Log und Synology GUI mit Ajax verwendet, findet sich in Jitsi-Meet, was ich bald online stelle.
Zum Thema "nach einem Disaster auf dem schnellstmöglichen Weg wieder online zu sein": das funktioniert Alles schon mit Datenbank und File-System Replikation: kopano4s-replication ist aber den weinigsten in der Community geläufig und nur bedingt im Wiki dokumentiert.
Mir hat die Datenbank Replikation (gibt es auf der 'Profi' Version Debian und UCS nicht bzw. muss man selbst Skripten..) den Allerwertesten gerettet, da mir 2 Synology's im Produktions-Betrieb nacheinander gstorben sind.
Ich hatte keine Datenverluste, Aber natürlich hatte ich Nacharbeit und mein Test-Lab verloren, was einer der Gründe ist, dass meine knappe Zeit nicht in Kopano4S Weiterentwicklung und Formum Support gegangen ist.
Zum Thema DR und Replikation als Erweiterung zu Backup-Restore solltest du einen eigenen Stream hier im Forum öffnen, ich kann dann auch gerne Antworten geben; das Skript ist jedenfalls 'mächtig'
Code:
admin@Diskstation:~$ sudo kopano4s-replication help
kopano-replication (c) TosoBoso: script for kopano replication via mysql.
Usage: kopano-replication [action] with status as default.
[status] or no action as argument shows setup per master or slave configuration and mysql replication state.
[health] checks replication state bi-directional for master and slave including error notification.
[master mypwd shost rpwd id] set master with id and replication user rslave connecting from slave-host.
[slave-add mypwd shost] add to running master next slave-host to connect with replication user rslave.
[slave mypwd mhost rpwd id] set and connect slave to the master-host with user rslave; run syncin afterwards.
[start/stop/syncin/skip/resync/remove mypwd] applicable for slave; syncin=start with master log-pos post restore;
to resolve issues: skip=skip last error; remove=replication removal; resync=initialized sync from reset master log-pos.
[rw/ro] by default slave is set to read-only (ro) which can be changed to write-enabled (rw: carefull it can break replication)
[reset mypwd] applicable for master / slave; sometimes master needs a reset; restart / reset and resync slave as next step..
mypwd is the mysql-root-pwd, rpwd is the replication pwd which has to be the same on master / slave side.
-TosoBoso
