Disaster Recovery

apiVersion: soultec.ch/v1kind: Servicemetadata: name: disaster-recovery locale: de 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/de/disaster-recovery.md route: /de/services/disaster-recovery/ schema: /nerd/schema/services.json markdown: /de/services/disaster-recovery.mdspec: title: Disaster Recovery group: infrastructure order: 7 tags: [backup-recovery, architecture, migration] vendors: [hpe, veeam] summary: >- RPO und RTO zuerst, Technik danach. Und ein Konzept, das nie getestet wurde, ist eine Hoffnung. 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:

Wogegen es schützt

body: | Gegen Stromausfall, Wasser, Feuer und Erdbeben, die alle selten sind und trotzdem vorkommen. Und gegen Ransomware, wo ein durchdachtes Disaster-Recovery-Konzept den Unterschied zwischen Tagen und Wochen macht. - heading:

Womit wir anfangen

body: | Mit zwei Zahlen. **RPO**, wie viel Datenverlust akzeptabel ist, und **RTO**, wie lange es dauern darf, bis es wieder läuft. Beide müssen mit den Stakeholdern verifiziert und freigegeben werden, denn sie tragen die ganze Architektur und sind keine technische Grösse. Danach klassifizieren und priorisieren wir Daten und Systeme. Nicht alles braucht dieselbe Zahl, und der Versuch, alles gleich zu behandeln, ist der häufigste Grund, warum ein Konzept zu teuer wird. - heading:

Wie das Design entsteht

body: | Berücksichtigt werden die Workloads in deinen Rechenzentren und in deinen Public Clouds, dazu die Verfügbarkeits- und Leistungsanforderungen. Auch die Wahl der Standorte fliesst ein: Wo deine Rechenzentren und Cloud-Regionen liegen, bestimmt mit, was überhaupt möglich ist. - heading:

Umsetzung, und der Teil, der übersprungen wird

body: | Wir setzen auf Zerto und Veeam. Beide erlauben es, den Ernstfall zu testen: Virtuelle Server lassen sich am Zielstandort in einer Sandbox starten und überprüfen, ohne die Produktion zu berühren. Genau das ist der Teil, der übersprungen wird. Regelmässige Testszenarien mit den Systemadministratoren und den betroffenen Fachbereichen sind das, was ein Konzept von einer Hoffnung unterscheidet.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": "de", "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/de/disaster-recovery.md", "route": "/de/services/disaster-recovery/", "schema": "/nerd/schema/services.json", "markdown": "/de/services/disaster-recovery.md" } }, "spec": { "title": "Disaster Recovery", "group": "infrastructure", "order": 7, "tags": [ "backup-recovery", "architecture", "migration" ], "vendors": [ "hpe", "veeam" ], "summary": "RPO und RTO zuerst, Technik danach. Und ein Konzept, das nie getestet wurde, ist eine Hoffnung.", "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": "

Wogegen es schützt

", "body": "Gegen Stromausfall, Wasser, Feuer und Erdbeben, die alle selten sind und trotzdem\nvorkommen. Und gegen Ransomware, wo ein durchdachtes Disaster-Recovery-Konzept den\nUnterschied zwischen Tagen und Wochen macht." }, { "heading": "

Womit wir anfangen

", "body": "Mit zwei Zahlen. **RPO**, wie viel Datenverlust akzeptabel ist, und **RTO**, wie lange es\ndauern darf, bis es wieder läuft. Beide müssen mit den Stakeholdern verifiziert und\nfreigegeben werden, denn sie tragen die ganze Architektur und sind keine technische\nGrösse.\n\nDanach klassifizieren und priorisieren wir Daten und Systeme. Nicht alles braucht dieselbe\nZahl, und der Versuch, alles gleich zu behandeln, ist der häufigste Grund, warum ein\nKonzept zu teuer wird." }, { "heading": "

Wie das Design entsteht

", "body": "Berücksichtigt werden die Workloads in deinen Rechenzentren und in deinen Public Clouds,\ndazu die Verfügbarkeits- und Leistungsanforderungen. Auch die Wahl der Standorte fliesst\nein: Wo deine Rechenzentren und Cloud-Regionen liegen, bestimmt mit, was überhaupt möglich\nist." }, { "heading": "

Umsetzung, und der Teil, der übersprungen wird

