Azure Backup und Site Recovery: Disaster-Recovery-Konzepte umsetzen

Backup ist nicht Disaster Recovery – und das musst du deinem Chef erklaeren koennen

Im Alltag werden die Begriffe staendig vermischt: “Wir haben ja ein Backup, das reicht doch.” Nein, reicht es nicht. Ein Backup schuetzt dich vor Datenverlust – geloeschte Dateien, verschluesselte Ransomware-Server, ein fehlerhaftes Update. Disaster Recovery (DR) schuetzt dich vor dem Ausfall einer ganzen Umgebung: ein Rechenzentrum brennt, eine Azure-Region hat einen Totalausfall, ein Standort ist wegen Stromausfall oder Hochwasser tagelang nicht erreichbar. Backup beantwortet die Frage “Wie bekomme ich verlorene Daten zurueck?”, DR beantwortet die Frage “Wie bringe ich den Betrieb an einem anderen Ort wieder zum Laufen?”.

Fuer ein Schweizer KMU heisst das konkret: Azure Backup sichert deine VMs, Fileserver und Datenbanken gegen Datenverlust und Ransomware. Azure Site Recovery (ASR) repliziert ganze VMs kontinuierlich in eine andere Region oder von on-premises nach Azure, damit du im Ernstfall innerhalb von Minuten statt Tagen wieder produktiv bist. Beide Dienste laufen ueber den Recovery Services Vault, sind aber architektonisch und im Betrieb komplett unterschiedliche Werkzeuge – und genau diese Unterscheidung ist in vielen KMU-DR-Konzepten nicht sauber durchdacht.

Dieser Artikel baut auf IT-Notfallplanung und Disaster Recovery und Backup-Strategie: die 3-2-1-Regel auf und geht in die Azure-spezifische Tiefe: Wie du einen Recovery Services Vault production-ready aufsetzt, Backup-Policies fuer VMs und Fileserver differenzierst, ASR-Replikation korrekt konfigurierst, RPO/RTO nicht nur definierst sondern auch beweist, Failover-Drills durchfuehrst, ohne die Produktion zu gefaehrden, und am Ende die Speicherkosten im Griff behaeltst.

Recovery Services Vault: die Verwaltungseinheit richtig planen

Der Recovery Services Vault ist der zentrale Container fuer Backup-Metadaten, Wiederherstellungspunkte und (optional) ASR-Replikationskonfigurationen. Bevor du ihn anlegst, triff drei Entscheidungen, die spaeter nur mit Aufwand korrigierbar sind: Region, Redundanz und Abgrenzung (wie viele Vaults, welche Scope-Grenzen).

Region und Redundanz

Ein Vault ist an eine Region gebunden. Fuer Azure-VM-Backups muss der Vault in derselben Region liegen wie die VM (Ausnahme: Cross Region Restore bei GRS-Vaults). Bei der Redundanz waehlst du zwischen:

Fuer produktive Server-Backups in einem Schweizer KMU ist GRS in der Regel die richtige Wahl: Switzerland North ist mit Switzerland West gepaart, deine Backup-Daten liegen also weiterhin in der Schweiz (relevant fuer nDSG/DSGVO-Anforderungen), aber physisch getrennt von der Primaerregion.

Vault erstellen (PowerShell / Az CLI)

# Resource Group und Recovery Services Vault erstellen
New-AzResourceGroup -Name "RG-Backup-Prod" -Location "switzerlandnorth"

