DE · EN

Call us

build 6ddc7a35 | content blog-content@417154f · 338 posts | profiles 32 · corpus 315 | ● 0 skipped | built 2026-10-21 12:35 UTC format run

$ soultec get service/disaster-recovery -o yaml$ soultec get service/disaster-recovery -o json$ soultec get service/disaster-recovery -o toml$ soultec get service/disaster-recovery -o xml$ python3 disaster-recovery.pyPS> ./disaster-recovery.ps1$ go run disaster-recovery.go$ node disaster-recovery.js

apiVersion: soultec.ch/v1kind: Servicemetadata: name: disaster-recovery locale: en labels: group: infrastructure capability/backup-recovery: 2.14 capability/architecture: 2.51 capability/migration: 2.82 vendor/hpe: 1.99 vendor/veeam: 3.03 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 audience: [enterprise, provider] 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. And against hardware defects. - 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 testing

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. We schedule those tests regularly, with the system administrators and the affected departments. Without them it stays open whether recovery works inside the agreed time. The recovery itself runs automated: order, network switch-over and system start are stored in the tool and are not carried out by hand in an emergency. The goal is that the company can keep working after the event.status: corpus: 315 solutions: - {ref: solutions/hpe/hpe-zerto, score: 0.67} - {ref: solutions/hpe/hpe-server, score: 0.50} - {ref: solutions/hpe/hpe-server/hpe-synergy, score: 0.50} - {ref: solutions/hpe/hpe-storage/hpe-storeonce, score: 0.45} alsoLike: - {ref: experts/yannick-gerber, score: 0.64} - {ref: services/engineering, score: 0.62} - {ref: experts/aldo-gwerder, score: 0.59} experts: - {ref: experts/yannick-gerber, score: 0.64} - {ref: experts/aldo-gwerder, score: 0.59} - {ref: experts/steven-rodenburg, score: 0.56} search: /en/search.json

