RepliStor is a reliable, easy to install out of the box data, replication solution. Where the protection and availability of business critical data in Windows NT and Windows 2000 environments is required, RepliStor has become the product of choice. RepliStor copies files, directories, volumes, shares and select registry keys from one or multiple computers - to one or multiple systems. Advanced features such as filtering and scheduling allow for flexibility in the selection of what information gets replicated and when. In addition, RepliStor is an ideal add-on distance solution to other backup and availability solutions such as NetWorker, Co-StandbyServer, Automated Availability Manager .

The use of LANs or WANs (Local or Wide Area Networks) allows RepliStor to protect more than just data; it can protect an entire site. Updates are captured to selected files on source systems and forwarded across LANs and WANs to user-specified target systems. In the event of data loss or hardware failure at the source location, an up-to-date copy of every specified file is always available on the network. RepliStor is also an ideal solution to distribute or consolidate information. Reliability and ease of use, combined with the fact that RepliStor can replicate to non-identical systems, makes it one of the most popular choices by customers.

Frenquently Asked Questions

Q: Does RepliStor replicate data?

A: No. After the initial synchronization, which does copy all of the source files to the targeted server, RepliStor keeps the source and target servers synchronized by replicating file operations, not data. Some examples of file operations are data write, truncate, rename, delete and permissions update. This means that if the SQL server updates a 1.5G database by writing 300 bytes at a certain offset, that 300 byte WRITE command is performed on the target just as it had been done on the source.

Q: Does RepliStor use a timer to periodically check when a file has changed? If so, can I make the poll time shorter so RepliStor works faster?

A: RepliStor does not poll for changes. Any file operation is immediately put into a queue to be sent to the targets. There are no timers throughout the process, data is sent immediately. A portion of RepliStor resides in the Operating System kernel and monitors all file activities. Because of that, the software actually knows the file operation succeeded before the application that performed it does.

Q: Does RepliStor preserve the update sequence between files and specifications?

A: Many applications are very careful to update files in a particular sequence. The reason for this is if the computer goes down unexpectedly, the application will be able to recover the files when the computer is restored. Database servers (SQL, Oracle, etc.) are good examples of this. Since RepliStor replicates file operations, not portions of the data stream, the update ordering is always preserved. In the case where multiple files are being updated, RepliStor will also preserve the update order across all files. This means that in the event of a system crash at the source, the database server will always be able to recover the database that was replicated on the target system. It does not matter if files are spread across several specifications. The sequence that occurred on the source is preserved on the target. If a file becomes blocked on the target system, updates for that file are saved and applied after the problem has been resolved. If this occurs, then the updated relationship the blocked file has with other files is lost. Therefore it is very important to avoid blocked files. A well-designed configuration should eliminate the risk of blocked files.

Q: How can I avoid blocked files on the target server?

A: A file can become blocked for a variety of reasons. Here are the most common: The file is in use by another application on the target. Make sure there are no applications that can open the files being replicated to the target, on the target. To make sure this does not happen, use the "Protect Target Files" option (in the Specification Options tab) and help insure that no application can modify the files on the target server. RepliStor does not have sufficient permissions to update the files on the target. Make sure to use the "Set Perm" functions on both the source and target systems when creating a specification that gives RepliStor the sufficient permissions to update files on the target. There is not sufficient disk space on the target server for the disk operation. There must be enough disk space on the target for all data on all source systems that are replicating to the target.

Q: What size should the Kernel Cache be?

A: The Kernel Cache is a portion of system memory that holds the queue of disk operations that are being forwarded to the target. If this area fills, then it will overflow to disk files created in the RepliStor data directory (OC$xxxxx files). The Kernel Cache should be sized so it does not overflow during normal mirroring operations, maximizing performance. However, overflow during a synchronized operation is a minor performance problem, and overflow if a site is blocked probably cannot be avoided. Unfortunately, there are too many variables affecting what the size should be to be able to provide an easy formula. Those variables are available bandwidth, CPU speed, available memory and the rate and size of file changes by applications. This is how to set the Kernel Cache size: Set the size of the Kernel Cache (which defaults to 4 Megs) to something much larger, while assuring that other applications and the OS still have sufficient memory. The size is changed from the RepliStor user interface, Maintenance/Options menu and Advanced tab. Bring up the Performance Monitor using the RepliStor user interface, Help/Performance Monitor menu. Monitor the following counters over the course of the next several days: Kernel Cache percent Used Kernel Cache percent High Water Mark Kernel Cache Overflow Count An overflow of the Kernel Cache during a synchronized operation may be unavoidable and is not a major performance problem. The Kernel Cache should be sized so that it does not overflow during normal mirroring operations, but is not so large as to cause the rest of the system to crash because of low available memory.

Q: Why should I use an asynchronous replication product? Isn't synchronous better?

A: Synchronous and asynchronous replications both have advantages and disadvantages, and the requirements of the particular application should determine which should be used. The following table shows typical considerations to make when deciding which would be better for your application: Data Availability For synchronous mirroring, the source and target systems are always synchronized. In the event of a system crash on the source system, the target system’s data will always be up-to-date. On an asynchronous replication configuration, it is possible and generally typical that the target system will be at least one, possibly more, file operations behind what has occurred on the source. Performance During a synchronous replication, any file updates must be committed on both the source and target before the application gets notified that it has been successful. This means that the performance of the application is now tied to the network speed and traffic as well as the performance of the target system. On an asynchronous replication configuration, the performance of the source application is not significantly affected since the file operation is allowed to complete while it is being forwarded to the target system. The source and target systems are allowed to run at full speed because the target system does not slow down the source. Distance Replication Synchronous is only practical when replicating over a fast LAN. If the network bandwidth is limited, the application, and in many cases the entire operation of the source computer becomes so slow it can be unusable. This means that in a WAN situation, asynchronous replication is the only option.

Q: What tuning is available to possibly make RepliStor work faster?

A: Kernel Cache The Kernel Cache is a fixed size portion of memory that holds file operations that are in queue to be forwarded to the target system. It is important that this memory does not overflow during normal mirroring operations. If it does, it uses disk files to hold the queue and performance will be affected. See “What size should the Kernel Cache be?” TCP/IP Buffer Size On fast networks, a performance increase may be realized by increasing the TCP/IP buffer size (Maintenance/Options, Advanced tab) above its default. This field defines the send/receive buffer size used by RepliStor and also by the kernel for each connection. The buffer size should not be increased past 64k.