$vault = New-AzRecoveryServicesVault `
  -ResourceGroupName "RG-Backup-Prod" `
  -Name "RSV-CH-Prod-01" `
  -Location "switzerlandnorth"

# Redundanz auf GRS setzen (nur moeglich vor dem ersten Backup!)
Set-AzRecoveryServicesBackupProperty `
  -Vault $vault `
  -BackupStorageRedundancy GeoRedundant

# Aequivalent in Azure CLI
az group create --name RG-Backup-Prod --location switzerlandnorth

az backup vault create \
  --resource-group RG-Backup-Prod \
  --name RSV-CH-Prod-01 \
  --location switzerlandnorth

az backup vault backup-properties set \
  --resource-group RG-Backup-Prod \
  --name RSV-CH-Prod-01 \
  --backup-storage-redundancy GeoRedundant

Wie viele Vaults braucht ein KMU?

Ein einzelner Vault kann problemlos hunderte VMs und Fileshares verwalten – technisch spricht nichts gegen “ein Vault fuer alles”. In der Praxis lohnt sich trotzdem eine Trennung nach zwei Kriterien:

• Umgebung: Ein Vault fuer Produktion, ein separater fuer Test/Dev. Verhindert, dass jemand aus Versehen Produktions-Policies auf Testmaschinen anwendet oder umgekehrt Kosten spart, wo es riskant ist.
• RBAC-Grenze: Wenn unterschiedliche Teams (z.B. externe IT-Dienstleister fuer Filialen vs. interne IT fuer den Hauptsitz) nur Zugriff auf ihre eigenen Backups haben sollen, spricht das fuer getrennte Vaults, da Rollen im Vault granular, aber nicht pro-VM zuweisbar sind.

Backup-Policies fuer VMs: Standard- vs. Enhanced Policy

Azure unterscheidet bei VM-Backups zwei Policy-Typen. Die Standard Policy arbeitet mit taeglichen oder woechentlichen Backups auf Basis von VM-Snapshots. Die Enhanced Policy (seit 2023 der empfohlene Standard fuer neue Konfigurationen) unterstuetzt zusaetzlich stuendliche Backups (bis zu alle 4 Stunden) und laengere Standard-Aufbewahrung.

# Enhanced Backup Policy fuer VMs mit 3x taeglichem Snapshot und 30 Tagen Retention
$schPol = Get-AzRecoveryServicesBackupSchedulePolicyObject `
  -PolicySubType "Enhanced" -WorkloadType "AzureVM" -BackupManagementType "AzureVM"
$schPol.ScheduleRunFrequency = "Hourly"
$schPol.HourlySchedule.Interval = 8
$schPol.HourlySchedule.WindowStartTime = (Get-Date -Hour 6 -Minute 0)
$schPol.HourlySchedule.WindowDuration = 12

$retPol = Get-AzRecoveryServicesBackupRetentionPolicyObject `
  -WorkloadType "AzureVM" -BackupManagementType "AzureVM" -PolicySubType "Enhanced"
$retPol.DailySchedule.DurationCountInDays = 30
$retPol.WeeklySchedule.DurationCountInWeeks = 12
$retPol.MonthlySchedule.DurationCountInMonths = 12

New-AzRecoveryServicesBackupProtectionPolicy `
  -Name "Pol-VM-Prod-Hourly" `
  -WorkloadType "AzureVM" `
  -PolicySubType "Enhanced" `
  -SchedulePolicy $schPol `
  -RetentionPolicy $retPol `
  -VaultId $vault.ID

GFS-Retention: Grandfather-Father-Son richtig aufsetzen

Fuer Compliance-Anforderungen (z.B. Buchhaltungsdaten, revisionssichere Aufbewahrung) reicht eine reine Tagesretention nicht. Das GFS-Schema kombiniert taegliche, woechentliche, monatliche und jaehrliche Restore-Punkte mit unterschiedlicher Aufbewahrungsdauer:

# Yearly Retention fuer 7 Jahre (typische Aufbewahrungspflicht CH: 10 Jahre Geschaeftsbuecher)
$retPol.IsYearlyScheduleEnabled = $true
$retPol.YearlySchedule.DurationCountInYears = 10
$retPol.YearlySchedule.MonthsOfYear = "January"
$retPol.YearlySchedule.DaysOfTheMonth = @(1)

Backup fuer Fileserver: Azure Backup Agent vs. Azure File Sync

Fileserver-Backups laufen technisch anders als VM-Backups. Du hast drei Optionen, die oft verwechselt werden:

1. VM-Backup (Snapshot-basiert): Sichert die ganze VM inklusive Fileserver-Rolle als Image. Einfach, aber granulare Einzeldatei-Wiederherstellung ist langsamer (File Recovery Tool muss VHD mounten).
2. MARS-Agent (Microsoft Azure Recovery Services Agent): Sichert gezielt Ordner/Volumes auf dem Windows Server, unabhaengig vom VM-Snapshot. Bis zu 3 taegliche Backups, granulare Datei-/Ordner-Restores ohne VHD-Mount.
3. Azure Backup fuer Azure File Shares: Wenn die Fileshares direkt in Azure Files liegen (nicht auf einem Windows-Fileserver), sicherst du sie nativ ueber den Vault ohne Agent.

# MARS-Agent-Installation vorbereiten: Vault-Credentials herunterladen
Get-AzRecoveryServicesVaultSettingsFile `
  -Vault $vault `
  -Path "C:\Temp\" `
  -Backup

