How do I request that a test database be refreshed with the latest copy of production?
Frequently, a client asks to refresh their test environment with real production data to test a new feature or process. The client may also want to restore the test over production during go-live, where data may be loaded in the test environment for verification and copied to production prior to go-live.
Database refreshes are requested by Veson IMOS Platform clients. On-Premise clients will need to refresh their test database by themselves.
To request the database refresh, clients will need to create the request through the Help Center via the Product Support option. Please expect each database refresh will be completed within a two-hour window time, but in most usual cases the task can be completed within one hour. During this time, users should log out of the target (test) environment that is being refreshed. The source (production) environment is not affected by the restoration process.
Please note that the database refresh is not official unless otherwise confirmed. The confirmation of the scheduled window is dependent upon the availability of our resources. In the event that a request coincides with a public holiday within the specified time zone, we will reach out via the ticket to reschedule for an alternative window time.
Details to be provided when raising a Standard Database refresh request:
When raising a standard database refresh request via the Help Center, please ensure that the following details must be provided:
What is the source environment/database name?
This is usually the Production environment data (E.g. ABCD_prod) where the data is extracted from.
What is the target environment/database name?
This is usually the Test environment data (E.g. ABCD_test) where the extracted data above will be copied into.
What is the date and time in UTC time zone for this to be carried out? Please propose two window times with 2-hour interval each between 01:30 and 20:30 UTC on Mondays to Fridays.
The date and time MUST be specified in UTC time zone and the two window times needs to have a 2-hour interval each between 01:30 and 20:30 UTC on Monday to Friday.
The earliest time window must be 2 business days in advance of the expected execution time of the database refresh. See below for example.
Example: If you raise a ticket on 7 October 2024 (Monday) 02:00 UTC requesting a database refresh for the test environment, the earliest window time to propose is 9 October 2024 (Wednesday) 02:00 to 04:00 UTC. The second window time can be any later date and time within the "Standard ISD request window“ table below (e.g. 9 October 2024, 04:00 to 06:00 UTC).
Please note that changes CANNOT be accommodated at weekends.
Example: If the proposed window time is 12 October 2024 (Saturday), 01:00 - 03:00 UTC, this request cannot be accommodated.
For point-in-time refresh of the test database, please refer below.
Do you want to preserve user info (security list) on the target environment?
The answer should be a “yes” or “no”.
The default is no. This means that the security list from the target (test) environment will be replaced by the security list from the source (production) environment.
If the answer is yes, please note that both the source and target environment must be on the same schema version. If they are different, we will reach out to arrange for a schema upgrade of both the source and target environment to the latest version.
Please note that we will not accommodate requests to copy over the configuration flags or messaging service configurations from the source to the target environment.
Overriding the configuration flags in the target environment can cause the environment to be inoperable, along with changes in the User Interface. Copying over the messaging configuration from the source environment can cause the data from the target environment to be inadvertently sent to the source environment or interfaces that are linked to the source environment.
Standard ISD request window (Mon-Fri, excluding regional public holidays):
From: | To: | |
|---|---|---|
Summer Time: | 01:00 UTC | 20:30 UTC |
Winter Time: | 01:00 UTC | 21:30 UTC |
Note: Any request outside the above times needs to be checked internally for approval.
For Point-in-Time Database Refresh
For a simple standard copy of the database (i.e. latest production copied to test), two business days' notice is required. If a test database needs to be refreshed with a copy of the production data from a specific point in time in the past, the date of the point-in-time database cannot be more than 10 days old from the require point-in-time execution date. In addition, a two-weeks' notice is required. We recommend to submit the request as early as possible.
Example 1:
If the test environment needs to be refreshed with production data up until 30 September 2024 12:00 UTC, the LATEST time to execute this request is 10 October 2024 12:00 UTC. With the two-weeks' notice, the latest time to submit the request will be 26 September 12:00 UTC.
Example 2:
If the test environment needs to be refreshed with production data up until 30 September 2024 12:00 UTC, and request is submitted on 23 September 2024 12:00 UTC, the earliest execution time, considering the two weeks' notice, will be 7 October 2024 12:00 UTC.
Things to note before database refresh
Before restoring a database refresh request, please bear in mind:
Configuration flag list will NOT be overwritten.
Messaging service configuration will NOT be overwritten.
Customers have the choice of whether the users are retained from the restore or overwritten (in question 4 above).
If you have a user that is used for API calls - take note of the email address of that user, and once the database is restored, change the email address back to the original one (i.e. before the DB restore) in the user profile of the Security list. Log out and log in again in order to see the Veslink API section.
