LiquidFiles Documentation

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 the command `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 migration, the LiquidFiles web application will 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. 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).

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.

Example Migration

Source System

[root@lf1 ~]# ft migrate
1. Migrate to this system
2. Migrate from this system
3. Cancel
?  2
This will enable you to migrate the data and the configuration from this system
to a new LiquidFiles system. This system be disabled during the migration
to avoid conflicts.
Do you want to continue?

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.

Destination System

On the target, there's a few more steps involved before running the `ft migrate` command:

  1. Complete a basic installation of the system, and complete the Getting Started procedure.
  2. 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.
  3. When the Getting Started procedure has completed, please go to Admin → Console Access and set a root password.
  4. 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?
What hostname/ip are we migrating from?
What's the password listed from the migration script on the source system?
Do you want to replace the ssl certificates with the one from the source?
The connection from here to uses rsync, tcp/873. Please make sure
it's allowed and that the migration script is running on
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.

While testing, replace the hostname part of the URL with the IP address of your new system to test that links work: →

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.