Peer DRS is a generic data replication framework capable of backing up various types of databases (e.g. MS SQL Server, MS Exchange Server, etc), as well as replicating database changes to one or more remote locations acting as warm or cold standby servers based on the supported database platform's capabilities.

Peer DRS employs a form of log shipping. This is the process of automating the backup of databases and transaction log files on a primary server, and then restoring them onto a target standby server. The key feature of log shipping is the automatic backup of transaction logs throughout the day (or on whatever interval you specify), and the ability to then automatically restore them on a standby server located anywhere in the world. This in effect keeps the two databases in synchronisation with one another. Should the production server fail, all you have to do is point the users/applications to the new server and perform a database role reversal.

Peer DRS is unique from other products. It provides a centralised way to remotely manage and monitor all of your database backups from a single location and from a single application. It has a plug-in architecture allowing it to support different types of database backups from a single application, e.g. SQL Server, Exchange Server, MySQL, etc. In addition, it is extremely flexible and can be configured to handle almost any type of backup scenario. Peer DRS has an easy and intuitive configuration wizard and management interface making backups simple.

Key Features

• Support for MS SQL Server 7.0, SQL Server 2000 (all versions), SQL Server 2005 (all versions), Exchange Server 2000 SP2 or greater, MS Exchange Server 2003 (all versions) and MS Exchange Server 2007 (all versions).
• Performs full backups on-demand or at a scheduled time.
• Performs up to the minute incremental backups and replicate them to one or more warm standby databases.
• Configure and manage all database backups remotely from a central, client-based GUI. It is not necessary to run Peer DRS on the same server as the primary database or target databases are installed on.
• Runs as a system service or run in background in system tray.
• Replicate across a WAN via FTP, SFTP, SSH or a password protected Network Shared drive.
• Resume a file copy from where it last left off for failed file copies to target. Very useful for large full backups across a slow WAN.
• Transfer backups securely across a WAN or LAN using SSH or SFTP
• Configure backup jobs on a per database basis with different configurations and schedules.
• Specify various archiving options and configure how long to keep backups and transaction logs.
• Perform full and incremental backups without restoring to a standby server for remote storage and disaster recovery.
• Cross platform Java bases application that can run on various operating systems such as Windows, Linux, Mac, etc.
• Possible to use the standby server as a live read-only database. The transaction log shipping approach will work, but an exclusive lock on the entire database is required to apply the transaction log changes. Therefore, this will only be possible on lightly loaded read-only databases, or if the user configures Peer DRS to allow the application to close all active connections during a restore.
• Send alert emails if connection to primary database cannot be established or if a backup or restore has not occurred within a configurable period of time threshold.
• Report on all replication activity from a single control panel allowing for easy identification of current errors or for peace of mind by knowing everything is operating smoothly.
• Monitor all replication activity in real-time and capable of setting different debug levels allowing for easy troubleshooting
• All configured passwords are encrypted and out of reach of prying eyes.

A new Small Business Edition has been released. It has all the great features of the full product, runs on all the same SQL Server versions and Windows versions, but with a few limitations, and a great price.

• Maximum of 2 systems acting as source and target machines
• Maximum of 4 databases per source server
• Maximum of 1 warm standby target servers
• Transfers via SSH and SFTP are disabled

Top of Page

How it works

Peer DRS uses a form of log shipping as it methodology for replication, and in order to understand how Peer DRS works, you need to understand how log shipping in general works.

Peer DRS log shipping implementation is straightforward:

1. A Full backup of the database is taken on the primary server and stored in a backup folder located either on the primary server, or more than likely, a network shared drive accessible by the Peer DRS application. The files in this Backup Folder can also serve as your backup archives.
2. If the target copy destination folder is different than the Backup Folder, the files are copied to the destination folder of all configured targets, otherwise no copy is performed.
3. The target standby server maintains a copy of the full database. The target database is not operational; but it can stay in read-only mode.
4. Based on the configured incremental backup schedule (e.g. every 15 minutes), incremental changes are recorded in transaction log files and stored in the shared Backup Folder
5. Transaction log backup files are copied to all configured target database destination folders immediately after an incremental backup of the primary database is performed.
6. Transaction log backups are applied to the target database on the target server in the order that they were taken on the primary server.

Top of Page

System Requirements

MS SQL Server
Peer DRS currently supports all editions of MS SQL Server 2005, MS SQL Server 2000, limited support for MS SQL Server 7, full support for SQL Server running under Windows Small Business Server 2003

