Windows Server-Sicherungsfehler - Volumes, die größer als 16,7 TB sind, können nicht geschützt werden?

Ich versuche, mit Windows Server Backup ein RAID-Array auf meinem neuen Server zu sichern. Aber wenn ich das tue, stoße ich auf diesen Fehler:

Geben Sie hier die Bildbeschreibung ein

Auf dem Server wird Windows Server 2012 R2 ausgeführt, und das betreffende Array hat eine Größe von 20 TB (wobei 18 TB verwendet werden können). Derzeit werden weniger als 1 TB verwendet.

Ich weiß, dass Sie in Windows Server 2008 aufgrund einer Einschränkung in VHD keine Volumes mit mehr als 2 TB sichern konnten, aber Microsoft hat jetzt auf VHDX umgestellt, wodurch 64 TB-Volumes gesichert werden können. Mir ist auch bewusst, dass das betreffende Laufwerk GPT sein muss, um dies nutzen zu können.

Ich habe bestätigt, dass es sich bei meiner Festplatte tatsächlich um GPT handelt.

Geben Sie hier die Bildbeschreibung ein

Wenn ich Windows Server Backup ausführe, verwende ich die Option "Einmal sichern" und sichere auf einem Netzwerklaufwerk. Ich verwende auch Standardeinstellungen. Wenn ich jedoch versuche, die Sicherung auszuführen, wird der oben gezeigte Fehler angezeigt.

Ich bin nicht sicher, warum dies auf 16,7 TB begrenzt ist, da Windows Server Backup Volumes mit bis zu 64 TB sichern kann. Kann mir jemand einen Einblick geben, warum dies passiert oder was ich falsch mache?

Update: Ich habe neue Laufwerke erhalten und das Array erneut erstellt, erhalte jedoch immer noch den gleichen Fehler. Ich kann bestätigen, dass meine Clusteranzahl unter 2 ^ 32 liegt.

Geben Sie hier die Bildbeschreibung ein

Ich habe in dieser Frage gelesen , dass Windows-Backups anscheinend das Sichern auf oder von Datenträgern nicht unterstützen, die weder 512- noch 512e-Byte-Sektoren haben. Wenn ich mir das Fileshare ansehe, auf das ich sichern möchte, werden 4k-Sektoren verwendet. Könnte dies das zugrunde liegende Problem sein? Wenn dies hilft, wird die Freigabe, auf die ich sichern möchte, auf einem CentOS-Server gehostet.

— Chris Powell
quelle

Es ist eine "geschützte" Nachricht, keine Raumnachricht an sich. Die 'Standardeinstellungen' für eine Windows Server-Sicherung sind DPM - Data Protection Manager. Es scheint, dass es bei Verwendung von DPM eine Softwareeinschränkung gibt. Vielleicht möchten Sie sehen, ob die Einstellungen eine Byte-für-Byte-Kopie ohne aktivierten sogenannten "Schutz" ermöglichen, vorausgesetzt, Sie haben die Möglichkeit, eine Byte-für-Byte-Kopie bei Bedarf wiederherzustellen.

— Andrew S

@ Andrews Nein, das ist eine Nachricht von Windows Server Backup. "Geschützt" scheint heutzutage das neue Schlagwort in Backups zu sein. Sogar mein Avamar-Dashboard (Enterprise d2d Backup-Produkt) sagt mir, dass X TB Daten für uns "geschützt" sind.

— HopelessN00b

Das ist ein unglücklicher Missbrauch des Wortes "Backup". Die ITIL-Götter werden zweifellos wütend. Wie sich jedoch herausstellt, beträgt das Limit für die Dateigröße bei NTFS 16,7 TB. Das ist also das Problem - das Backup (ich vermute) ist eine riesige Datei und 16,7 TB ist das Limit für diese Größe. Microsoft und die anderen Anbieter können es zerfleischen und es als "Schutz" oder jede andere idiotische Marketing-Schnecke bezeichnen, die sie wollen. Ich werde es immer noch als "Backup" bezeichnen.

— Andrew S

@AndrewS Es wird als Maß für die ursprüngliche Datengröße verwendet, bevor Daten dedupliziert und Snapshots erstellt werden. Die maximale Dateigröße für NTFS unter Server 2012 beträgt 256 TB, nicht 16 TiB .

— HopelessN00b

FWIW: das gleiche Problem hier. Server 2016, 20- und 63-TB-Laufwerke, 16 KByte pro Cluster auf dem Volume, unter 2 ^ 32 Clustern pro Volume, 512-Byte-Sektoren auf der physischen Festplatte und GPT. vss-Shadows funktionieren ohne Probleme. Backups erhalten den gleichen Fehler wie Sie. Ich bin dabei aufzugeben und ein verdammtes Powershell-Skript zu schreiben, das einen Schnappschuss macht und ein vorbestimmtes Skript pro Ordner ausführt, und für Dateien im Stammverzeichnis, deren Verwaltung viel schwieriger sein wird ...

— Cookie Monster

Antworten:

OK, der Grund, warum die Windows Server-Sicherung fehlschlägt, liegt in der Clustergröße, die Sie auf dem Volume verwenden. (Und ich werde genau erklären, warum das am Ende ist, nachdem das wichtige Problem, dass Ihr RAID-Array eine Zeitbombe ist, ist.)

