How one tool solved all 5 risks

Note: this post focuses on one specific commercial solution (R-1 from RepliWeb) which I’m working with for the past 3.5 years.

RepliWeb’s R-1 has 2 built-in Transport Engines designed for high bandwidth/low error rate (usually LAN) and low bandwidth/high error rate (typically WAN) networks. Both include a special Per-File Data Integrity Assurance feature that guarantees that no broken/half-baked files will ever reach the Target.

The way it works is very simple yet ultra robust: each file is first replicated to an administrator-defined temporary (hidden) directory on the Target host. Only after the file has been verified to be completely and successfully replicated it is than moved from the temporary location to its final Target destination via native OS rename command and than R-1 replicates the next file.

This powerful one little gadget actually kills two birds!! It absolutely guarantees that no broken/half-baked files will ever reach the Target destination (note that the original file is not touched until the final rename action). It also protects the file from being accessed during replication because the replication is performed into a temporary (hidden) directory where no User or Application will look for the file. The virtue of the rename command is that the whole file is being linked at once to the Target directory so there is zero exposure there.

Risks #1 and #2 – 100% mitigated!

Another mechanism built into RepliWeb’s R-1 is the Transactional Deployment which is a Quantum-Updated Integrity Assurance mechanism. ‘Quantum-update’ refers to the inclusive group of files that need to be deployed on specific host. The mode of operation resembles Two Phase Commit or in layman terms: “All or None”; ALL files are first replicated into an administrator-defined temporary (hidden) directory on the Target host, and are moved to the final Target destination only after two conditions are fulfilled. The first condition is ‘hardcoded’ – all files must have been completely and successfully replication (no point in moving forward if at least one file is damaged/missing). The second condition is selectable by the administrator and can be one of the following:

• As soon as all files made it successfully to the temporary directory
• At specific time of day
• When a designated Trigger File is created by an external application/process
• Upon named User approval

Risks #1, #2 and #3 – knocked out!!

RepliWeb’s R-1 includes another powerful mechanism – inter deployment synchronization points when running a Distribution (1-to-Many) deployments. Simply put, R-1 can make sure that concurrent deployments to multiple Target hosts progress through the same steps simultaneously. When set to synchronize just before the Transaction Commit point an administrator can extend the Transactional Deployment boundaries across multiple hosts, thus unless ALL hosts have received their Quantum-update in whole, NONE of them will be updated!

Risks #1, #2, #3 and #4 – busted!!!

Last, but certainly not least, is RepliWeb’s R-1 Rollback mechanism. This serves in conjunction to the Per-File Data Integrity Assurance and Transactional Deployment mechanisms, providing an insurance policy against wide variety of harmful affects of deployment including successful deployment of the wrong content. When used the Rollback engine will set aside every original file that has been touched by R-1 (i.e. overwritten or deleted) and will record any new file that has been introduced by R-1. At any time the Administrator can instruct R-1 to rollback in time and reverse the affects of all deployments as of specific point-in-time.

Risks #1, #2, #3, #4 and #5 – eradicated from the dictionary!!!!

Happy Deployments.