To upgrade, you first must ensure you have a backup of everything, the mail, the Groupware database, etc. To be safe, backup the entire /Icewarp/ folder so that you know you have a full backup.
To move to a new server, follow the steps below:
1. You must have the same version on both servers because of differences in config files.
2. During migration, you can use the same license on your production server for up to 30 days in parallel. On the new server, activate your license using the remote console - Help - License - Activate License... - insert Order ID from the old server.
3. Import/export list of users and domains from old to a new server If you are using filesystem or SQLite
- In case you are using the file system, you must migrate accounts to the SQLite database
- Go to IW remote console - System - Storage - Accounts
- In DB Settings... select Driver to "SQLite" and write to Database column "accounts.db" - OK
- Convert To DB (this will create accounts.db file in /icewarp/ folder)
- Take accounts.db and copy it on the new server to /icewarp/ folder
- On the new server in the remote console - System - Storage - DB Settings... choose "SQLite" for Driver and "accounts.db" for Database
- Switch choose an option from File System to Database - Apply
After doing this, you will run the same users and domains on the new server.
4. From the source server to the target server, copy the following folders to the /icewarp/ folder
- Mail (don't forget to migrate /mail/ folder with the same timestamps - we are using Robocopy or RSync)
- Spam (if using the default anti-spam database - SQLite)
- Calendar (if using the default groupware database - SQLite)
- Config (without webserver.dat and imservices.dat)
We recommend doing a backup of all 4 folders before replacement to avoid irreversible damage.
NOTE: The license file is saved in /config/ folder so be careful to copy it if you don't move the whole folder.
5. When you change the config file, you will change the connection settings for all DBs. The most important is account DB because it can cause login issues to the remote console.
Check if you have a setup a file system or database for accounts (1- file system, 2 - DB)
/opt/icewarp/tool.sh get system C_System_Storage_Accounts_StorageMode
Check how do you have a setup of accounts DB (should be accounts.db;;;;7;3)
/opt/icewarp/tool.sh get system c_system_storage_accounts_odbcconnstring
Setup storage mode to DB
/opt/icewarp/tool.sh set system C_System_Storage_Accounts_StorageMode 2
Setup DB settings to accounts.db
/opt/icewarp/tool.sh set system c_system_storage_accounts_odbcconnstring 'accounts.db;;;;7;3'
6. Linux has a different meaning of backslashes that's why you need to change it for slashes. You can use the following command to replace it in Linux
- /opt/icewarp/tool.sh export account "*@*" u_type u_mailboxpath | grep ",0," | sed -r 's|\\|/|g' > /opt/icewarp/path.txt
- /opt/icewarp/tool.sh import account "/opt/icewarp/path.txt" u_type u_mailboxpath
NOTE: If you have members of a mailing list from .txt files, don't forget to migrate the .txt files too.
7. When you successfully migrate everything and have servers on the same version, to upgrade to the latest IceWarp version, you should always install several versions before getting to the latest. (for example, if you are running on v11 and older, first install v11.4.6, then v12.2, followed by v13.0 and 13.0.3.10 to finally land on v14.x)
****** Migration to cloud - config ******
Do not to transmit:
settings.cfg
license.key
webserver.dat (or, if so, it is necessary to edit the paths in it)
ftpserver.dat (same as previous)
voicemail.xml
imservices.dat
Then there are files to be careful about, because they may (but do not have to) contain paths inside:
content.xml
filter.dat
staticfilters.dat
autoclean.dat
externaldirs.dat
Then usage of local IP may not make sense - in bypass files, setup of binding, etc.
****** If using the MySQL databases do a DUMP of DB ******
1. Start CMD as administrator and go to the /bin/ folder of MySQL
2. For export of DB do: mysqldump -u username -p databasename > C:\dbname.sql
3. This will create DUMP in C:\ location
4. For import of DB to the new Linux server do the following: mysql -u mysql_user -p database name< dbname.sql
You can do DUMP only this DB's: account, antispam, antispam-reports, groupware. The rest of DB are cache DB, so it’s unnecessary to migrate them.
****** Creation of DB in MySQL server ******
CREATE DATABASE accounts default charset utf8mb4 collate utf8mb4_unicode_ci;
CREATE DATABASE antispam default charset utf8mb4 collate utf8mb4_unicode_ci;
CREATE DATABASE groupware default charset utf8mb4 collate utf8mb4_unicode_ci;
CREATE DATABASE webclient default charset utf8mb4 collate utf8mb4_unicode_ci;
CREATE DATABASE eas default charset utf8mb4 collate utf8mb4_unicode_ci;
CREATE DATABASE dircache default charset utf8mb4 collate utf8mb4_unicode_ci;
CREATE DATABASE asreports default charset utf8mb4 collate utf8mb4_unicode_ci;
After this switch value in API console:
system.mysqldefaultcharset utf8mb4
We are recommending using this charset/collation.
NOTE: If you had DB created with a different charset/collation and you will import its DUMP to the new created DB, it will not inherit his charset/collation; it will still have the same as was created.
****** Robocopy/Rsync ******
For migration of /mail/ folder we use these commands with the following parameters.
Robocopy
robocopy C:\source M:\destination /MIR /FFT /R:3 /W:5 /MT:16 /Z /NP /NDL
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy
Rsync
rsync -avz /source/data /destination/data
*** After migration ***
After migration, stop all services on the old server and use uninstall.exe to remove the application files and clear the extra license activation.
Comments
0 comments
Article is closed for comments.