Disaster recovery (DR) planning is a bit like purchasing those pricey, added insurance addendums when planning a once-in-a-lifetime trip—it's distasteful to shell out the extra cash to prepare for the unlikely, but with so much at stake, it's hard to ignore the risks.
Many companies—like too many travelers—are still doing too little to protect their key systems despite the well-publicized fall-out from catastrophes like Hurricane Katrina or even from human error, which is the biggest culprit of data loss and downtime. Data compiled by Infrascale revealed that 40% of organizations ranked their ability to recover operations after a disaster as fair or poor and that it takes almost 18.5 hours, on average, to recover after a disaster. That might explain the high price tag associated with inadequate disaster recovery practices: Research pegs the average cost of one hour of downtime at $8,000 for a small company and up to $700,000 for a large enterprise.
You might be wondering what all this disaster recovery stuff has to do with engineering workflows and in particular, Adept. It's quite simple actually: While your organization may (or may not based on the research) have its own disaster recovery tools and practices in place, it's a really smart idea to have a full-blown DR strategy for Adept given its critical role in the product development process.
What's the point of having a separate Adept plan if IT already has enterprise DR and business continuity covered, you ask? Well, suppose the enterprise DR plan doesn't account for Adept—it's only focused on more widely used enterprise systems. Or what if Adept was introduced by engineering, thus is flying under the radar screen of IT—meaning that it's not covered by a broader enterprise DR plan. In a different scenario, maybe IT has orchestrated an enterprise DR initiative that encompasses Adept, but it's triggered only during a system-wide failure, not when the Adept server goes down.
As you can see, there are a variety of scenarios where DR planning for Adept isn't covered, even in organizations with fairly mature DR practices. With that in mind, here are a few recommended best practices that will ensure Adept is fully safeguarded and engineering workflows left undisturbed:
A typical Adept configuration has an Adept Server, an SQL database (Oracle or Microsoft SQL) and the Vault. The recovery server is a secondary piece of hardware with a fully configured version of Adept (a mirror image of the production server) along with a Vault, set up as a satellite with files replicated to that server. Users need to find the optimal place to house the recovery server and then establish a replication schedule depending on the level of recovery that's necessary for their specific business practices.
Introduced with the Adept File System (AFS) in the Adept 8.4 release, Adept Vault Replication lets multiple geographic locations share a common Adept Vault, ensuring they are always working on the latest version. The Adept Vault structure gives users a unified view of files in globally distributed environments; it can serve as the backbone of a solid disaster recovery plan, providing protection for databases, individual files, drawings and documents.
Even though the Adept recovery plan is separate from an enterprise strategy, it's best to get IT involved, both to enlist their help with set up and to ensure that Adept recovery remains part of the broader IT business continuity effort.
Run through the Adept DR program at least once or twice a year, not just during initiation. There are many things that could happen during the testing process, so it’s best to catch and fix them before any irrevocable loss of data.
With Adept as the cornerstone of engineering document management and more broadly, product development, neglecting to do targeted business continuity planning is a recipe for disaster. Schedule your one-on-one demo.