The rostrvm system, particularly the servers, require certain maintenance operations to be performed regularly to prevent system resources from being exhausted. The types of operation that need to be performed are:

 

---

Backing up your system

As you use your rostrvm system, certain files are inevitably changed.  Changes may be applied to your rostrvm configuration database tables as new components are added to your system.  Changes to your configuration database are applied as new devices, users, etc. are added to the system.  New CallDirector routing scripts are created as routing algorithms are adjusted to handle new business requirements.  Plus many more.  To ensure none of these changes are lost it is important that your rostrvm system is continuously backed up.

Following installation or upgrade rostrvm will be configured for an incremental backup scheme.  This entails a periodic full backup in conjunction with a continuously running incremental backup log.

Full backup

The full database backups can be scheduled using the rostrvm Manager Scheduler.  Following installation and/or upgrade backups are scheduled for 3am every Sunday morning.  The files are created in <root>\backups\... with a name of rostrvm_<vernum>_<number>.rbk. Number is a backup number that cycles round so that there are a number of backup files (the oldest file will be overwritten when appropriate). Vernum is the version of rostrvm without the dashes and dots.

The scheduled backup command can be amended to cycle a different number of full backups (other than the default 2) by changing the parameter CYCLE <number> from the Backup configuration database scheduled task Configure ... option.

Incremental backup

Incremental logs are placed in the <root>\Database\data\... directory with a name of rtmbinlog.<increment> with the other MySQL files. Increment is a 6 digit number with leading 0's assigned by MySQL and populated when changes are made to the database.  The logs show a record of all changes to the database and can be viewed using the MySQL utility <root>\mysql\mysqlbinlog.exe providing the name of incremental log file to examine.

The rtmbinlog files can be quite large so it may be easier to read them by piping the output into a file.  For example:

Logon to your rostrvm server and from a command line window navigate to the rostrvm mysql directory <root>\mysql and run the following mySQL command:

    mysqlbinlog.exe <root>\Database\data\rtmbinlog.000001 > mybinlog.txt

 

This will create a file called mybinlog.txt which can be loaded into a text editor for analysis.

This file could be used to pinpoint the exact time of a query that caused a problem.  If appropriate, you could then follow the Restore procedure below to restore up to the point just before when this query was executed.

---

Restoring your database

IMPORTANT: Read the whole section before starting a restore

Please contact your system administrator for the mySQL root user password.

Following accidental loss of data (or corruption) from your rostrvm system it may be necessary to restore your database back to a known safe point in time.  This can be done using standard MySQL utilities and commands using the appropriate full back-up file and optionally one or more of the MySQL incremental backup logs.

Consider the case where for some reason the system administrator wishes to restore the database to the previous day (e.g. incorrect data was accidentally imported that corrupted or replaced valid data).  The following actions need to be performed:

 

Stop your rostrvm system

rostrvm reads and updates the database regularly even when idle (i.e. no calls are in progress and no agents are logged on).  For this reason before attempting to restore the data the Rostrvm Service should be stopped.  Leave the mySQL Service running.

Restoring a full backup

To restore the last full backup (.rbk file) prior to the time you are restoring to, logon to your rostrvm server and from a command line window navigate to the rostrvm backup directory <root>\backups.  From here type the following MySQL command:

   <root>\mysql8\mysql --user=<Username> --password=<password> --port=3308 rostrvm_920 < rostrvm_920_<number>.rbk

where

   Username and Password are those created when the server was first installed or last upgraded;
   rostrvm_920 is the database name;
   rostrvm_920_<number>.rbk is the name of the relevant full backup file.

If you do not have a backup file (i.e. the system has not yet performed a backup) you can restore the system using only the incremental backup file(s).  Before you do this you need to delete and re-create the database (Note: this will remove all data from the database prior to the restore):

   <root>\mysql\mysqladmin --user=root --port=3308 --password=<Password> drop rostrvm_920 create rostrvm_920

where

   Password is the root password for the database;
   rostrvm_920 is the database name;
 

Restoring the incremental backup

First you need to identify the incremental backup file(s) since the relevant full backup was run.  Note: there may be several incremental backup files required to perform the restore.

Identify the incremental backup files

