How do YOU get your data where you need it, when you need it?
RepliStor increases the availability of your data by delivering real-time replicas. Creating as many as you need, in virtually any location, RepliStor allows you to use your data for anything from off-line backup protection, disaster recovery switch over, file and content publication across web farms, to decision-support data warehousing and countless other applications. RepliStor supports your critical Windows environments in flexible configurations from one-to-one to many-to-many, across local and wide area distances. As long as you can connect to it using TCP/IP, RepliStor can get your data there!
Features & Benefits
Real-Time Data Protection
Protection against server or site failure (Redundant data sets)
Rapid recovery of critical servers
Easy to Install and Use
Simple installation (out of box solution)
Graphical User Interface manages multiple RepliStor Servers
Local or remote installation and management
Certified for Windows 2000 Server and Advanced Server
Minimizes Recovery Time
Recovery from complete server losses with limited manual intervention or server reboot
Immediately available data on target systems
Works over Local or Wide Area Network (LAN or WAN)
Copies Open Files and Select Registry Keys
All Windows NT/2000 based backup/recovery solutions
Source and target systems need not be identical
Optimized for Active Directory
Versatile Configuration Options
One to One Replication
One to Many Replication
Many to One Replication
Many to Many Replication
Three Levels of Security
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
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
|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:
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
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.
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.
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.