Transferring a single-server system to another server

Table of contents

Task Description
Approaches
What you’ll need
Options for installing the platform in the mode with a backup database connection.
Detailed description of the process

Task Description

Starting point:
There is an installed instance of the platform on a server (possibly virtual) with a Debian.
The platform is installed on the local address of the virtual server (let’s say, 172.27.1.121).
The main domain DBMS postgresql is installed here via the platform installer.
The DBMS is installed in a docker container.

It is necessary to move the platform to another server that has a different address (let’s say 172.27.5.122).
You need to save data, including license, configuration, settings.

Approaches

1. Through export/import.

This option is applicable if the installation is standard, the number of domains is small, and historical data is not important.

2. Through a database backup (pg_basebackup)

The new system is installed and then a connection is made to the previously reserved copy instead of the empty postgres domain database.
This can be done by replacing the DBMS directory with the configuration and data, or by configuring a new DBMS instance based on the backup copy and then replacing the connection string in the configuration.

From the previous system in this case will also need to be copied:

Syncroot directory with domain data (including script files).
The recpath directory with the recorded conversations if the recording has not been configured to external storage.
License.
Configuration (it will have to be additionally adapted to the new server addresses).

If the system connected to external DBMSs and file storages, the connection will be made automatically if there is access to them with the same parameters.
The exception to this is NFS and other mounted file systems, which must be connected to the server beforehand.
If external storages become available under different addresses or credentials, then the settings of connections to the storages must be adjusted in the domains.

3. Through the database script (pg_dump)

Unlike the previous point, the database is not backed up and connected, but a script is created using the pg_dump utility, which is then applied to the new database.
The script is created separately for each database within the DBMS, i.e. 1-2 times for each domain.

This method should be used if it is necessary to migrate data to another version of the DBMS server, or to enrich an existing postgres instance with databases and platform data while leaving other existing objects unchanged.

What you’ll need

1. Setting string with parameters

The following installer startup line with parameters was used to install the main system:

bash install_ssh.sh \
  -u era \
  -p 22 \
  --host=188.1.1.1 \
  --ipaddress=172.27.1.121 \
  --postfix=_myinstance \
  --master=y \
  --masterdomain=era.test \
  --srvname=mysrv1 \
  --dopginstall=y \
  --usereplic=n \
  --pgmode=d \
  --pgport=5432 \
  --pgpostgrespwd=MyPwd1234 \
  --pskcookie=123456 \
  --usedefaults

If no such string was used, you must compose it by restoring all used values, including default values.

2. Active configuration

After authorizing in the master domain, open the configuration for editing and copy its contents.

An alternative way is to get it from disk, it is placed in the cfgv3.json file in the working directory of the node with the mic role, for example in the container this is the

/var/lib/era/_workdir/mic1@172.27.1.121/cfgv3.json

and the default host

/opt/era_myinstance/lib/_workdir/mic1@172.27.1.121/cfgv3.json

3. License

Having authorized in the master domain, open the page in the address bar of your browser /api/admin/v1/lic/download.

An alternative way is to get it from disk, it is placed in the r.lic file in the working directory of the node with the mdc role, for example in the container this:

/var/lib/era/_workdir/mdc1@172.27.1.121/lic/r.lic

and the default host

/opt/era_myinstance/lib/_workdir/mdc1@172.27.1.121/lic/r.lic

4. Files

The syncroot directory contains domain files that are available to all servers in the deployed platform. For example, script files.
The catalog should be copied in its entirety to the new system.

5. Food layer bags

If a product layer was used on the system and external packages were installed, the packages should be detected.

Options for installing the platform in the mode with a backup database connection.

There are two courses of action:

1. Installing the platform with a new DB and then swapping out the DB.

1.1. Install a new instance of the platform at the current local address with the same installation parameters (mainly database passwords). Adjust those parameters that are necessary (e.g. installation address, binding to volumetric directories). It is important to install the same version of the database.
1.2. Prepare the database on the source for backup.
1.3. Swap the database. That is, we backup the database, disable the backup state, and swap the target database directory. Or backup directly to the postgres installation point, renaming the previous data folder beforehand.

2. Platform installation with connection to a new pre-prepared database.

2.1. Manually install the database on the new server (postgresql only) of the same version as on the source server.
2.2. Backup the database from the source server to a new folder on the destination server /var/lib/postgresql/14/era.
2.3. Install a new instance of the platform by selecting "connect to existing database" in the section about installing the database server and entering the address of your database server and its port. If everything is local - up to 127.0.0.1

Further operations

*.4. Downloading the license.
*.5. Authorize to the master domain under admin, open configurations, find the latest one, adjust it if necessary by changing addresses (and, unlikely, paths).
*.6. Copy the directory from the previous server syncroot.
*.7. Copy the directory from the previous server era_recpath.
*.8. We install the grocery layer and custom packages.