Disaster Recovery

apiVersion: soultec.ch/v1kind: Servicemetadata: name: disaster-recovery locale: en labels: group: infrastructure capability/backup-recovery: 2.18 capability/architecture: 2.93 capability/migration: 3.54 vendor/hpe: 2.04 vendor/veeam: 4.22 annotations: source: src/content/services/en/disaster-recovery.md route: /en/services/disaster-recovery/ schema: /nerd/schema/services.json markdown: /en/services/disaster-recovery.mdspec: title: Disaster Recovery group: infrastructure order: 7 tags: [backup-recovery, architecture, migration] vendors: [hpe, veeam] summary: >- RPO and RTO first, technology after. And a plan that has never been tested is a hope. photoNeed: >- A failover rehearsal in progress: two engineers at a screen with a runbook open beside them, mid-test rather than posed stub: false draft: false sections: - heading:

What it protects against

body: | Power failure, water, fire and earthquake, all rare and all possible. And ransomware, where a properly thought-through disaster recovery plan is the difference between days and weeks. - heading:

Where we start

body: | With two numbers. **RPO**, how much data loss is acceptable, and **RTO**, how long it may take to be running again. Both have to be verified and signed off with the stakeholders, because they carry the whole architecture and are not a technical quantity. After that we classify and prioritise data and systems. Not everything needs the same number, and trying to treat everything alike is the most common reason a plan becomes unaffordable. - heading:

How the design comes together

body: | It accounts for the workloads in your datacentres and in your public clouds, along with availability and performance requirements. Site choice feeds in too: where your datacentres and cloud regions sit partly determines what is possible at all. - heading:

Implementation, and the part that gets skipped

body: | We build on Zerto and Veeam. Both allow the real event to be rehearsed: virtual servers can be started in a sandbox at the recovery site and checked without touching production. That is exactly the part that gets skipped. Regular test scenarios with the system administrators and the affected departments are what separate a plan from a hope.status: corpus: 267 solutions: - {ref: solutions/hpe/hpe-server, score: 0.50} - {ref: solutions/veeam, score: 0.43} - {ref: solutions/hpe, score: 0.39} - {ref: solutions/omnissa/citrix-takeout, score: 0.23} alsoLike: - {ref: services/engineering, score: 0.66} - {ref: services/datacenter-lifecycle, score: 0.61} - {ref: experts/marco-betschart, score: 0.34} experts: - {ref: experts/marco-betschart, score: 0.34} - {ref: experts/rico-lenherr, score: 0.34} - {ref: experts/marco-mattei, score: 0.31}