# Nach Agent-Installation: Registrierung pruefen
Get-OBMachine

Fuer verteilte Standorte (mehrere Filialen mit eigenen Fileservern) lohnt sich zusaetzlich ein Blick auf Azure File Sync, das lokale Fileserver mit Azure Files synchronisiert und Cloud Tiering ermoeglicht – das ist aber ein eigenes Thema, keine Backup-Loesung per se, sondern reduziert eher die lokale Storage-Last.

Azure Site Recovery: Replikations-Architektur verstehen

ASR repliziert auf Block-Ebene kontinuierlich (nicht Snapshot-basiert wie Backup). Es gibt zwei Hauptszenarien, die fuer ein KMU relevant sind:

• Azure-to-Azure: VMs, die bereits in Azure laufen, werden in eine zweite Region repliziert (z.B. Switzerland North -> Switzerland West oder West Europe).
• VMware/Hyper-V-to-Azure: On-premises-VMs werden nach Azure repliziert, fuer den Fall, dass das eigene Rechenzentrum/Serverraum ausfaellt.

Replikation aktivieren (Azure-to-Azure)

# Recovery Services Vault fuer ASR verwenden (kann derselbe Vault wie Backup sein,
# in der Praxis empfiehlt sich aber Trennung fuer Uebersicht)
$asrVault = Get-AzRecoveryServicesVault -Name "RSV-CH-DR-01"
Set-AzRecoveryServicesAsrVaultContext -Vault $asrVault

# Replikationsrichtlinie: 24h Recovery Point Retention, App-konsistente Punkte alle 4h
$policy = New-AzRecoveryServicesAsrPolicy `
  -AzureToAzure `
  -Name "Pol-A2A-24h" `
  -RecoveryPointRetentionInHours 24 `
  -ApplicationConsistentSnapshotFrequencyInHours 4

# Replizierten Schutzcontainer verknuepfen (Quell- und Zielregion)
New-AzRecoveryServicesAsrProtectionContainerMapping `
  -Name "Mapping-CHN-to-CHW" `
  -Policy $policy `
  -PrimaryProtectionContainer $sourceContainer `
  -RecoveryProtectionContainer $targetContainer

Nach der Ersteinrichtung laeuft die Replikation kontinuierlich im Hintergrund: Aenderungen auf der Quell-VM werden asynchron auf einen Replika-Datentraeger in der Zielregion geschrieben. Der Replikationsstatus (gesund, verzoegert, kritisch) ist im Portal unter “Replicated items” pro VM einsehbar – das solltest du in dein Monitoring einbinden, denn eine VM, deren Replikation seit drei Tagen “kritisch” ist, gibt dir im Ernstfall keinen Schutz mehr.

Recovery Plans fuer mehrstufige Failover

Bei mehreren voneinander abhaengigen VMs (z.B. Domain Controller vor Applikationsserver vor Webserver) orchestrierst du den Failover ueber einen Recovery Plan statt einzelne VMs manuell failen zu lassen:

New-AzRecoveryServicesAsrRecoveryPlan `
  -Name "RP-ERP-Umgebung" `
  -PrimaryFabric $primaryFabric `
  -RecoveryFabric $recoveryFabric `
  -GroupStart "Group1" -Group1 $dcVMs `
  -GroupStart "Group2" -Group2 $appVMs `
  -GroupStart "Group3" -Group3 $webVMs

