Moving to a new server
Sometimes it's required to move from one server to another. Either from changing to cloud deployment (EC2, ...) to a local server, from Hyper-V to VMware, a physical server to EC2, move between two different server locations, moving from LiquidFiles v2.x to v3.x or any other similar situations.
The LiquidFiles way to facilitate this is identical in all those situations. The process is basically to run
`ft migrate` on the console on both systems and follow the bouncing ball.
License Considerations when moving server
When moving server, make sure you:
- Give the new server the same hostname as the old system. If you use the method of setting the Email Base URL in Admin → Configuration → Email, make sure you set the same on the new system as well. Please verify in Admin → System → License that both systems have the same licensed hostname.
- With this configuration you can install the same license on the destination system.
- Complete the migration as per this guide.
- If you want to change to a different hostname, when the migration has finished and you've decomissioned the old system, you can change the hostname (or Email Base URL) on the new system and it will automatically update the license server.
Data Disk Considerations when moving server
If you want to use something other than the default disk configuration of keeping everything on the one large system disk, you need to configure the destionation system before migrating. Please follow the Data Disk or NFS Server guide on the new server before you start the migration from the old system. The migration process will then use the desired data disk/NFS configuration.
Running this migration procedure will make destination system an identical copy of the source system. It is NOT possibly to merge two systems into one.
The data transfer between the source and destination system is using Rsync on TCP/873, from the destination system to the source system. Please make sure any firewalls and similar between the system is permitting this connection.
During a final production migration, the LiquidFiles web application should be shut down to ensure nothing changes on the source system so that we can ensure that the destination system is an identical copy of the source system when the migration has completed.
Testing Migration before production change-over
One great feature for testing is that running the migration multiple times is completely safe, so you can run the migration to copy everything to a new system on one migration window, test everything you need to test on the destination system and then re-run the migration a second time. During the testing or initial migration you can keep the LiquidFiles web appliacation running on the source machine. The second time, only the new files (from the previous migration) will be copied over to the destination system so even on large installations, migrating the second time will be very fast (depending on number of files that has been uploaded since the previous migration). Note: The option which allows to stop or keep running the LiquidFiles web service has been added since LF v3.0.0
Please see the Using a dev/test/staging system with the production license guide for more information on using the same license on two systems during testing.
[root@lf1 ~]# ft migrate 1. Migrate to this system 2. Migrate from this system 3. Cancel ? 2 This will assist you in migrating the data and the configuration from this system to a new LiquidFiles system. You can choose to disable the current system or not. If you're just testing the migration before the final migration, you don't need to disable the system. If you're doing the final migration, it's best to disable the current system to ensure that no one uses the system where any changes wouldn't be copied to the system you're migrating to. 1. Continue and don't disable 2. Continue and disable 3. Cancel ? 2 ------------------------------------------------------------------------------- Migration script This will enable migration from this system to a new LiquidFiles system. Stopping web service. Backing up database for migration. To migrate from the this system, please run 'ft migrate' on the system you want to migrate to. It will ask you to enter a password. Please enter the password below: password: thiacafru When you're done migrating, please enter ^c (Control C) to disable migration from this sytem.
On the target, there's a few more steps involved before running the
`ft migrate` command:
- Complete a basic installation of the system, and complete the Getting Started procedure.
- Give the Target system the same hostname as the Source system, this will enable you to install the same license as on the source system.
- When the Getting Started procedure has completed, please go to Admin → Console Access and set a root password.
- If there's a firewall between the system, please make sure that rsync (TCP port 873) is permitted from the target to the source.
[root@lf1 ~]# ft migrate 1. Migrate to this system 2. Migrate from this system 3. Cancel ? 1 This migration script will replace all files, configuration and users on this system with the one your migrating from. Do you want to continue? yes Great What hostname/ip are we migrating from? 172.16.5.251 What's the password listed from the migration script on the source system? thiacafru Do you want to replace the ssl certificates with the one from the source? no The connection from here to 172.16.5.251 uses rsync, tcp/873. Please make sure it's allowed and that the migration script is running on 172.16.5.251. Testing connection... Looks good. Beginning migration in 10s, please hit control-c now if you want to abort.
And as specified in the screenshot. All files and all configuration will be deleted from the target system. Depending on how much file data you have, this can take a significant amount of time.
Once completed, you can turn off the source system.
Two Step Migration
A fairly common scenario is to do a two step migration from the old to the new system. Once to test that migration works as expected and a second time to complete the migration for production changeover. It will work just fine with this migration process.
After you've completed the migration steps above, restart and keep using the old system as your production system. You can do whatever tests that you need on the new system to make sure that it works as expected.
Make sure that you leave the hostname the same as the old system or you will run into licensing issues on either the old or new system, or both.
When you test functions that will send emails with links — sending messages, password resets, ... the links will have your production URL in them. During testing, you need to replace the hostname part of the URL with the IP address of the test system.
https://prod.liquidfiles.com/message/abc123 → https://192.168.10.20/message/abc123
This will enable you to keep testing without changing the hostname or run into license issues.
Once you've completed all the testing you need, just re-run the migration steps above. What will happen is that any changes with any files will be mirrored to the old (source) system again. Only new files will be copied across. When all files have been mirrored the database will be replaced with the database from the old system so any changes you've made in testing will be removed.
Make sure you turn off the old (source) system once you've completed and update your firewalls/dns to make sure your production traffic is going to the new system.