This article describes the Servicing Director data you should backup as part of your company data backup plan. 

This article does not cover backup methods or strategies in detail, and you should use your local technical support resources to make sure you have backup procedures that meet the demands of your business and your disaster recovery plan. 

The information below is for your local IT or system administrator familiar with Windows and Microsoft SQL server.

Servicing Director consists of at least two sets of data, and possibly a third set, which will need to be part of your backup plan. You should supplement this information with SQL information from your Microsoft SQL support resources.

Here is a description of the three different sets of data:

• The databases:

There are two required databases, named Service and SvcEventMgr. The Service database contains all the loan information, and also the licensing, company, and user configuration information.  The SvcEventMgr database manages the Event Manager application event scheduling and criteria information. The database backups will carry with them any already applied database updates and fixes, such as a Servicing Director Service Pack you have applied.

• The SvcData shared folder:

There is one required shared network folder, which is named SvcData by default. The Servicing Director applications use the SvcData folder to share system-wide reports, and other non-database information, such as user defined screens and import/export map files.  This folder is a local folder on the production server by default.

• The archiver folders:

This set of data is optional.  If you are using the optional Servicing Director archiver to archive documents, then copies of some or all documents have been sent to one or more user defined network shared folders, and references to the documents and their folder locations are in the Service database. Often these folders are on the production server, but the user defined locations can be on another server.

General Backup Information:

1. Make certain you have ongoing backups of your data. If your current production server is suddenly no longer operational, you will have to rely on your data backups to make a new operational server.
2. Your backup procedures or strategy should back up all three sets of data described above, and have the following characteristics: 

• The backups are up-to-date. The backups should be created at least daily, if possible more than one per day.
• The backups include several dates.  The backups should be stored for as many days as you decide. It is possible to not discover a server issuer for more than a day, and it may be necessary to go to a backup created in the past, more than a day old. Also, backups of special dates should be kept longer, such as backups of the end of month or end of the year may need to be kept for a year or longer.

• The backups are kept off-site. The backup files should be transferred to storage locations which are offsite. For example, place the backup files on an external hard drive, CD, DVD, or tape and take the files offsite.

• The backups are secure. The backups will contain non-public information, and the backup files should have restricted access. For example, the backup files themselves can be encrypted and password protected using several different methods. Also, if you store the backup files on portable media, then the media should be physically secure, such as in a locked storage area.

• The backups are verified. The backup files should be verified when they are created and periodically test restored. The backup method you use may have verification options, and you should use those options to verify the backup files. Procedures carefully created only for testing that do not interfere with your production system should be performed periodically using the backup files to make sure they can be restored successfully. 

3. Create a backup before and after your end of day processing:

• Before you perform the Event Manager application “Run All” events process as part of your end of day process, create a backup. Then create a backup after you complete the "Run All" process.
• A significant number of updates and activities take place during the “Run All” process, and in the unusual case that something should fail, it is often valuable to be able to have a backup saved before the process started.

4. The databases are set to use SQL “Simple” recovery mode when installed, which has the following characteristics:

• Effectively disables the creation of SQL transaction logs for the product databases. 
• Without the SQL transactions logs, you rely on full database backups, and you cannot restore the databases to a point in time other than the last full backup of the databases. 
• If you chose to enable the a SQL recovery mode other than “Simple”, SQL will begin to create SQL transaction logs, which can grow the log files with every transaction.  
• If your system has SQL transaction logs, be sure to follow the Microsoft SQL recommendations regarding frequent SQL transaction log backups.
• If your system has SQL transaction logs that are not backed up or truncated, the log files can grow unchecked until all there is no more free disk space, leading the server to fail and stop operating correctly.

5. The Servicing Director databases grow:

• You can estimate using about 1GB of database space per 1000 Servicing Director loans. Your usage may vary. 
• Most Servicing Director data accumulates over time, providing a full audit and historical record on every loan, permanently storing most data whether or not a loan is actively being serviced or not.  Using Servicing Director will typically cause the database size to grow over time.
• There are no significant product provided methods to reduce the size of the database.
• Leave the SQL Server default setting allowing databases to automatically grow enabled or manage the disk space available to allow for the growing database size.

6. Servicing Director does not support SQL database replication:

• If replication is enabled, the Servicing Director database upgrades may fail to upgrade the replicated parts of Servicing Director without displaying an error, and report the upgrade was successfully completed.
• SQL log shipping is an advanced form of replication, which is also not supported but it may avoid a problem with the database upgrades. 

7. Make sure you have your Servicing Director product installation files:

• You may want to create a backup copy of your Servicing Director product installation files. 
• The installation files can be copied to a DVD or a hard drive location. Store this copy offsite.

Locate the data to backup:

• Locate your Service and SvcEventMgr databases. The databases are on the server where the Microsoft SQL server product is installed.  You can view information about the databases and manage the databases using the Microsoft SQL tool called SQL Server Management Studio.  Your backup procedures will place the backups in a user defined location, and you should confirm what location that is.
• Locate your production server SvcData folder. To confirm the SvcData location, review Having the Servicing Director \SvcData Folder on a Server Other Than the Database Server 
• Confirm whether your production server has archiver folders. If your system enabled the archiver option, the archiver folders for that option are user defined. To view your archiver folder locations, follow the instructions in Viewing the Servicing Director Archiver Folders.

Gather the following information about your current system, which will be helpful if you ever need to rebuild the system:

1. Confirm your database version:

• Each full release of Servicing Director will have a upgrade the database contents to a specific version.  
• Sometimes there are updates or fixes for a full release, such as a Servicing Director service pack, which will apply additional changes to the contents of the databases. 
• To view the history of your database upgrades, updates, and fixes, follow the instructions in Viewing the Installed Version History of the Servicing Director Database.

2. Confirm whether or not you will need more than your product installation files to install the Servicing Director applications to match your database:

• If the history of your database indicates your current version has an update, service pack, or fix applied, you will likely need to apply an update, service pack or fix to your desktop applications if you have to install the desktop applications.
• Any update, service pack, or fix applied to your database will be stored in the database backups, and will not need to be applied again.
• Sometimes, updates, service packs, and fixes have changes for the desktop applications and sometimes not.
• To confirm if a service pack is installed on a desktop, review Confirming if a Servicing Director Service Pack is Installed.
• Review the Release Notes or instructions for any updates, service packs, or fixes and determine if there are parts to be applied to the desktop applications. If you do have desktop application updates, service packs, or fixes, then note were to locate the desktop application parts for future reference if you should need to apply them to a new installation of the applications. 
• Servicing Director updates, and service packs, would have been downloaded from the Support Center web site Solution page for Servicing Director.
• Servicing Director fixes would have been downloaded from your support case submitted for the fix.

3. Locate the Servicing Director product installation files of the same release version as your production server.  

4. Confirm the current system requirements for Servicing Director so you will know what computers and software will be needed for a new system. Search for System Requirements in the knowledge base. 

ArticleNumber:

000052864