1. All primary database and target database pairs should be running the same version of MS SQL Server at the same service pack level. For example, you cannot replication between a SQL Server 2005 database and a SQL Server 2000 database, because of the differences in their structures. The database servers should also be configured similarly. For example, the code page/character set, sort order, Unicode collation, and the locale all must be the same on both servers.
2. Peer DRS is meant to replace an existing backup plan. If you are currently backing up databases using the built-in MS SQL Server BACKUP DATABASE T-SQL commands, using built-in Log Shipping or any other replication type that uses the built-in data maintenance plan, or any other technique that uses the transaction log files and truncates the log files, then the existing backup method will need to be disabled and replaced by this application. You can keep existing backup plans intact for any databases that you don’t intend to backup using this application.
3. The target MS SQL Server database to which the transaction logs are to be restored into must be in an 'unrecovered' state. That is, the last restore process must have been made with the NORECOVERY or STANDBY option. Peer DRS also has the ability to create the database for you on the target which is usually the easiest and best option to use.
4. Peer DRS can only work with databases configured for FULL or BULK_LOADED recovery models. This method will not work with a database configured for a SIMPLE recovery model. You will need to update the recovery model in the Database Properties tab of the Enterprise Manager, or allow Peer DRS to make the change for you.
5. Establish proper security to all the servers. The Windows account you use to set up log shipping must have SQL Server systems administrator (sa) privileges on all the servers.
6. The account that the Peer DRS application is running under must have read-write permission to any network shares being utilized, and the MS SQL Server administrator account being used on the Primary and Target Databases must have read-write access to the configured local directory or network share.

MS Exchange Server
Peer DRS currently supports all editions of MS Exchange Server 2007, MS Exchange Server 2003, and all editions of MS Exchange Server 2000 SP2 or higher.

1. All primary database and target database pairs should be running the same version of MS Exchange Server and at the same service pack level, or the target is of a higher version that is compatible with the primary server. For example, you cannot replicate between a MS Exchange Server 2003 server and a MS Exchange Server 2000 server, because of the differences in their structures.
2. The target storage group and logical database names to which you restore to must match the primary storage group and logical database names. While the path to the database files can be configured differently, we recommend using the same database paths as the primary.
3. The target Exchange server must use the same Active Directory organizational name and administrative group as the primary server and the legacyExchangeDN values for the administrative group must match.
4. In order to restore or replay log files into a target, MS Exchange Server must be installed on the target server and the Exchange Information Store service must be running, all storage groups and databases must be configured and dismounted and each database must have the "This database can be overwritten by a restore " property set. This checkbox is located on the Database properties page for the logical database object.
5. The primary and target databases must have circular logging disabled.
6. Peer DRS must be run under a domain account and this account must belong to the domain's Backup Operators group and must have Full Exchange Administrator rights. When running Peer DRS as a service you will need to customize the service's properties by specifying the log on credentials of this domain account under the "Log On" tab of the service's properties.
7. The domain account that the Peer DRS application is running under must have read-write permission to any network shares being utilized. In general, any network shares utilized must be specified as a UNC e.g. \\server\directory and not as a mapped network drive e.g. X:\directory since most Peer DRS installations will run as a service and will not have access to mapped network drives.
8. When running Peer DRS from a machine different than the target Exchange server, the domain account that the Peer DRS application is running under must have access to the target's Exchange database files via the default configured administrative share(s). For example, if the target's Exchange database files are configured to be stored in the C:\Program Files\Exchsrvr\mdbdata directory then there must be an administrative share setup to \\targetExchangeServer\C$\Program Files\Exchsrvr\mdbdata and the domain account that the Peer DRS is running under must have access to this share. If this is not possible, then you should run Peer DRS on the target Exchange server and grant local access to the domain account.
9. The account that the target Exchange information store process is running under (default is local system account) must have access to the configured log replay folder. If this folder is not specified then the target's file copy directory will be used. If this directory is a network share, then the Exchange information store process will need to be run under a domain account with read-write access to the log replay directory.
10. If you plan on using continuous replication for your incremental backups, which perform incremental backups whenever an a transaction log file is committed to disk on the primary exchange server, and Peer DRS is running on a server other then the primary Exchange server, then the domain user account that Peer DRS is running under must have access to the corresponding administrative share on the primary Exchange server.
11. An existing Exchange Recovery Group cannot be configured on the target server when restoring and replaying logs into the target database. If one is configured, then the restore will automatically be directed to the recovery group.
12. Peer DRS is meant to replace an existing backup plan. If you are currently backing up databases using the built-in MS Exchange Server Backup API via third-party tools, then the existing backup process will need to be disabled and replaced by this application.
13. Peer DRS for Exchange must be run on a supported Windows platform.
14. If you rename a storage group or database name using Exchange System Manager, then you will need to delete and reconfigure the affected replication jobs.

Top of Page