Kopano Server Migration
-
hi kios_gmbh,
I prefer a mysqldump and tar the data folder and copy it to the new system.
My migration was debian 8 to ubuntu 18, just because of ubuntu has a newer PHP Version ( 7.2.).
Good luck! :-) -
Hi,
I would prefere the kopano-backup method, especial with hughe amount of data - as you can bring online the new server and be productive while reostoring user data still running and you have minor issues with user mappings i think
rg
Christian -
@AnotherAndy thank you for the reply.
What kind of files are included in the data folder?
Regards -
@externa1 thank you for your input.
What would be the command syntax if i wanted to do a full backup and backup everything ?
Regards -
hi @kios_gmbh ,
in my data folder all attachments are stored.
cat server.cfg |grep attachment_path
attachment_path = /data/kopano/attachments
You can also setup up a second server and restore the database dump and the files folder and see if everything is working.
best regards -
kopano-backup -l info -O /backup/folder for example - then in the backup folder the backup creates a folder per username for each account
rg
Chrisitan -
Hi @kios_gmbh,
I prefer the manual (database/attachments) migration. As mentioned in this thread I noticed that, using kopano-backup, email contents are altered at least regarding their headers if you are using kopano-backup. So if you want everything to look exactly the same after migration, the manual approach is the one you might want to go. Of course, the downside of the approach is the downtime of your system. But you can minimize that by using rsync for the attachments files. First, you can do a kind of pre-migration copying the attachments to your new system. Then, when doing the final migration, using rsync it speeds up things a lot because you are only synchronizing the differences.
-
@genesis74 said in Kopano Server Migration:
But you can minimize that by using rsync for the attachments files
to add to that mysql master/slave replication can be used to dramatically reduce migration time of the database as well.
-
@externa1 that worked, albeit very slow.
Now im having an issue when trying to restore from the backup:
root@mail:/mnt/backup/backup/folder# kopano-backup /mnt/backup/backup/folder/ --restore
[error ] gsoap connect: ()
[error ] HrLogon server “default:” user “SYSTEM”: network error
2019-04-25 14:00:29,055 - backup - WARNING - could not connect to server at ‘default:’, retrying in 5 secHrLogon “default:” doesn’t seem right. What am i missing here?
-
is kopano-server running? do you have a log file in /var/log/kopano/server.log
-
@mcostan there were no log files. After using service kopano-server start this is the log:
Thu Apr 25 16:34:08 2019: [=======] Starting kopano-server version 8.6.9 (pid 7395)
Thu Apr 25 16:34:08 2019: [warning] Config warning: Option ‘server_max_keep_alive_requests’ is not used anymore.
Thu Apr 25 16:34:08 2019: [warning] Config warning: Option ‘sync_log_all_changes’ is not used anymore.
Thu Apr 25 16:34:08 2019: [warning] Config warning: Option ‘plugin_path’ is not used anymore.
Thu Apr 25 16:34:08 2019: [warning] Config warning: Option ‘thread_stacksize’ is not used anymore.
Thu Apr 25 16:34:08 2019: [warning] Config warning: Option ‘client_update_enabled’ is not used anymore.
Thu Apr 25 16:34:08 2019: [warning] Config warning: Option ‘client_update_path’ is not used anymore.
Thu Apr 25 16:34:08 2019: [warning] Config warning: Option ‘client_update_log_level’ is not used anymore.
Thu Apr 25 16:34:08 2019: [warning] Config warning: Option ‘client_update_log_path’ is not used anymore.
Thu Apr 25 16:34:08 2019: [error ] Coredumps will not be generated: kopano-server requires the fs.suid_dumpable sysctl to contain the value 2, not 0. See kopano-coredump(5) for details.
Thu Apr 25 16:34:08 2019: [error ] KDatabase::Connect(): database access error Unknown error code (0x80000007), mysql error: Access denied for user ‘kopanoadmin’@‘localhost’
Thu Apr 25 16:34:08 2019: [crit ] Unable to connect to database: MYSQL not initialized
Thu Apr 25 16:34:08 2019: [=======] Server shutdown complete. -
it looks like your kopano server can’t connect to your MySQL server.
Perhaps MySQL isn’t running or perhaps the permission for the user “kopanoadmin” aren’t set properly.
I think you need to fix this before you attempt the restore of the backup.
