Schon seit der Veröffentlichung von Microsoft Windows NT 4.0 im Jahre 1996 ist das Distrubuted File System (DFS) fester Bestandteil jedes Windows Servers. Ursprünglich diente dieses Dateisystem der Bündelung von verteilt liegenden Netzwerkfreigaben unter einem einheitlichen Namensraum.

Diese Anforderung entstand hauptsächlich durch die damals noch sehr begrenzten Speicherkapazitäten der Server. So konnten Freigaben von verschiedenen und verschiedenartigen Quellen (Dateiserver, Netware Server oder auch Freigaben von Client- PCs) unter einem gemeinsamen Freigabenamen zusammengefasst werden. Die Nutzer mussten also nicht jede Datenquelle einzeln aufsuchen oder per Netzlaufwerk verbunden bekommen, sondern fanden unter dem gemeinsamen Freigabenamen des DFS alle benötigten Ressourcen. Diese Baumstruktur ist für den Nutzer nicht von einer herkömmlichen Ordnerhierarchie zu unterscheiden. Dies machte die Arbeit und auch die Administration dieser Netze sehr viel einfacher. Das Prinzip war aus der Unix- Welt (dort NFS= Network File System) von jeher bekannt und wurde den eigenen Erfordernissen entsprechend adaptiert. Durch die rasant steigende Speicherkapazitäten der Festplatten wurden dann aber zunehmend zentrale Dateiserver eingesetzt und das DFS fristete immer ein Schattendasein.

Schon bei Einführung von DFS konnten einzelne Datenquellen von entfernten Standorten in den gemeinsamen Namensraum (namespace) eingebunden werden. So konnten in auf mehrere Standorte verteilt tätigen Unternehmen die Kundedaten von einem Server in Berlin und die Buchhaltungsdaten von einem Server in Hamburg stammen und trotzdem in einer gemeinsamen Freigabestruktur erreichbar sein. Dies hat große Vorteile, jedoch erfolgt der Zugriff auf die Daten mit den standortspezifischen Zugriffszeiten und- kosten. Ein Nutzer in Berlin wartet auf die Buchhaltungsdaten aufgrund der vergleichsweise langsameren Internetverbindung immer länger auf Dateien als sein Hamburger Kollege und umgekehrt verhält es sich bei den Kundendaten. Diese Einschränkung könnte aufgelöst werden, indem alle im DFS Namensraum bereitgestellten Daten fortlaufend auf alle Standorte repliziert werden würden.

Es enstand die Erweiterung von DFS um die Replikation zu DFS-R (oder DFSR). Diese Technologie ist Bestandteil des Microsoft Server Betriebssystems seit Windows Server 2012. Eine Datensynchronisierung über eine vergleichsweise langsame Internetverbindung ist jedoch immer eine besondere Herausforderung für den Administrator, denn die kostbare Bandbreite dieser Verbindung will optimal ausgenutzt sein, ohne andere Dienste negativ zu beeinflussen.

• Überprüfung der vorhandenen VPN Datenverbindung auf ihre Zuverlässigkeit und verfügbare Bandbreite über einen längeren Zeitraum hinweg
• Kontrolle der letzten Datensicherung auf Vollständigkeit
• bei größeren Datenmengen: Erstellen der Offline Kopie der Daten von der Quelle auf einen externen Datenträger, damit die Erstsynchronisierung in endlicher Zeit durchlaufen kann
• ggfs. Anpassung der Einstellungen für die Volumenschattenkopien (anders als oft behauptet verträgt sich DFS-R sehr gut mit Volumenschattenkopien)
• Installation der DFS Rolle auf allen beteiligten Servern
• Einrichtung des DFS- Namespace
• Anlegen der DFS- Freigaben
• Einrichtung der DFSR Replikation für alle nötigen Freigabeordner (lokale Pfade sollten für bessere Übersicht möglichst gleich sein)
• Platzierung der Offline Kopie der Daten auf alle Zielserver
• Initialisierung der Erstsynchronisation mit 1 Server als Primärquelle
• Sukzessive Anpassung der DFSR stage- quota auf sinnvolles Maß je Serverfreigabe (Microsoft sagt sinnvoll ist die Datenmenge des größten Unterordners)
• Mehrmalige Fortschrittskontrolle bis zum erfolgreichen Abschluss der Erstsynchronisation
• ggfs. Auswertung der Parameter für die Datenübertragung am Monitoring- Server
• Test der spontanen Datenreplizierung nach Erstsynchronisierung
• Beobachtung der Staging- Folder auf ihren Datenzuwachs und eventuelle Synchronisierungsfehler

Die Größe der Staging Folder

Die richtige Bemessung der Midestgröße der Staging- Folder ist eines der Erfolgsrezepte für eine schnelle Erstsynchronisierrung. Microsoft empfielt dazu:

For the initial replication of existing data on the primary member, the staging folder quota must be large enough so that replication can continue even if multiple large files remain in the staging folder because partners cannot promptly download the files.

To properly size the staging folder for initial replication, you must take into account the size of the files to be replicated. At a minimum, the staging folder quota should be at least the size of the 32 largest files in the replicated folder, or the 16 largest files for read-only replicated folders. To improve performance, set the size of the staging folder quota as close as possible to the size of the replicated folder.

To determine the size of the largest files in a replicated folder using Windows Explorer, sort by size and add the 32 largest file sizes (16 if it’s a read-only replicated folder) to get the minimum staging folder size. To get the recommended minimum staging folder size (in gigabytes) from a Windows PowerShell® command prompt, use this Windows PowerShell command where <replicatedfolderpath> is the path to the replicated folder (change 32 to 16 for read-only replicated folders):

(Get-ChildItem <replicatedfolderpath> -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb