Replication is a key concept of modern scientific method. Experiments need to be replicable for the results to be judged scientifically valid. The same is true of data \u2013 information must be reproducible from the failover site if it is to be trusted.<\/p>\n\n\n\n
In a scientific scenario, replication confirmation is obtained by repeating the experiment using a different data set \u2013 preferably several times. But in the corporate IT environment, there is typically just one repository to work with.<\/p>\n\n\n\n
So how do you confirm validity of your data replication \u2018experiment\u2019?<\/p>\n\n\n\n
Refer to the Replication Application\u2019s Dashboards<\/strong><\/p>\n\n\n\n All data replication tools come with built-in statistic functions, generally available as an at-a-glance dashboard. Your data centre engineers should be routinely checking the dashboard to confirm that the system is reporting successful completion of replication operations.<\/p>\n\n\n\n Obviously, any errors or warnings will flag up and must be corrected immediately to restore the integrity and accuracy of the replicated data.<\/p>\n\n\n\n Query the System Logs<\/strong><\/p>\n\n\n\n The replication system\u2019s dashboards are typically populated using data stored in the underlying event logs. But in order to simplify the data for at-a-glance graphical display, some details will be left out.<\/p>\n\n\n\n Again, your data centre engineers should check the system logs periodically for events that are not included in the dashboard\u2019s simplified view. This is particularly important as low-level issues may only be discoverable through analysis of logs over a longer period.<\/p>\n\n\n\n Compare Known Variables<\/strong><\/p>\n\n\n\n Automated verification of replicated data is extremely useful \u2013 not least because it relieves your administrators of the burden. It is good practice to verify that the reporting is as accurate as the reality, however \u2013 peer review in the scientific community follows the same principle.<\/p>\n\n\n\n You should confirm that replication is accurate by comparing known variables \u2013 such as date\/time stamps and files sizes \u2013 are reflected correctly on the failover system. Manual confirmation of replication procedures will also help towards proving that data safeguards are being properly applied for GDPR compliance purposes.<\/p>\n\n\n\n Test the Failover System<\/strong><\/p>\n\n\n\n Without actually testing the failover systems, it is impossible to confirm that data has replicated correctly. As part of your disaster recovery preparations you should routinely trigger the failover, ensuring that the transition works correctly, and data is present and correct.\u00a075% of businesses do not have a disaster recovery plan\u00a0\u2013 and many of those who do fail to adequately test their provisions.<\/p>\n\n\n\n These tests are absolutely crucial, otherwise your data recovery procedures are built on faith \u2013 which is not<\/em> a typical component of scientific experiments \u2013 nor disaster recovery best practice.<\/p>\n\n\n\n Rebuild Replication Routines<\/strong><\/p>\n\n\n\n Scientific proof is only obtained when repeated experiments yield the same outcomes. Applying that principle to data replication means you must be able to achieve the same data accuracy every time the systems sync.<\/p>\n\n\n\n The only way to prove that your processes and technologies are working is to recreate aspects of the sync process, test them, and compare the results. If these recreated routines replicate the same data to the same standard, you will have scientifically proven that they are \u201cgood\u201d.<\/p>\n\n\n\n