Using a Test-Bed Backup

In certain situations it may be useful to make a copy of all the data in a given LISTSERV Maestro installation and transfer it into a second (test-bed) installation without affecting the production installation.

•

Testing a software upgrade – If the production LISTSERV Maestro installation has a high-availability requirement, then it is prudent to upgrade a test server first to make sure the upgrade will not result in unanticipated down-time of your production system. L-Soft performs thorough testing before releasing new versions, but it is not always feasible to test every possible situation. To make sure the upgrade process will work flawlessly with your data, you can set up a “test-bed” server with your production data and perform the upgrade there first. If any errors result, these can be addressed by L-Soft support before you upgrade your production server.

•

Beta testing – If you are participating in a beta-test of an upcoming version of LISTSERV Maestro, then you may want to test the new features using your production data, but without running beta software in production. By beta-testing in an environment identical to your production environment and using your production data, you can ensure that there won’t be any issues specific to your installation when the product is released. By trying out the new features with your production data, you can anticipate how you might use those features in production and even suggest improvements to the developers so that the new features really meet your needs. It is much easier to discover such opportunities for improvement when working with real data and realistic scenarios than when using test data and test scenarios.

•	Training – If you are conducting training (or hiring L-Soft to conduct training at your site) in LISTSERV Maestro for your users, then it may be helpful to conduct the training using real data and realistic scenarios.

In order to create a Test-bed backup, you cannot simply trigger a regular backup on the original system, and then restore this backup into the test system. Doing so has several pitfalls which could, in a worst case scenario, destroy some of the data in the original production system.

•

If, at the moment the backup is triggered, the original system contains a mail job in the Outbox and it’s scheduled for delivery, and this backup is restored into the second system, and the scheduled delivery time arrives, then the second system would actually send out the job to the given recipients.

•

And since the job is a copy of a real job on the production server, with real recipients, this mailing from the test system would go out to these real recipients. At the same time, since the same job also still exists on the production server, it will be mailed out from there. As a result, the recipients will actually get two copies of the same mailing.

•

If the production server installation is distributed over several servers (for example where LUI is installed on one server and TRK is installed on another server), then the information about how the components are distributed will also be contained in the backup data. Then, you would have to be very careful when restoring this backup into the test server so that you do not accidentally end up, for example, connecting the test server LUI with the TRK of the original production system (or vice versa).

•

If the production server installation uses an external system database, then the connection information for this external database is also stored in the backup data. This means that, during the backup restoration, this information will also be restored to the test server. Because of this, the test server will try to connect to the same external database (and use it as its system database) as the production server. At worst, the test server could then delete or change data belonging to the production system!

Because of these pitfalls, it is generally not advisable to restore a backup of an existing and running system into a different system. Therefore, the idea of restoring a backup from the original server to the test server is not a good idea.

To solve this problem, LISTSERV Maestro offers the Test-Bed Backup feature. A test-bed backup is similar to a normal backup of a system, meaning it contains all the system data (all user accounts, jobs, reports, tracking information, hosted recipient data, etc.). However, all the critical aspects of the data, like information about distributed components, connection information for external databases, scheduled jobs in the outbox, etc. have been changed by the system (when the data was written to the test-bed backup) so that they no longer pose a risk when the test-bed backup is restored to a test server. Simply put, a test-bed backup is as close a copy to the data of the original system as possible, but with all the critical information removed or changed.

•	Component distribution information. If the original system was distributed over several servers, then the test-bed backup is no longer aware of this and assumes that all components are on the same server (i.e. the “localhost”).

•	External database information. If the original system used an external system databases, then the test-bed backup is no longer aware of this and assumes that the internal system database is used.

•	Instance-ID information. The test-backup backup does not contain the original system’s instance ID. This means that during the first start of the test server, it will generate its own instance IDs.

•

LISTSERV connection host information. The test-bed backup does not contain information about which LISTSERV host to use; therefore, this information needs to be added manually (via the Administration Hub) after the test-bed backup has been restored to a test server. This allows the test server to connect to a different instance, if desired.

•	Tracking host information. The test-bed backup does not contain information about which tracking host name to use; therefore, this information needs to be added manually (via the Administration Hub) after the test-bed backup has been restored to a test server.

•

Scheduled jobs. The outbox send queue option in the test-bed backup is set to Sending is disabled. This means that any queued jobs in the Outbox are not automatically delivered by the server into which the test-bed backup is restored. If you need to send any jobs on the test server, then it is therefore necessary to re-enable the Outbox (via the Administration Hub) on the test server. However, before re-enabling the Outbox, make sure to check it for any production jobs still left in it. If there are any left, then delete or revoke those jobs to stop them from being delivered when the Outbox is re-enabled.

With the risky information being removed or reset to appropriate defaults, it is safe to restore the test-bed backup to a test server without the risk of damaging or impacting the production server.

To create a test-bed backup on the original system, log into the Administration Hub of the original installation. Click the Global Component Setting icon, then Administration Hub, and finally General Administration. From the General Components Settings for Administration Hub screen, click the [Create Test-Bed Backup] button.

•	The folders where the backup data is stored are always the following three folders:

The backup is always written to a folder called “test-bed_backup” inside of the home folder of each of the three components (on their respective server, if the components are installed on different servers).

•	Just like with a normal backup, a test-bed backup consists of the backups of all three components, i.e. a complete test-bed backup encompasses all three of the above folders.

For each test-bed backup that is created, a backup report is written to the log folder of the Administration Hub component (“[install_folder]/hub/logs”), just like for a normal backup. The content of this report is also very similar to a normal backup report, only that it clearly states that this backup is a test-bed backup (and thus contains data which has been changed slightly, in comparison to the original data).

•	Similarly to a normal backup, a test-bed backup is only valid (i.e. contains complete and restorable data) if the last line of the report reads:

Just like a normal backup, it is important to restore all three components and also to make sure that the backup data for each component was written by the same backup (or test-bed backup in this case). As with a regular backup, this verification is done by verifying the backup ID (Test-Bed-Backup-ID) in the three backup parts.

The test-bed backup is not restored on the original system where it was created; instead, it is restored on a different system or the “test server” system. It is also important to know that a test-bed backup must only be restored to a test server that was installed on a single server, including the internal database. A test server must meet the following requirements:

•	All three components (HUB, LUI and TRK) are installed on the same server.

•	The internal MySQL database is also installed and used as the system database.

These requirements are easily met by installing a fresh installation of LISTSERV Maestro on the test server, and then selecting all three components, plus the internal system database, when running the Setup wizard (or using the Express Setup option in the Suite Installation Kit for Windows).

Once you have such a test server system and have also identified the test-bed backup you want to restore, then you can restore it by following the normal backup restoration steps.