Skip to content

Instantly share code, notes, and snippets.


rbocchinfuso/ Secret

Last active May 29, 2018
What would you like to do?
Isolated Recovery high-level process overview

Isolated Recovery high-level process overview

  • Macro level due diligence and requirements gathering.

    • Collect and aggregate data from replication / backup process, disk based backup target, backup software, etc...
      • Develop a macro level understanding of the logical and physical implementation.
    • We need to move quickly here but without buy-in and a plan to execute we do not want to start prototyping.
  • Build a scope based on agile methodology with 2 week sprints to begin development (high-level outline below)

    • Requirements documentation
    • Prototyping and sandboxing
      • Close air gap
        • Automate establishing layer 1 connectivity (e.g. - “no shut” on switch interfaces)
        • Establish replication (sync source and target data domains)
        • Monitor replication status
        • Poll replication status
        • One source and target are in sync begin to the WORM process
      • Retention lock (worm scripting)
        • Code the process to set atime to WORM lock data on target DD
        • Trigger hashing
      • Source and target hashing
        • Code the process to validate the binary signature of all source and target isolated recovery
        • Identify and report any anomalies
        • Once source and target are validated create the air gap
      • Create air gap
        • Suspend replication processes
        • Automate severing layer 1 connectivity (e.g. - “shut” on switch interfaces)
      • All of the above need to happen and be coordinated with backup software so process.
      • Gap analysis and remediation
        • Can the current state design support the solution we prototyped.
          • E.g. – Do we have the required protocol access to the devices to set atime for retention lock from third party hosts. What potential changes need to made to the current state infrastructure vs. logic changes that need to be made our code.
          • Decide on the best path to resolution and execute.
            • Either making architectural changes to the current infrastructure or modifying our logic.
    • Test
    • QA
    • Roll to production
    • Support


  1. Fork it!
  2. Create your feature branch: git checkout -b my-new-feature
  3. Commit your changes: git commit -am 'Add some feature'
  4. Push to the branch: git push origin my-new-feature
  5. Submit a pull request :D


  • version 0.1 (initial release) - 2017/10/03


Rich Bocchinfuso <>


Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment