Environment and data duplication


  1. Duplicating an environment
    1. Server duplication
    2. Rename DNS
    3. Tests
  2. Data duplication
    1. Configuration
    2. Disk space

Duplicating an environment

It may be necessary to duplicate an environment, for example, to put into production a test environment that has passed validation. Here are the steps to follow:

  • Duplicate servers
  • Rename DNS

Server duplication

Hosting is increasingly based on virtual machines. Server duplication becomes a simple operation.

  • Stop services (Apache, Tomcat, Solr then MySQL) on the source server
  • Duplicate all machines

Rename DNS

DNS renaming is detailed in the section below: ModifyingURL in the back office

Tests

  • Connect to the new CMS
  • Create a page, new content and validate content, make page accessible (tag if necessary)
  • Run a content search on CMS and check that it doesn't fail
  • Connect to the old CMS, check that the page is not on the old one CMS
  • Login to the new site
  • Go to new page
  • Connect to the old site and check that the new page does not exist on the old site

Data duplication

Data duplication can be useful for copying production data to a test environment.

The data managed by CMS is stored in a JCR database. Several implementations are possible:

  • File system
  • Database (with file system complement)

To find out how your data is stored, go to CMS http://cms.xxxxxx.fr/_admin administration (use administration login, default: admin/admin), in the Repository section:

If the "Store data by default from Jackrabbit " checkbox is checked, then your implementation is on file system only.
If this checkbox is not checked, most data is stored in the database indicated in the Persistence Jackrabbit / Data source field.

The location of your data files is defined in the environment variable AMETYS_CMS_HOME.
Data stored in databases is defined in your configuration, each time you encounter a data source.

  • On the source server

    • If possible, stop Tomcat
    • Follow backup steps: 4. Operation
    • Restart Tomcat
  • On the target server

    • Retrieve the source server archive

    • Follow restoration steps: 4. Operation

      Also make a backup on the target server.
      Do not restart Tomcat at the end of the restore.

    • Retrieve the config folder from the old data and replace it in $AMETYS_CMS_HOME/config

    • Do the same with the $AMETYS_CMS_HOME/data/internal-db

    • Relaunch Tomcat

Configuration

During data recovery, we did not recover the config folder containing the application's entire configuration. You may need it in whole or in part.

Here are the different files that can be found in this folder:

  • config.xml All the information entered in the administration configuration (most of the time, the configuration differs from a TEST environment to a PROD environment (URL, data sources, mode, server mail, etc.).
  • datasources-ldap.xml Description of data sources LDAP ( LDAP sources are often very similar between TEST and PROD).
  • datasources-sql.xml: Description of data sources SQL (The use of the same databases in TEST and PROD is rare, except for specific read-only requirements).
  • group-directories.xml Description of group directories.
  • user-populations.xml Description of user populations (populations are often a little different and more restricted in a TEST environment).
  • synchronizable-collections.xml In order to continue synchronizing data, it may be useful to retrieve all or part of the data from this file. Please note that collections must have the same identifier in TEST and PROD to be compatible.

This list is not exhaustive.

Disk space

To avoid disk space problems, don't forget to delete obsolete data.

Back to top

Installation and operation manual