{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "disaster-recovery", "locale": "en", "labels": { "group": "infrastructure", "capability/backup-recovery": 2.14, "capability/architecture": 2.51, "capability/migration": 2.82, "vendor/hpe": 1.99, "vendor/veeam": 3.03 }, "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", "audience": [ "enterprise", "provider" ], "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.\n\nAnd against hardware defects." }, { "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 testing

", "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\nWe schedule those tests regularly, with the system administrators and the affected\ndepartments. Without them it stays open whether recovery works inside the agreed time.\n\nThe recovery itself runs automated: order, network switch-over and system start are stored\nin the tool and are not carried out by hand in an emergency. The goal is that the company\ncan keep working after the event." } ] }, "status": { "corpus": 315, "solutions": [ { "ref": "solutions/hpe/hpe-zerto", "score": "0.67" }, { "ref": "solutions/hpe/hpe-server", "score": "0.50" }, { "ref": "solutions/hpe/hpe-server/hpe-synergy", "score": "0.50" }, { "ref": "solutions/hpe/hpe-storage/hpe-storeonce", "score": "0.45" } ], "alsoLike": [ { "ref": "experts/yannick-gerber", "score": "0.64" }, { "ref": "services/engineering", "score": "0.62" }, { "ref": "experts/aldo-gwerder", "score": "0.59" } ], "experts": [ { "ref": "experts/yannick-gerber", "score": "0.64" }, { "ref": "experts/aldo-gwerder", "score": "0.59" }, { "ref": "experts/steven-rodenburg", "score": "0.56" } ], "search": "/en/search.json" }}

apiVersion = "soultec.ch/v1"kind = "Service"[metadata]name = "disaster-recovery"locale = "en"[metadata.labels]group = "infrastructure""capability/backup-recovery" = 2.14"capability/architecture" = 2.51"capability/migration" = 2.82"vendor/hpe" = 1.99"vendor/veeam" = 3.03[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"audience = ["enterprise", "provider"]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[[spec.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.And against hardware defects.'''[[spec.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.'''[[spec.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.'''[[spec.sections]]heading = "

Implementation and testing

"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.We schedule those tests regularly, with the system administrators and the affecteddepartments. Without them it stays open whether recovery works inside the agreed time.The recovery itself runs automated: order, network switch-over and system start are storedin the tool and are not carried out by hand in an emergency. The goal is that the companycan keep working after the event.'''[status]corpus = 315search = "/en/search.json"[[status.solutions]]ref = "solutions/hpe/hpe-zerto"score = "0.67"[[status.solutions]]ref = "solutions/hpe/hpe-server"score = "0.50"[[status.solutions]]ref = "solutions/hpe/hpe-server/hpe-synergy"score = "0.50"[[status.solutions]]ref = "solutions/hpe/hpe-storage/hpe-storeonce"score = "0.45"[[status.alsoLike]]ref = "experts/yannick-gerber"score = "0.64"[[status.alsoLike]]ref = "services/engineering"score = "0.62"[[status.alsoLike]]ref = "experts/aldo-gwerder"score = "0.59"[[status.experts]]ref = "experts/yannick-gerber"score = "0.64"[[status.experts]]ref = "experts/aldo-gwerder"score = "0.59"[[status.experts]]ref = "experts/steven-rodenburg"score = "0.56"

<?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.14</entry> <entry key="capability/architecture">2.51</entry> <entry key="capability/migration">2.82</entry> <entry key="vendor/hpe">1.99</entry> <entry key="vendor/veeam">3.03</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> <audience> <item>enterprise</item> <item>provider</item> </audience> <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> <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.And against hardware defects. </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 testing

</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.We schedule those tests regularly, with the system administrators and the affecteddepartments. Without them it stays open whether recovery works inside the agreed time.The recovery itself runs automated: order, network switch-over and system start are storedin the tool and are not carried out by hand in an emergency. The goal is that the companycan keep working after the event. </body> </section> </sections> </spec> <status> <corpus>315</corpus> <solutions> <item> <ref>solutions/hpe/hpe-zerto</ref> <score>0.67</score> </item> <item> <ref>solutions/hpe/hpe-server</ref> <score>0.50</score> </item> <item> <ref>solutions/hpe/hpe-server/hpe-synergy</ref> <score>0.50</score> </item> <item> <ref>solutions/hpe/hpe-storage/hpe-storeonce</ref> <score>0.45</score> </item> </solutions> <alsoLike> <item> <ref>experts/yannick-gerber</ref> <score>0.64</score> </item> <item> <ref>services/engineering</ref> <score>0.62</score> </item> <item> <ref>experts/aldo-gwerder</ref> <score>0.59</score> </item> </alsoLike> <experts> <item> <ref>experts/yannick-gerber</ref> <score>0.64</score> </item> <item> <ref>experts/aldo-gwerder</ref> <score>0.59</score> </item> <item> <ref>experts/steven-rodenburg</ref> <score>0.56</score> </item> </experts> <search>/en/search.json</search> </status></manifest>

# Code generated by the soultec.ch build. DO NOT EDIT.import jsonPAGE = { "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "disaster-recovery", "locale": "en", "labels": { "group": "infrastructure", "capability/backup-recovery": 2.14, "capability/architecture": 2.51, "capability/migration": 2.82, "vendor/hpe": 1.99, "vendor/veeam": 3.03, }, "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", "audience": ["enterprise", "provider"], "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\n" "a properly thought-through disaster recovery plan is the difference between days and weeks.\n" "\n" "And against hardware defects." ), }, { "heading": "

Where we start

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

How the design comes together

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

Implementation and testing

", "body": ( "We build on Zerto and Veeam. Both allow the real event to be rehearsed: virtual servers can\n" "be started in a sandbox at the recovery site and checked without touching production.\n" "\n" "We schedule those tests regularly, with the system administrators and the affected\n" "departments. Without them it stays open whether recovery works inside the agreed time.\n" "\n" "The recovery itself runs automated: order, network switch-over and system start are stored\n" "in the tool and are not carried out by hand in an emergency. The goal is that the company\n" "can keep working after the event." ), }, ], }, "status": { "corpus": 315, "solutions": [ { "ref": "solutions/hpe/hpe-zerto", "score": "0.67", }, { "ref": "solutions/hpe/hpe-server", "score": "0.50", }, { "ref": "solutions/hpe/hpe-server/hpe-synergy", "score": "0.50", }, { "ref": "solutions/hpe/hpe-storage/hpe-storeonce", "score": "0.45", }, ], "alsoLike": [ { "ref": "experts/yannick-gerber", "score": "0.64", }, { "ref": "services/engineering", "score": "0.62", }, { "ref": "experts/aldo-gwerder", "score": "0.59", }, ], "experts": [ { "ref": "experts/yannick-gerber", "score": "0.64", }, { "ref": "experts/aldo-gwerder", "score": "0.59", }, { "ref": "experts/steven-rodenburg", "score": "0.56", }, ], "search": "/en/search.json", },}if __name__ == "__main__": print(json.dumps(PAGE, indent=2, ensure_ascii=False))

# Code generated by the soultec.ch build. DO NOT EDIT.$Page = [ordered]@{ apiVersion = 'soultec.ch/v1' kind = 'Service' metadata = [ordered]@{ name = 'disaster-recovery' locale = 'en' labels = [ordered]@{ group = 'infrastructure' 'capability/backup-recovery' = 2.14 'capability/architecture' = 2.51 'capability/migration' = 2.82 'vendor/hpe' = 1.99 'vendor/veeam' = 3.03 } annotations = [ordered]@{ 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 = [ordered]@{ title = 'Disaster Recovery' group = 'infrastructure' audience = @('enterprise', 'provider') 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 = @( [ordered]@{ 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.And against hardware defects.'@ } [ordered]@{ 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.'@ } [ordered]@{ 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.'@ } [ordered]@{ heading = '

Implementation and testing

' 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.We schedule those tests regularly, with the system administrators and the affecteddepartments. Without them it stays open whether recovery works inside the agreed time.The recovery itself runs automated: order, network switch-over and system start are storedin the tool and are not carried out by hand in an emergency. The goal is that the companycan keep working after the event.'@ } ) } status = [ordered]@{ corpus = 315 solutions = @( [ordered]@{ ref = 'solutions/hpe/hpe-zerto' score = '0.67' } [ordered]@{ ref = 'solutions/hpe/hpe-server' score = '0.50' } [ordered]@{ ref = 'solutions/hpe/hpe-server/hpe-synergy' score = '0.50' } [ordered]@{ ref = 'solutions/hpe/hpe-storage/hpe-storeonce' score = '0.45' } ) alsoLike = @( [ordered]@{ ref = 'experts/yannick-gerber' score = '0.64' } [ordered]@{ ref = 'services/engineering' score = '0.62' } [ordered]@{ ref = 'experts/aldo-gwerder' score = '0.59' } ) experts = @( [ordered]@{ ref = 'experts/yannick-gerber' score = '0.64' } [ordered]@{ ref = 'experts/aldo-gwerder' score = '0.59' } [ordered]@{ ref = 'experts/steven-rodenburg' score = '0.56' } ) search = '/en/search.json' }}$Page | ConvertTo-Json -Depth 32