Recovery Plans erlauben zusaetzlich, Skripte oder Azure Automation Runbooks zwischen den Gruppen einzuhaengen (z.B. DNS-Umschaltung nach Gruppe 1, bevor Gruppe 2 startet) – das ist der Unterschied zwischen “Server sind wieder online” und “Applikation funktioniert tatsaechlich End-to-End”.

RPO und RTO: definieren, nicht nur behaupten

RPO (Recovery Point Objective) beschreibt den maximal tolerierbaren Datenverlust in Zeit, RTO (Recovery Time Objective) die maximal tolerierbare Ausfallzeit bis zur Wiederherstellung. Beide Werte werden viel zu oft “aus dem Bauch heraus” festgelegt (“wir sagen mal 4 Stunden”) statt aus dem tatsaechlichen Business-Bedarf abgeleitet.

Entscheidungsbaum: RPO/RTO pro Workload ableiten

Workload identifizieren
  │
  ├─ Ist ein Ausfall > 1h geschaeftskritisch (Umsatzausfall, Vertragsstrafen)?
  │    ├─ JA  → RTO < 1h    → ASR mit Azure-to-Azure, getestete Recovery Plans
  │    └─ NEIN → weiter pruefen
  │
  ├─ Ist ein Ausfall > 4h tolerierbar, aber > 1 Tag nicht?
  │    ├─ JA  → RTO 4-8h   → ASR mit einfachem Recovery Plan ODER
  │    │                     VM-Backup mit schneller Restore-Region
  │    └─ NEIN → weiter pruefen
  │
  └─ Ist ein Ausfall von 1-2 Tagen akzeptabel (interne Tools, Testsysteme)?
       └─ JA  → RTO 1-2 Tage → Reines Azure Backup, Restore bei Bedarf

Fuer die RPO-Seite gilt: Azure Site Recovery erreicht typischerweise ein RPO von wenigen Minuten (kontinuierliche Replikation), Azure Backup je nach Policy zwischen 4 Stunden (Enhanced Policy, stuendliche Snapshots) und 24 Stunden (Standard Policy, taeglich). Die SLA von Microsoft fuer ASR nennt ein RTO-Ziel von einer Stunde fuer den eigentlichen Failover-Vorgang – das ist die Zeit, die Azure braucht, um die VMs zu starten, nicht die Zeit bis die Applikation fuer Nutzer wieder erreichbar ist (DNS-Umschaltung, Lizenzserver, Anwendungsstart kommen oben drauf).

Failover-Test-Drills: so gehst du vor, ohne die Produktion zu gefaehrden

Azure Site Recovery unterstuetzt Test Failover als nicht-disruptive Operation: Die Replikation der Produktions-VM laeuft ungestoert weiter, waehrend eine isolierte Kopie in einem separaten, isolierten Netzwerk gestartet wird.

Schritt-fuer-Schritt-Ablauf eines Test-Failover-Drills

1. Isoliertes Test-VNet vorbereiten: Lege ein separates VNet in der Zielregion an, das keine Route zur Produktion hat (sonst riskierst du IP-Konflikte oder ungewollten Traffic zwischen Test- und Live-System).
2. Recovery Point waehlen: Im Portal unter “Replicated items” -> VM -> Test Failover. Waehle “Latest processed” fuer die realistischste RTO-Messung oder einen spezifischen Zeitstempel, wenn du ein bestimmtes Recovery-Szenario nachstellen willst.
3. Test Failover ausloesen und Zeit stoppen: Ab Klick auf “Test Failover” bis die VM in Azure bootet und die Applikation erreichbar ist – das ist deine gemessene RTO.
4. Applikation funktional pruefen: Nicht nur “Server läuft”, sondern Login, Datenbankzugriff, externe Schnittstellen (falls im Testnetz simulierbar).
5. Notizen zu Abweichungen: Fehlende Konfigurationen, falsche IP-Annahmen, vergessene Abhaengigkeiten (z.B. ein Lizenzserver, der nicht mitrepliziert wird).
6. Cleanup ausfuehren: “Cleanup test failover” im Portal – wichtig, sonst laeuft die Test-VM weiter und verursacht Kosten, ohne dass die Replikation dadurch beeintraechtigt wird.

