> On Aug 21, 2017, at 10:49 PM, Christian Mack (christian.m...@uni-konstanz.de) 
> <users@sogo.nu> wrote:
> 
> That should have worked.
> At least on my last migration test it did.

Unfortunately, it didn’t work for me.

> You should open a bug report for that.

Bug report: https://sogo.nu/bugs/view.php?id=4256

Here’s how i got the backup fully restored (SOGo 2.2.15 -> 2.3.22 -> 3.2.10): 3 
machines involved, old server runs SOGo-2.2.15 and we’re going to migrate it. A 
temporary virtual machine runs SOGo-2.3.22 and used to help get the latest SQL 
structure of SOGo 2.x branch. The final new server runs SOGo-3.2.10, it is the 
one we’re going to deploy in production. Steps:

1) Old server is running SOGo-2.2.15, backup data with 'sogo-tool backup'.
2) Setup a new VM with SOGo-2.3.22 (the latest version of 2.x branch).
3) On new VM, drop sogo db, re-create it, restart sogo service. SOGo creates 
required SQL tables automatically.  Note: since it’s already 2.3.x with new SQL 
structure, i didn’t run the script "sql-update-2.2.17_to_2.3.0-mysql.sh” to 
modify SQL table structure.
4) On new VM, restore backup files with 'sogo-tool restore'. Login to SOGo and 
verify restored data. So far so good, all personal contacts/calendars, and 
shared calendars are restored.
5) On new VM, backup sogo data by dumping the whole sogo sql database (not 
‘sogo-tool backup’).
6) On final new server, runs SOGo-3.2.10 (the latest version of 3.x branch).
7) On final new server, drop sogo db, re-create it, restart sogo service. SOGo 
creates required SQL tables automatically.
8) On final new server, import dumped sogo sql file (generated on step #5).
9) On final new server, run script "sql-update-3.0.0-to-combined-mysql.sh” 
(shipped in SOGo package) to update SQL structure.
10) On final new server, backup data with “sogo-tool backup”. Then run 
“sogo-tool restore -p -c /etc/sogo/sieve.cred <backup-dir> <user>” to generate 
sieve rules.
11) Login to final new server and review restored data, so far so good, all 
personal contacts/calendars, and shared calendars are restored.

Question:

- We stores mail accounts in OpenLDAP, why does SOGo backup file contains full 
LDIF data of user? especially attribute "userPassword". I suppose only uid 
(full email address) and/or ldap dn of user should be enough? It may become a 
security concern if sysadmin didn’t realize the backup file contains (hashed) 
password and didn’t set proper owner/group and file permission.

Again, thank you very much for helping. :)

----
Zhang Huangbin, founder of iRedMail project: http://www.iredmail.org/
Time zone: GMT+8 (China/Beijing).
Available on Telegram: https://t.me/iredmail

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Reply via email to