// Code generated by the soultec.ch build. DO NOT EDIT.package mainimport ( "encoding/json" "os")var page = map[string]any{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": map[string]any{ "name": "disaster-recovery", "locale": "en", "labels": map[string]any{ "group": "infrastructure", "capability/backup-recovery": 2.14, "capability/architecture": 2.51, "capability/migration": 2.82, "vendor/hpe": 1.99, "vendor/veeam": 3.03, }, "annotations": map[string]any{ "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": map[string]any{ "title": "Disaster Recovery", "group": "infrastructure", "audience": []any{"enterprise", "provider"}, "order": 7, "tags": []any{"backup-recovery", "architecture", "migration"}, "vendors": []any{"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": []any{ map[string]any{ "heading": "

What it protects against

", "body": "Power failure, water, fire and earthquake, all rare and all possible. And ransomware, where\n" + "a properly thought-through disaster recovery plan is the difference between days and weeks.\n" + "\n" + "And against hardware defects.", }, map[string]any{ "heading": "

Where we start

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

How the design comes together

", "body": "It accounts for the workloads in your datacentres and in your public clouds, along with\n" + "availability and performance requirements. Site choice feeds in too: where your datacentres\n" + "and cloud regions sit partly determines what is possible at all.", }, map[string]any{ "heading": "

Implementation and testing