Check the "Date Modified" property of the incremental backup file identified above.  If the Modified Date/Time is before the target restore date and time then you need to look at the subsequent incremental backup files until you identify the file whose Modified Date is after the target date and time.

You will then need to restore each incremental file up to and including the file identified above by listing them using the following commands.

Command for restoring an incremental backup

The following command should be used to restore the first incremental backup:

   cd <root>
   mysql8\mysqlbinlog --database=rostrvm_110 Backup\rtmbinlog57.<increment> Backup\rtmbinlog57.<increment2> … | mysql8\mysql --user=root --password=<Password> rostrvm_110

where

   Password is the root password for the database;
   rostrvm_110 is the database name;
   rtmbinlog57.<increment> is the name of the required incremental backup file (e.g. rtmbinlog57.000007)

Re-start you rostrvm system

Once all backups have been restored the rostrvm system can be re-started in the normal way.

---

Extracting and Purging your Management Information Statistics

The SuperVisor server module writes its statistical information to the MIS database. Over time this database will grow in size. It is therefore recommended that you archive and purge your data at regular intervals to ensure that the system does not run out of disk space.

As for back-ups, an extract and purge utility is provided for this function. This utility is invoked automatically by rostrvm.

Automatic MIS extract and purge

It may be more desirable to set up a regular automatic MIS extract and purge task. By default rostrvm will purge MIS data at 2am every morning, and will remove MIS older than 1 month.

Also at this time, rostrvm will extract the previous day's MIS data into CSV text files suitable for import into another database or a spreadsheet for further analysis. These files are placed in the ExtractedMIS sub-directory under the rostrvm home directory.

The automatic back-up facilities are set through rostrvm Manager Scheduler.

---

Purging your rostrvm log files

Every rostrvm system creates a number of new log files for each day of operation. It is strongly recommend that the system manager periodically purge older log files to prevent the situation where there is no free space left on the disk. You can purge log files using the usual file deletion method for the operating system concerned.

The regularity of such purges depends on the disk’s capacity and the typical size of the log files on the system in question. rostrvm log files can vary greatly in size and this depends on the severity of log output required (the lower the severity, the more output is created), the activity levels in the contact centre and hence the rostrvm system, and the behaviour of the system (a system encountering fault conditions will produce more log output than usual).

It is left to the discretion of the system manager to decide how often and to what extent to purge log files, but we suggest that once every week would be sufficient. It should also be noted that by default only log files of less than 3 months old are kept. Files older than this are automatically deleted by the system each night.

To set up the scheduled automatic log purge

The automatic log purge functions differently from the manual purge. Under the rostrvm log directory a number of sub-directories (one for each month) are created as required (named <MONTH><YEAR>, e.g. Jan21). When the purge is scheduled all log files over 2 days old (i.e. prior to yesterday) are zipped and moved into the appropriate sub-directory.

The automatic back-up facilities are set through rostrvm Manager Scheduler.

---

Email and Voice Recording archives

Voice Recordings

Voice recordings are stored both in the rostrvm database and in voice archive files.  Voice archive files may be stored on the rostrvm server for easy access, or be stored separate from the rostrvm server for access using AuditLog viewer.

Each archive file contains a number of recordings (and associated MIS) covering a particular period (e.g. a day, a week, a month etc.); when the archive file reaches a configured size a new archive file is started.  The system manager should manage the disk with regard to space available for recordings (warnings will be provided by rostrvm when space is low).

As a rough guide 1Gb provides approximately 1,000 hours of continuous recording.  Assuming an agent spends 5 hours per day 5 days per week talking that equates to 40 weeks of voice recordings.  A 1Tb drive could store almost 4 years’ worth of recordings for 200 agents.

Configuration

It is possible to specify the time each day that voice archiving is activated from the Recording Archiver entry in the Scheduler page in Manager.

The user may specify the location for the archive and the maximum size for a single archive file from the switch properties Media Archiving tab in Manager.

Recordings are stored in file(s) with the name:
 Voice Recording <from datetime> <to datetime>.sdb;

Emails

These are archived and configured in exactly the same way as voice recordings.  The only difference is the name of the file(s) in which they are stored.  In this case these are:
 Email Archive <from datetime> <to datetime>.sdb;
 SMS Archive <from datetime> <to datetime>.sdb;
 Chat Archive <from datetime> <to datetime>.sdb.