Bevor wir uns jedoch mit dem Sicherungsproblem befassen, müssen wir das Problem mit Ihrem RAID-Setup beheben.

Verwenden Sie RAID5 nicht mit großen Festplatten. Verwenden Sie RAID5 nicht mit Arrays mit vielen Mitgliedern. Mit nur einer Paritätsfestplatte ist es praktisch sicher, dass bei so vielen großen Festplatten ein (nicht behebbarer Lesefehler) URE oder ein anderer Festplattenfehler auftritt, sodass Sie keine echte Redundanz haben. Wenn Sie Paritäts-RAID verwenden müssen, verwenden Sie RAID6, aber selbst dann weist Paritäts-RAID schwerwiegende Nachteile auf. Denken Sie also lange und gründlich nach, bevor Sie sich für Paritäts-RAID entscheiden.

Ich würde empfehlen, dieses 20-TB-Array aufzuschlüsseln und in RAID 10 neu zu erstellen. Sie erhalten eine viel bessere Leistung und echte Redundanz für Ihre Daten. Da Sie ohnehin nur 1 TB verwenden, stehen Ihnen noch 9 TB für zukünftiges Wachstum zur Verfügung. Wenn Sie dies erreichen, müssen Sie sich ein dediziertes NAS-Gerät oder einen dedizierten Speicherserver ansehen.

Sobald Sie Ihr RAID-Array in einen vernünftigen Zustand versetzt haben, lösen Sie auch dieses Problem, da es kleiner ist als die 16 TiB, über die es sich derzeit beschwert. Wenn Sie jedoch wissen möchten, ist es nicht die Größe des Arrays, mit dem es ein Problem hat, sondern die Anzahl der Cluster. Das zu sichernde Volume muss weniger als 2 ^ 32 Cluster enthalten. Ändern Sie Ihre Clustergröße von 4 KB auf 8 KB, und Sie sollten bereit sein.

Verwenden Sie zum Überprüfen Ihrer Clustergröße:

fsutil fsinfo ntfsinfo F:

Und Sie sollten so etwas wie den folgenden Screenclip bekommen.

Geben Sie hier die Bildbeschreibung ein

Wenn Sie neugierig sind, woher diese 16-TB-Nummer stammt, sollte dieser MSDN-Blog-Beitrag dies für Sie klären .

— HopelessN00b
quelle

Vielen Dank für Ihre Besorgnis über RAID. Ich habe versucht, meinen Chef davon zu überzeugen, dass ich RAID6 verwenden darf, war aber erfolglos. Es befindet sich tatsächlich in einem Array von 5-TB-Festplatten, nicht in 2-TB-Festplatten (Entschuldigung, das hätte ich angeben sollen). Der Grund dafür, dass so wenig Daten verwendet werden, ist, dass wir sie noch nicht in Produktion genommen haben. Aber es wird irgendwann unser neues NAS sein. Außerdem führen wir sehr oft Sicherungen durch, damit wir uns leicht von einem verschlechterten Array erholen können. Bedeutet das also, dass ich dieses Problem nicht hätte, wenn ich das Array mit einer größeren Streifengröße neu erstellt hätte?

— Chris Powell

@ ChrisPowell Sorry, ich habe falsch geschrieben (falsch geschrieben). Ich wollte Cluster sagen, nicht Streifen. Sie müssen das Array neu formatieren. Wählen Sie diesmal jedoch 8 KB (oder mehr, falls gewünscht) für Ihre Clustergröße aus.

— HopelessN00b

@ChrisPowell Vielen Dank, dass Sie sich die Mühe gemacht haben, eine gute Frage zu stellen ... und eine, die ich auch beantworten könnte, Bonus. :)

— HopelessN00b

Nur ein Update; Sie werden froh sein zu wissen, dass ich wieder mit meinem Chef gesprochen habe und ihn überzeugt habe, dass ich den NAS auf RAID6 umstellen und die Laufwerke auf 6 TB aktualisieren darf. Nochmals vielen Dank für Ihre Hilfe.

— Chris Powell

Ein weiteres Update: Ich habe gerade die Laufwerke eingelegt, das Array eingerichtet und mit einer Clustergröße von 8 KB formatiert, und es wird immer noch dieser Fehler angezeigt. Irgendein Rat? Ich habe meine gesamten Cluster überprüft und es ist deutlich unter 2 ^ 32.

— Chris Powell

16,7 TB ist die Dateigrößenbeschränkung für das NTFS-Dateisystem. Die Dateigrößenbeschränkung von NTFS5 beträgt 16 Exabyte. Da es sich um ein gemeinsam genutztes Speicherlaufwerk handelt, ist es möglicherweise NTFS-formatiert und nicht NTFS5-formatiert. Sie müssen überprüfen. Alle Minuspunkte, die ich bekomme, sind Leute, die davon ausgehen, dass Sie in ein NTFS5-Dateisystem schreiben.

— Andrew S.
quelle

Abzüglich alles, was Sie wollen - diese Antwort ist richtig

— Andrew S

WSB schreibt keine 16-TiB-Datei für ~ 1 TiB Daten, die gesichert werden sollen. Das ist es also nicht. Die eigentliche Ursache des Problems ist das NTFS-Implementierungslimit von 2 ^ 32 -1 Clustern in Kombination mit einer Clustergröße von 4 KB , die seit langer Zeit die Standardeinstellung ist.

— HopelessN00b