# Test-Failover via PowerShell ausloesen
$rp = Get-AzRecoveryServicesAsrReplicationProtectedItem `
  -ProtectionContainer $container -FriendlyName "SRV-ERP-01"

Start-AzRecoveryServicesAsrTestFailoverJob `
  -ReplicationProtectedItem $rp `
  -Direction PrimaryToRecovery `
  -AzureVMNetworkId $testVNetId

# Nach Pruefung: Cleanup
Start-AzRecoveryServicesAsrTestFailoverCleanupJob -ReplicationProtectedItem $rp

Fuer reine Azure-Backup-Restores (ohne ASR) simulierst du DR-Faelle durch File-Level Recovery oder eine vollstaendige VM-Wiederherstellung in eine isolierte Resource Group – auch das gehoert regelmaessig auf den Testplan, nicht nur ASR-Failover.

Kostenoptimierung: wo das Geld tatsaechlich hingeht

Azure Backup und ASR verursachen zwei Kostenarten: die Schutzgebuehr (pro geschuetzter Instanz, gestaffelt nach Groesse) und die Speicherkosten (pro GB Restore-Punkte/Recovery-Points). Bei wachsender Retention und vielen VMs wird Letzteres schnell zum groessten Posten.

Konkrete Hebel

# Backup-Item auf Archive-Tier verschieben (fuer Recovery Points > 180 Tage)
Set-AzRecoveryServicesBackupProtectionPolicy `
  -Policy $retPol `
  -MoveToArchiveTier $true `
  -TieringMode "TierAllEligible" `
  -DurationInDaysForArchivingPolicy 180

Ein oft uebersehener Kostenfaktor: verwaiste Backup-Elemente. Wenn eine VM geloescht wird, aber die zugehoerigen Recovery Points im Vault “stopped protection with retain data” bleiben, laufen die Speicherkosten unbegrenzt weiter. Ein regelmaessiges Audit (quartalsweise) mit Get-AzRecoveryServicesBackupItem gegen die aktuelle VM-Liste zeigt solche Leichen zuverlaessig auf.

# Alle Backup-Items im Vault auflisten und mit aktiven VMs abgleichen
$backupItems = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureVM -WorkloadType AzureVM -VaultId $vault.ID
$activeVMs = Get-AzVM | Select-Object -ExpandProperty Name

$backupItems | Where-Object { $_.SourceResourceId -notmatch ($activeVMs -join "|") } |
  Select-Object FriendlyName, ProtectionStatus, LastBackupStatus

Praxis-Checkliste fuer das DR-Konzept

• Recovery Services Vault mit passender Redundanz vor dem ersten Backup festgelegt (nicht nachtraeglich aenderbar).
• Backup-Policies pro Kritikalitaet differenziert (nicht “eine Policy fuer alles”).
• GFS-Retention fuer Compliance-relevante Daten (Buchhaltung, 10 Jahre nach OR) explizit konfiguriert.
• ASR fuer geschaeftskritische VMs mit definiertem, dokumentiertem Recovery Plan.
• RPO/RTO pro Workload aus dem Business-Bedarf abgeleitet, nicht geschaetzt.
• Mindestens halbjaehrlicher Test-Failover mit Zeitmessung und Soll/Ist-Vergleich.
• Soft Delete und idealerweise Multi-User Authorization fuer den Vault aktiv (Ransomware-Schutz).
• Quartalsweises Audit auf verwaiste Backup-Items und Archive-Tier-Kandidaten.

Weiterlernen

• Recovery Services Vault – Uebersicht (Microsoft Learn)
• Azure VM Backup mit Enhanced Policy (Microsoft Learn)
• Test Failover (DR-Drill) in Azure Site Recovery (Microsoft Learn)
• Tutorial: DR-Drill mit Azure Site Recovery durchfuehren (Microsoft Learn)
• Azure Backup Preisuebersicht (Microsoft Azure)
• Leitfaden und bewaehrte Methoden fuer Azure Backup (Microsoft Learn)