", "body": "We build on Zerto and Veeam. Both allow the real event to be rehearsed: virtual servers can\n" + "be started in a sandbox at the recovery site and checked without touching production.\n" + "\n" + "We schedule those tests regularly, with the system administrators and the affected\n" + "departments. Without them it stays open whether recovery works inside the agreed time.\n" + "\n" + "The recovery itself runs automated: order, network switch-over and system start are stored\n" + "in the tool and are not carried out by hand in an emergency. The goal is that the company\n" + "can keep working after the event.", }, }, }, "status": map[string]any{ "corpus": 315, "solutions": []any{ map[string]any{ "ref": "solutions/hpe/hpe-zerto", "score": "0.67", }, map[string]any{ "ref": "solutions/hpe/hpe-server", "score": "0.50", }, map[string]any{ "ref": "solutions/hpe/hpe-server/hpe-synergy", "score": "0.50", }, map[string]any{ "ref": "solutions/hpe/hpe-storage/hpe-storeonce", "score": "0.45", }, }, "alsoLike": []any{ map[string]any{ "ref": "experts/yannick-gerber", "score": "0.64", }, map[string]any{ "ref": "services/engineering", "score": "0.62", }, map[string]any{ "ref": "experts/aldo-gwerder", "score": "0.59", }, }, "experts": []any{ map[string]any{ "ref": "experts/yannick-gerber", "score": "0.64", }, map[string]any{ "ref": "experts/aldo-gwerder", "score": "0.59", }, map[string]any{ "ref": "experts/steven-rodenburg", "score": "0.56", }, }, "search": "/en/search.json", },}func main() { enc := json.NewEncoder(os.Stdout) enc.SetEscapeHTML(false) enc.SetIndent("", " ") if err := enc.Encode(page); err != nil { os.Exit(1) }}

// Code generated by the soultec.ch build. DO NOT EDIT.const page = { apiVersion: "soultec.ch/v1", kind: "Service", metadata: { name: "disaster-recovery", locale: "en", labels: { group: "infrastructure", "capability/backup-recovery": 2.14, "capability/architecture": 2.51, "capability/migration": 2.82, "vendor/hpe": 1.99, "vendor/veeam": 3.03, }, 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", audience: ["enterprise", "provider"], 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\n" + "a properly thought-through disaster recovery plan is the difference between days and weeks.\n" + "\n" + "And against hardware defects.", }, { heading: "

Where we start

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

How the design comes together

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

Implementation and testing

", body: "We build on Zerto and Veeam. Both allow the real event to be rehearsed: virtual servers can\n" + "be started in a sandbox at the recovery site and checked without touching production.\n" + "\n" + "We schedule those tests regularly, with the system administrators and the affected\n" + "departments. Without them it stays open whether recovery works inside the agreed time.\n" + "\n" + "The recovery itself runs automated: order, network switch-over and system start are stored\n" + "in the tool and are not carried out by hand in an emergency. The goal is that the company\n" + "can keep working after the event.", }, ], }, status: { corpus: 315, solutions: [ { ref: "solutions/hpe/hpe-zerto", score: "0.67", }, { ref: "solutions/hpe/hpe-server", score: "0.50", }, { ref: "solutions/hpe/hpe-server/hpe-synergy", score: "0.50", }, { ref: "solutions/hpe/hpe-storage/hpe-storeonce", score: "0.45", }, ], alsoLike: [ { ref: "experts/yannick-gerber", score: "0.64", }, { ref: "services/engineering", score: "0.62", }, { ref: "experts/aldo-gwerder", score: "0.59", }, ], experts: [ { ref: "experts/yannick-gerber", score: "0.64", }, { ref: "experts/aldo-gwerder", score: "0.59", }, { ref: "experts/steven-rodenburg", score: "0.56", }, ], search: "/en/search.json", },};console.log(JSON.stringify(page, null, 2));

# 79 lines · YAML · validated at build# 112 lines · JSON · validated at build# 119 lines · TOML · validated at build# 139 lines · XML · validated at build# 135 lines · Python · read back at build, equals the JSON record# 132 lines · PowerShell · read back at build, equals the JSON record# 139 lines · Go · read back at build, equals the JSON record# 124 lines · JavaScript · read back at build, equals the JSON record · served at /en/services/disaster-recovery.md

Service · infrastructure

Disaster Recovery

RPO and RTO first, technology after. And a plan that has never been tested is a hope.

Topics Backup and Recovery 2.14 Architecture 2.51 Migration 2.82

Vendors HPE 1.99 Veeam 3.03

04Solutions

03Capabilities

02Vendors

315Corpus

photograph wantedA failover rehearsal in progress: two engineers at a screen with a runbook open beside them, mid-test rather than posed

What it protects against

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.

And against hardware defects.

Where we start

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.

How the design comes together

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.

Implementation and testing

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.

We schedule those tests regularly, with the system administrators and the affected departments. Without them it stays open whether recovery works inside the agreed time.

The recovery itself runs automated: order, network switch-over and system start are stored in the tool and are not carried out by hand in an emergency. The goal is that the company can keep working after the event.