", "body": "Wir setzen auf Zerto und Veeam. Beide erlauben es, den Ernstfall zu testen: Virtuelle\nServer lassen sich am Zielstandort in einer Sandbox starten und überprüfen, ohne die\nProduktion zu berühren.\n\nGenau das ist der Teil, der übersprungen wird. Regelmässige Testszenarien mit den\nSystemadministratoren und den betroffenen Fachbereichen sind das, was ein Konzept von einer\nHoffnung unterscheidet." } ], "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 = "de"[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/de/disaster-recovery.md"route = "/de/services/disaster-recovery/"schema = "/nerd/schema/services.json"markdown = "/de/services/disaster-recovery.md"[spec]title = "Disaster Recovery"group = "infrastructure"order = 7tags = ["backup-recovery", "architecture", "migration"]vendors = ["hpe", "veeam"]summary = "RPO und RTO zuerst, Technik danach. Und ein Konzept, das nie getestet wurde, ist eine Hoffnung."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 = "

Wogegen es schützt

"body = '''Gegen Stromausfall, Wasser, Feuer und Erdbeben, die alle selten sind und trotzdemvorkommen. Und gegen Ransomware, wo ein durchdachtes Disaster-Recovery-Konzept denUnterschied zwischen Tagen und Wochen macht.'''[[sections]]heading = "

Womit wir anfangen

"body = '''Mit zwei Zahlen. **RPO**, wie viel Datenverlust akzeptabel ist, und **RTO**, wie lange esdauern darf, bis es wieder läuft. Beide müssen mit den Stakeholdern verifiziert undfreigegeben werden, denn sie tragen die ganze Architektur und sind keine technischeGrösse.Danach klassifizieren und priorisieren wir Daten und Systeme. Nicht alles braucht dieselbeZahl, und der Versuch, alles gleich zu behandeln, ist der häufigste Grund, warum einKonzept zu teuer wird.'''[[sections]]heading = "

Wie das Design entsteht

"body = '''Berücksichtigt werden die Workloads in deinen Rechenzentren und in deinen Public Clouds,dazu die Verfügbarkeits- und Leistungsanforderungen. Auch die Wahl der Standorte fliesstein: Wo deine Rechenzentren und Cloud-Regionen liegen, bestimmt mit, was überhaupt möglichist.'''[[sections]]heading = "

Umsetzung, und der Teil, der übersprungen wird

"body = '''Wir setzen auf Zerto und Veeam. Beide erlauben es, den Ernstfall zu testen: VirtuelleServer lassen sich am Zielstandort in einer Sandbox starten und überprüfen, ohne dieProduktion zu berühren.Genau das ist der Teil, der übersprungen wird. Regelmässige Testszenarien mit denSystemadministratoren und den betroffenen Fachbereichen sind das, was ein Konzept von einerHoffnung unterscheidet.'''[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>de</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/de/disaster-recovery.md</source> <route>/de/services/disaster-recovery/</route> <schema>/nerd/schema/services.json</schema> <markdown>/de/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 und RTO zuerst, Technik danach. Und ein Konzept, das nie getestet wurde, ist eine Hoffnung.</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>

Wogegen es schützt

</heading> <body>Gegen Stromausfall, Wasser, Feuer und Erdbeben, die alle selten sind und trotzdemvorkommen. Und gegen Ransomware, wo ein durchdachtes Disaster-Recovery-Konzept denUnterschied zwischen Tagen und Wochen macht. </body> </section> <section> <heading>

Womit wir anfangen

</heading> <body>Mit zwei Zahlen. **RPO**, wie viel Datenverlust akzeptabel ist, und **RTO**, wie lange esdauern darf, bis es wieder läuft. Beide müssen mit den Stakeholdern verifiziert undfreigegeben werden, denn sie tragen die ganze Architektur und sind keine technischeGrösse.Danach klassifizieren und priorisieren wir Daten und Systeme. Nicht alles braucht dieselbeZahl, und der Versuch, alles gleich zu behandeln, ist der häufigste Grund, warum einKonzept zu teuer wird. </body> </section> <section> <heading>

Wie das Design entsteht

</heading> <body>Berücksichtigt werden die Workloads in deinen Rechenzentren und in deinen Public Clouds,dazu die Verfügbarkeits- und Leistungsanforderungen. Auch die Wahl der Standorte fliesstein: Wo deine Rechenzentren und Cloud-Regionen liegen, bestimmt mit, was überhaupt möglichist. </body> </section> <section> <heading>

Umsetzung, und der Teil, der übersprungen wird

</heading> <body>Wir setzen auf Zerto und Veeam. Beide erlauben es, den Ernstfall zu testen: VirtuelleServer lassen sich am Zielstandort in einer Sandbox starten und überprüfen, ohne dieProduktion zu berühren.Genau das ist der Teil, der übersprungen wird. Regelmässige Testszenarien mit denSystemadministratoren und den betroffenen Fachbereichen sind das, was ein Konzept von einerHoffnung unterscheidet. </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>

Wogegen es schützt

Womit wir anfangen

Wie das Design entsteht

Umsetzung, und der Teil, der übersprungen wird

Wogegen es schützt

Womit wir anfangen

Wie das Design entsteht

Umsetzung, und der Teil, der übersprungen wird

Wogegen es schützt

Womit wir anfangen

Wie das Design entsteht

Umsetzung, und der Teil, der übersprungen wird

Wogegen es schützt

Womit wir anfangen

Wie das Design entsteht

Umsetzung, und der Teil, der übersprungen wird

Disaster Recovery

Wogegen es schützt

Womit wir anfangen

Wie das Design entsteht

Umsetzung, und der Teil, der übersprungen wird

Expertinnen und Experten dafür

Marco Betschart

Rico Lenherr

Marco Mattei

Passt ausserdem

Engineering

Datacenter Lifecycle

Marco Betschart