Migrating the system to a new server or restoring it from backup

Migrating or restoring the system from backup takes place in a few steps.

1. Upload the files to the webroot directory.

It is best to unpack the files directly on the server, which will preserve the original permissions on the files.

If you have a separate copy of the storage directory, like in case of YetiForce Cloud you need to unpack the backup copy to __CRM__PATH__/storage so that there is no storage directory in this directory, and only the following data directories instead: https://github.com/YetiForceCompany/YetiForceCRM/tree/developer/storage 

2. Upload database.

Upload the database using the CLI console (recommended) or a database client eg. DBeaver,  Database Workbench , SQLyog

mysql -P 3306 -h 127.0.0.1  -u crm -p crm < dump.sql

3. Update configuration files.

After uploading the files and importing the database we should update the following files:

  • config/Main.php
/** Backslash is required at the end of URL */
public static $site_URL = 'https://example.yetiforce.cloud/';
  • config/Db.php
/** Gets the database server */
public static $db_server = 'localhost';
/** Gets the database port */
public static $db_port = '3306';
/** Gets the database user name */
public static $db_username = 'root';
/** Gets the database password */
public static $db_password = '';
/** Gets the database name */
public static $db_name = 'yetiforce';

It is also worth checking if restricted domains have changed:

  • config/Security.php
/** Restricted domains */
public static $EMAIL_FIELD_RESTRICTED_DOMAINS_VALUES = ['yetiforce.com','github.com'];

If there is a backup directory available on the server, it can be enabled:

Verify if forced HTTPS is enabled. There might be problems if HTTPS was on the old server and the redirection was enabled and the new server has no active HTTPS.

/** Force site access to always occur under SSL (https) for selected areas. You will not be able to access selected areas under non-ssl. Note, you must have SSL enabled on your server to utilise this option. */
public static $forceHttpsRedirection = false;
  • config/Components/Backup.php
/** Backup catalog path. */
public static $BACKUP_PATH = '';

4. Check if the configuration complies with the requirements.

Whenever the system is migrated, restored from backup, or the LAMP server is updated, it is important to check the system’s configuration in the built-in verification tool or in the article  “Web server requirements”.

If the server does not comply with the requirements, do not use it as it may result in data loss. If any parameters are yellow or red, they should be changed. 

It is also important that the owner of the files is the same user running the web server (apache, nginx).

5. Run CRON and verify its operation.

6. Re-register the system

Migrating to a new server or restoring it from a backup requires re-registration of the system.

7. Update add-ins

Some add-ins may need to be reconfigured when changing CRM location or address.

7.1 YetiForce Outlook Integration Panel

Requires reinstallation and the installation of a new XML file. The old add-in installed in Outlook should be removed and the new XML file from the CRM panel should be downloaded according to the instructions.

8. Creating a test environment

If we create a test environment, it is worth introducing some important changes that will help us distinguish and secure the environments.

8.1 Change users' passwords

8.2 Visually separate the environments

It is worth adding a message that this is a test environment, it can be done on the login page and on the top bar of the CRM system.

From version 6.2.0 it is possible to add in the configuration file config\Main.php additional notices.

https://doc.yetiforce.com/code/classes/Config-Main.html#property_loginPageAlertMessage

/** Header alert message */
public static $headerAlertMessage = '';
/** Header alert type, ex. alert-primary, alert-danger, alert-warning, alert-info */
public static $headerAlertType = '';
/** Header alert icon, ex.  fas fa-exclamation-triangle, fas fa-exclamation-circle, fas fa-exclamation, far fa-question-circle, fas fa-info-circle */
public static $headerAlertIcon = '';
/** Login page alert message */
public static $loginPageAlertMessage = '';
/** Login page alert type, ex. alert-primary, alert-danger, alert-warning, alert-info */
public static $loginPageAlertType = '';
/** Login page alert icon, ex.  fas fa-exclamation-triangle, fas fa-exclamation-circle, fas fa-exclamation, far fa-question-circle, fas fa-info-circle */
public static $loginPageAlertIcon = '';

2021-08-27_14-58-00.png

2021-08-27_14-58-15.png

8.3 Change the sender name in SMTP or disable the cron task responsible for sending out emails

Messages sent from the new environment will look the same as the ones sent from the production environment, so it is worth disabling or changing the sender names in SMTP to be able to distinguish between these e-mail messages.

Panel: System settings > Automation > CRON

Documentation: CRON

8.4& Change API keys

It is worth changing the API access data to make them different for each environment. So that someone who has access to the test version will not be able to get data from the production version.

Panel: System settings  > Integration > Web service - Apps

Note:

In order to properly transfer the CRM system to another server, you should make a complete copy of the system (files and database). It is best to use compression software, e.g.

zip -r `date +"%Y%m%d_%H%M"`.zip __CRM_PATH__ -q
tar -zcvf /var/www/html/`date +"%Y%m%d_%H%M"`.tar.gz /var/www/html/

No error can occur during the transfer or recovery of the system, as the database may later turn out to be corrupted.

  • Monday, 11 January 2021