# Storage Replica: Block-Level DR für Windows Server

TL;DR / Management Summary Während DFS-R (Artikel 501) auf Datei-Ebene arbeitet, operiert Storage Replica (SR) auf Block-Ebene. Es spiegelt ganze Volumes (Partitionen) zwischen Servern oder Clustern. Da es unterhalb des Dateisystems ansetzt, können auch geöffnete Dateien und Datenbanken (SQL) ohne VSS-Overhead repliziert werden. Für Senior Admins ist es das ultimative Tool für den Aufbau von Stretch-Clustern oder standortübergreifendem Disaster Recovery.

# 1. Einführung & Architektur

Synchron vs. Asynchron.

Storage Replica nutzt das SMB 3.1.1 Protokoll für den Transport.

# Die zwei Modi

1. Synchrone Replikation (RPO = 0): Daten werden erst auf dem lokalen System bestätigt, wenn sie auch auf dem Ziel-Server auf die Disk geschrieben wurden.
   • Nachteil: Hoher Impact auf Latenz. Erfordert < 5ms RTT (meist innerhalb eines RZ).
2. Asynchrone Replikation: Daten werden lokal sofort bestätigt und im Hintergrund übertragen.
   • Vorteil: Für WAN-Strecken über weite Distanzen geeignet.

# Architektur-Übersicht (Mermaid)

graph LR
    subgraph "Site A (Source)"
    APP[Application] -->|Write| VOL_A[Data Volume]
    LOG_A[Log Volume]
    end

    subgraph "Site B (Destination)"
    VOL_B[Data Volume - RO]
    LOG_B[Log Volume]
    end

    VOL_A <-->|SMB 3.1.1| VOL_B
    LOG_A <-->|Sync| LOG_B

# 2. Einrichtung in der Praxis

Das Fundament für DR.

# Voraussetzungen

• Lizenz: Windows Server Datacenter Edition. (Standard ist auf 1 Partnerschaft bis 2 TB limitiert).
• Volumes: Sie benötigen ein Daten-Volume und ein separates, schnelles Log-Volume (SSD/NVMe empfohlen) auf beiden Seiten.

# Setup via PowerShell

# 1. Feature installieren
Install-WindowsFeature -Name Storage-Replica -IncludeManagementTools

# 2. Topologie testen (Kritisch für Support)
Test-SRTopology -SourceComputerName "SRV-A" -SourceVolumeName "D:" -SourceLogVolumeName "L:" `
    -DestinationComputerName "SRV-B" -DestinationVolumeName "D:" -DestinationLogVolumeName "L:" `
    -DurationInMinutes 5 -ResultPath "C:\Temp"

# 3. Partnerschaft erstellen
New-SRPartnership -SourceComputerName "SRV-A" -SourceRGName "Group01" `
    -SourceVolumeName "D:" -SourceLogVolumeName "L:" `
    -DestinationComputerName "SRV-B" -DestinationRGName "Group02" `
    -DestinationVolumeName "D:" -DestinationLogVolumeName "L:"

# 3. Deep Dive: Das Log-Volume

Der Motor der Replikation.

Storage Replica schreibt alle Änderungen zuerst sequentiell in das Log-Volume.

• Warum?: Das ermöglicht die schnelle Serialisierung über das Netzwerk.
• Größe: Das Log sollte groß genug sein, um die Schreiblast einer Stunde (bei asynchron) oder die Zeit eines kurzen Netzwerkausfalls abzufangen.

# 4. Day-2 Operations: Failover-Test

Umschalten im Ernstfall.

Im Normalbetrieb ist das Ziel-Volume (Destination) für den User unsichtbar und nicht gemountet.

# Geplanter Failover (Switch)

Set-SRPartnership -NewSourceComputerName "SRV-B" -SourceRGName "Group02" -DestinationComputerName "SRV-A" -DestinationRGName "Group01"

Nach dem Befehl wird das Volume auf SRV-B beschreibbar und auf SRV-A schreibgeschützt.

# 5. Troubleshooting & “War Stories”

Wenn die Sektoren hängen.

# Top 3 Fehlerbilder

1. Symptom: Massive Schreib-Latenz auf dem Source-Server.

   • Ursache: Synchrone Replikation über eine zu langsame Leitung.
   • Lösung: Auf asynchron umstellen oder Bandbreite erhöhen.

2. Symptom: SR-Status bleibt ewig auf “Initial Block Copy”.

   • Ursache: Bandbreite reicht nicht aus, um den “Current Change Rate” plus die Altdaten zu übertragen.
   • Lösung: Seed-Disk nutzen (Daten physisch zum Ziel bringen) oder Set-SRNetworkConstraint zur Bandbreitenbegrenzung nutzen.

3. Symptom: Fehler “Log volume is too small”.

   • Lösung: Log-Volume vergrößern (erfordert meist Löschen und Neuanlegen der Partnerschaft).

# “War Story”: Der “Zero-Loss” SQL Cluster

Wir bauten einen SQL-Cluster zwischen zwei Brandabschnitten. Dank Storage Replica im synchronen Modus konnten wir auf teure Fibre-Channel-Switches verzichten und nutzten die vorhandene 25 GbE Kupfer-Infrastruktur. Das Ergebnis: Bei einem Test-Power-Off des ersten Raums schwenkten die Rollen in 30 Sekunden um – ohne ein einziges Byte Datenverlust in der Datenbank. Lehre: Storage Replica ist der “SAN-Killer” für mittelständische HA-Szenarien.

# 6. Monitoring & Alerting

Die Replikations-Queue.

# Wichtige PerfMon Counter

• Storage Replica \ Log Copy Latency: Latenz der Replikation.
• Storage Replica \ Recovery Point Objective: Aktueller Datenverzug (bei asynchron).

# 7. Fazit & Empfehlung

Storage Replica ist die “große Schwester” von DFS-R.

• Empfehlung: Nutzen Sie SR für Datenbanken, Hyper-V VHDXs und Dateiserver mit Millionen kleiner Dateien, wo DFS-R an seine Grenzen stößt.
• Hardware: Sparen Sie niemals am Log-Volume. Nehmen Sie hierfür die schnellste NVMe, die Ihr Budget hergibt.

# Anhang: Cheatsheet

# Referenzen

• Microsoft Learn: Storage Replica Overview
• Server-to-server storage replication
• FAQ: Storage Replica