Last year we were approached by an Avamar customer looking to take their backup replication in a different direction. They were concerned about the ease of backup data access following the loss and failover of a primary data center location. Through discussions with EMC personnel, spurred along by the EMC Avamar Replication Methods and Optimization Strategies white paper (https://www.emc.com/collateral/software/white-papers/h8245-avamar-replication-wp.pdf), they wanted to implement a continuous root-to-root replication strategy.
Most folks utilizing Avamar’s replication abilities are doing so in the traditional manner, root-to-replicate replication. In a root-to-replicate environment one or more Avamar servers can replicate their backed up data to another Avamar server. These replicated backups sit in a unique directory to help differentiate replicated backups from any that may be taken locally. Otherwise the backups look and operate just like any other. They can be accessed for restores, retention changes, or even additional replication to another environment like any other backup.
Root-to-root replication doesn’t just replicate backups between systems, it also sends certain configuration aspects and places them, along with the backup, overtop of base directories. The replicated data is not visible for restores or management until the system undergoes a “new-system” restore. Any data sent to the Avamar outside of the replication stream is presumed lost during the restore. Most of the time root-to-root replication is used for migrating to a new environment, such as the latest generation of hardware.
Unlike root-to-replicate, root-to-root is not a part of Avamar’s GUI. It’s a command-based process to kick off replication followed by a restore on the remote side once the replication is complete. There’s no easy way to monitor the progress other than dumping the command output to a file and tailing the output. In addition, as far as testing has shown, the only way to verify the integrity of the data post-replication is to perform a restore on the remote side.
This is a simple task for migrations. Run a few commands here, run a few commands there, and you’re done. It’s a fairly well documented (well, for EMC) process. It’s taking this process and turning it into a nightly replication task, which complicates things. The process we chose to implement started with several simple scripts, essentially the root-to-root commands and associated tasks like log creation and cleanup. These scripts were then placed in Avamar’s DPN crontab calling the cron_evn_wrapper and mcs_shsh_add library beforehand.
While it would be simple enough to just run the root-to-root command on a nightly basis, the lack of built-in reporting made log management important. Each run’s output was dumped to a file and the files were periodically compressed into a larger archive for safe keeping. The idea was that the backup administrator could go in and manually review the logs as needed to ensure the nightly process has been running without issue. A savvy scripter could easily pull select status messages from the logs and distribute them via SMTP.
Replication & Avamar 7
How would this procedure have worked with Avamar 7? Unfortunately we have not had the opportunity to perform a root-to-root from an Avamar 7 just yet. While the old root-to-root command has been deprecated, the general process should still function with the updated commands.
Is this right for my environment?
It’s important to remember that Avamar is a backup and archive product. Its core function is to backup your environment and safely protect those backups for whatever duration your organization requires. It’s not designed to be a disaster recovery product with a small RTO. Sure, you could certainly use it as a recovery service, but don’t expect the sort of response as RecoverPoint or SRDF.
Take a second to think through the steps your organization would take following the loss of a primary datacenter (or peruse the DR plan you hopefully already have). At what point does the restoration of backup services come into play? Is it high enough up on that list that the potential time savings of a root-to-root scenario would trump day-to-day management difficulties and some basic reconfiguration of a root-to-replicate Avamar server?
Start the conversation.
Whether you’re considering a root-to-root, root-to-replicate, or would like to explore other backup and archiving approaches, Clearpath can help guide you through the process. With a wide spectrum of IT partnerships, we will assess the needs and demands of your infrastructure to determine what solution makes the most sense for your organization. Reach out to us via email or give us a call at 1-866-892-3154.