{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "disaster-recovery", "locale": "en", "labels": { "group": "infrastructure", "capability/backup-recovery": "2.18", "capability/architecture": "2.93", "capability/migration": "3.54", "vendor/hpe": "2.04", "vendor/veeam": "4.22" }, "annotations": { "source": "src/content/services/en/disaster-recovery.md", "route": "/en/services/disaster-recovery/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/disaster-recovery.md" } }, "spec": { "title": "Disaster Recovery", "group": "infrastructure", "order": 7, "tags": [ "backup-recovery", "architecture", "migration" ], "vendors": [ "hpe", "veeam" ], "summary": "RPO and RTO first, technology after. And a plan that has never been tested is a hope.", "photoNeed": "A failover rehearsal in progress: two engineers at a screen with a runbook open beside them, mid-test rather than posed", "stub": false, "draft": false }, "sections": [ { "heading": "

What it protects against

", "body": "Power failure, water, fire and earthquake, all rare and all possible. And ransomware, where\na properly thought-through disaster recovery plan is the difference between days and weeks." }, { "heading": "

Where we start

", "body": "With two numbers. **RPO**, how much data loss is acceptable, and **RTO**, how long it may\ntake to be running again. Both have to be verified and signed off with the stakeholders,\nbecause they carry the whole architecture and are not a technical quantity.\n\nAfter that we classify and prioritise data and systems. Not everything needs the same\nnumber, and trying to treat everything alike is the most common reason a plan becomes\nunaffordable." }, { "heading": "

How the design comes together

", "body": "It accounts for the workloads in your datacentres and in your public clouds, along with\navailability and performance requirements. Site choice feeds in too: where your datacentres\nand cloud regions sit partly determines what is possible at all." }, { "heading": "

Implementation, and the part that gets skipped

", "body": "We build on Zerto and Veeam. Both allow the real event to be rehearsed: virtual servers can\nbe started in a sandbox at the recovery site and checked without touching production.\n\nThat is exactly the part that gets skipped. Regular test scenarios with the system\nadministrators and the affected departments are what separate a plan from a hope." } ], "status": { "corpus": 267, "solutions": [ { "ref": "solutions/hpe/hpe-server", "score": "0.50" }, { "ref": "solutions/veeam", "score": "0.43" }, { "ref": "solutions/hpe", "score": "0.39" }, { "ref": "solutions/omnissa/citrix-takeout", "score": "0.23" } ], "alsoLike": [ { "ref": "services/engineering", "score": "0.66" }, { "ref": "services/datacenter-lifecycle", "score": "0.61" }, { "ref": "experts/marco-betschart", "score": "0.34" } ], "experts": [ { "ref": "experts/marco-betschart", "score": "0.34" }, { "ref": "experts/rico-lenherr", "score": "0.34" }, { "ref": "experts/marco-mattei", "score": "0.31" } ] }}

apiVersion = "soultec.ch/v1"kind = "Service"[metadata]name = "disaster-recovery"locale = "en"[metadata.labels]group = "infrastructure""capability/backup-recovery" = "2.18""capability/architecture" = "2.93""capability/migration" = "3.54""vendor/hpe" = "2.04""vendor/veeam" = "4.22"[metadata.annotations]source = "src/content/services/en/disaster-recovery.md"route = "/en/services/disaster-recovery/"schema = "/nerd/schema/services.json"markdown = "/en/services/disaster-recovery.md"[spec]title = "Disaster Recovery"group = "infrastructure"order = 7tags = ["backup-recovery", "architecture", "migration"]vendors = ["hpe", "veeam"]summary = "RPO and RTO first, technology after. And a plan that has never been tested is a hope."photoNeed = "A failover rehearsal in progress: two engineers at a screen with a runbook open beside them, mid-test rather than posed"stub = falsedraft = false[[sections]]heading = "

What it protects against

"body = '''Power failure, water, fire and earthquake, all rare and all possible. And ransomware, wherea properly thought-through disaster recovery plan is the difference between days and weeks.'''[[sections]]heading = "

Where we start

"body = '''With two numbers. **RPO**, how much data loss is acceptable, and **RTO**, how long it maytake to be running again. Both have to be verified and signed off with the stakeholders,because they carry the whole architecture and are not a technical quantity.After that we classify and prioritise data and systems. Not everything needs the samenumber, and trying to treat everything alike is the most common reason a plan becomesunaffordable.'''[[sections]]heading = "

How the design comes together

"body = '''It accounts for the workloads in your datacentres and in your public clouds, along withavailability and performance requirements. Site choice feeds in too: where your datacentresand cloud regions sit partly determines what is possible at all.'''[[sections]]heading = "

Implementation, and the part that gets skipped

"body = '''We build on Zerto and Veeam. Both allow the real event to be rehearsed: virtual servers canbe started in a sandbox at the recovery site and checked without touching production.That is exactly the part that gets skipped. Regular test scenarios with the systemadministrators and the affected departments are what separate a plan from a hope.'''[status]corpus = 267[[status.solutions]]ref = "solutions/hpe/hpe-server"score = "0.50"[[status.solutions]]ref = "solutions/veeam"score = "0.43"[[status.solutions]]ref = "solutions/hpe"score = "0.39"[[status.solutions]]ref = "solutions/omnissa/citrix-takeout"score = "0.23"[[status.alsoLike]]ref = "services/engineering"score = "0.66"[[status.alsoLike]]ref = "services/datacenter-lifecycle"score = "0.61"[[status.alsoLike]]ref = "experts/marco-betschart"score = "0.34"[[status.experts]]ref = "experts/marco-betschart"score = "0.34"[[status.experts]]ref = "experts/rico-lenherr"score = "0.34"[[status.experts]]ref = "experts/marco-mattei"score = "0.31"

<?xml version="1.0" encoding="UTF-8"?><manifest kind="Service"> <apiVersion>soultec.ch/v1</apiVersion> <metadata> <name>disaster-recovery</name> <locale>en</locale> <labels> <group>infrastructure</group> <entry key="capability/backup-recovery">2.18</entry> <entry key="capability/architecture">2.93</entry> <entry key="capability/migration">3.54</entry> <entry key="vendor/hpe">2.04</entry> <entry key="vendor/veeam">4.22</entry> </labels> <annotations> <source>src/content/services/en/disaster-recovery.md</source> <route>/en/services/disaster-recovery/</route> <schema>/nerd/schema/services.json</schema> <markdown>/en/services/disaster-recovery.md</markdown> </annotations> </metadata> <spec> <title>Disaster Recovery</title> <group>infrastructure</group> <order>7</order> <tags> <item>backup-recovery</item> <item>architecture</item> <item>migration</item> </tags> <vendors> <item>hpe</item> <item>veeam</item> </vendors> <summary>RPO and RTO first, technology after. And a plan that has never been tested is a hope.</summary> <photoNeed>A failover rehearsal in progress: two engineers at a screen with a runbook open beside them, mid-test rather than posed</photoNeed> <stub>false</stub> <draft>false</draft> </spec> <sections> <section> <heading>

What it protects against

</heading> <body>Power failure, water, fire and earthquake, all rare and all possible. And ransomware, wherea properly thought-through disaster recovery plan is the difference between days and weeks. </body> </section> <section> <heading>

Where we start

</heading> <body>With two numbers. **RPO**, how much data loss is acceptable, and **RTO**, how long it maytake to be running again. Both have to be verified and signed off with the stakeholders,because they carry the whole architecture and are not a technical quantity.After that we classify and prioritise data and systems. Not everything needs the samenumber, and trying to treat everything alike is the most common reason a plan becomesunaffordable. </body> </section> <section> <heading>

How the design comes together

</heading> <body>It accounts for the workloads in your datacentres and in your public clouds, along withavailability and performance requirements. Site choice feeds in too: where your datacentresand cloud regions sit partly determines what is possible at all. </body> </section> <section> <heading>

Implementation, and the part that gets skipped

</heading> <body>We build on Zerto and Veeam. Both allow the real event to be rehearsed: virtual servers canbe started in a sandbox at the recovery site and checked without touching production.That is exactly the part that gets skipped. Regular test scenarios with the systemadministrators and the affected departments are what separate a plan from a hope. </body> </section> </sections> <status> <corpus>267</corpus> <solutions> <item> <ref>solutions/hpe/hpe-server</ref> <score>0.50</score> </item> <item> <ref>solutions/veeam</ref> <score>0.43</score> </item> <item> <ref>solutions/hpe</ref> <score>0.39</score> </item> <item> <ref>solutions/omnissa/citrix-takeout</ref> <score>0.23</score> </item> </solutions> <alsoLike> <item> <ref>services/engineering</ref> <score>0.66</score> </item> <item> <ref>services/datacenter-lifecycle</ref> <score>0.61</score> </item> <item> <ref>experts/marco-betschart</ref> <score>0.34</score> </item> </alsoLike> <experts> <item> <ref>experts/marco-betschart</ref> <score>0.34</score> </item> <item> <ref>experts/rico-lenherr</ref> <score>0.34</score> </item> <item> <ref>experts/marco-mattei</ref> <score>0.31</score> </item> </experts> </status></manifest>

What it protects against

Where we start

How the design comes together

Implementation, and the part that gets skipped

What it protects against

Where we start

How the design comes together

Implementation, and the part that gets skipped

What it protects against

Where we start

How the design comes together

Implementation, and the part that gets skipped

What it protects against

Where we start

How the design comes together

Implementation, and the part that gets skipped

Disaster Recovery

What it protects against

Where we start

How the design comes together

Implementation, and the part that gets skipped

Experts for this

Marco Betschart

Rico Lenherr

Marco Mattei

You might also like

Engineering

Datacenter Lifecycle

Marco Betschart