Błąd kopii zapasowej systemu Windows Server - woluminów większych niż 16,7 TB nie można chronić?

Próbuję użyć narzędzia Kopia zapasowa systemu Windows Server do wykonania kopii zapasowej macierzy RAID na nowym serwerze. Ale kiedy to robię, napotykam ten błąd:

wprowadź opis zdjęcia tutaj

Na serwerze działa system Windows Server 2012 R2, a tablica ma rozmiar 20 TB (z możliwością użycia 18 TB); obecnie używa się mniej niż 1 TB.

Wiem, że w systemie Windows Server 2008 nie można wykonać kopii zapasowej woluminów większych niż 2 TB z powodu ograniczeń w VHD, ale że Microsoft przeszedł teraz na VHDX, co pozwala na tworzenie kopii zapasowych woluminów 64 TB. Wiem też, że aby skorzystać z tego, dysk musi być GPT.

Potwierdziłem, że mój dysk to tak naprawdę GPT.

wprowadź opis zdjęcia tutaj

Po uruchomieniu Kopii zapasowej systemu Windows Server korzystam z opcji „Utwórz kopię zapasową raz” i wykonuję kopię zapasową na dysku sieciowym. Korzystam również z ustawień, które uważam za standardowe. Ale kiedy próbuję uruchomić kopię zapasową, pojawia się błąd widoczny powyżej.

Nie jestem pewien, dlaczego limit ten wynosi 16,7 TB, ponieważ Kopia zapasowa systemu Windows Server umożliwia tworzenie kopii zapasowych woluminów do 64 TB. Czy ktoś może dać mi wgląd w to, dlaczego tak się dzieje lub co robię źle?

Aktualizacja: otrzymałem nowe dyski i ponownie utworzyłem tablicę, ale wciąż pojawia się ten sam błąd. Mogę potwierdzić, że liczba moich klastrów jest mniejsza niż 2 ^ 32.

wprowadź opis zdjęcia tutaj

Przeczytałem w tym pytaniu, że najwyraźniej kopia zapasowa systemu Windows nie obsługuje tworzenia kopii zapasowych na dyskach lub z dysków, które nie mają sektorów bajtów 512 lub 512e. Patrząc na współdzielony plik, do którego próbuję wykonać kopię zapasową, wykorzystuje sektory 4k. Czy może to być problem podstawowy? Jeśli to pomoże, udział, który próbuję wykonać, jest przechowywany na serwerze CentOS.

— Chris Powell
źródło

Jest to sama wiadomość „chroniona”, a nie kosmiczna. „Standardowe ustawienia” dla kopii zapasowej serwera Windows to użycie DPM - Data Protection Manager. Wygląda na to, że istnieje ograniczenie oprogramowania podczas korzystania z DPM. Możesz sprawdzić, czy ustawienia pozwolą na wykonanie kopii bajt po bajcie, bez włączonej tak zwanej „ochrony”, zakładając, że istnieje możliwość przywrócenia kopii bajt po bajcie, jeśli zajdzie taka potrzeba.

— Andrew S

@AndrewS Nie, to wiadomość z kopii zapasowej systemu Windows Server. Wydaje się, że „chronione” to obecnie nowe hasło w kopiach zapasowych. Nawet mój pulpit Avamar (produkt do tworzenia kopii zapasowych d2d dla przedsiębiorstw) mówi mi, że ma dla nas X TB danych „chronionych”.

— HopelessN00b

To niefortunne niewłaściwe użycie słowa „kopia zapasowa”. Bez wątpienia bogowie ITIL się denerwują. Ale, jak się okazuje, limit rozmiaru pliku w systemie plików NTFS wynosi 16,7 TB, więc na tym polega problem - kopia zapasowa (tak myślę) to jeden gigantyczny plik, a 16,7 TB to limit dla tego rozmiaru. Microsoft i inni dostawcy mogą to zmienić i nazwać „ochroną” lub jakimkolwiek innym idiotycznym działaniem marketingowym, jakiego chcą, nadal będę to nazywać „kopią zapasową”.

— Andrew S,

@AndrewS Jest używany jako miara oryginalnego rozmiaru danych, przed deduplikacją danych i migawkami itp. A limit rozmiaru pliku dla NTFS na serwerze 2012 wynosi 256 TB, a nie 16 TiB .

— HopelessN00b

FWIW: ten sam problem tutaj. Serwer 2016, dyski 20 i 63 TB, 16 KB na klaster w woluminie, poniżej 2 ^ 32 klastrów na wolumin, dyski fizyczne 512 sektorów bajtów i GPT. cienie vss działają bez problemu, kopie zapasowe mają ten sam błąd co ty. Zaraz się poddam i napiszę cholerny skrypt PowerShell, który wykonuje migawkę i uruchamia z góry określony skrypt dla folderu, a dla plików w katalogu głównym, co będzie znacznie trudniejsze w zarządzaniu ...

— Cookie Monster

Odpowiedzi:

OK, przyczyną niepowodzenia tworzenia kopii zapasowej systemu Windows Server jest rozmiar klastra używany na woluminie. (I wyjaśnię dokładnie, dlaczego tak się dzieje na końcu, po tym, jak ważną kwestią dotyczącą macierzy RAID jest bomba zegarowa).

Ale przed rozwiązaniem problemu z kopią zapasową musimy rozwiązać ten problem przy konfiguracji RAID.

Nie używaj RAID5 z dużymi dyskami. I nie używaj RAID5 z tablicami z dużą liczbą członków. Z tylko jednym dyskiem parzystości masz praktycznie pewność, że dojdzie do (niemożliwego do odzyskania błędu odczytu) URE lub innej awarii dysku z tyloma dużymi dyskami, więc nie masz prawdziwej redundancji. Jeśli musisz użyć macierzy RAID parzystości, użyj RAID6, ale nawet wtedy macierz RAID parzystości ma poważne wady, więc zastanów się długo, zanim zdecydujesz się na macierz RAID parzystości.

Polecam rozbicie tej macierzy 20 TB i odtworzenie jej w RAID 10. Otrzymasz znacznie lepszą wydajność i prawdziwą redundancję dla swoich danych. Ponieważ i tak używasz tylko 1 TB, nadal masz 9 TB na przyszły rozwój, i szczerze mówiąc, jeśli trafisz na to, musisz szukać dedykowanego urządzenia NAS lub serwera pamięci.

Gdy doprowadzisz macierz RAID do rozsądnego stanu, rozwiążesz również ten problem, ponieważ będzie on mniejszy niż 16 TiB, na który obecnie narzeka. Ale jeśli chcesz wiedzieć, to nie wielkość tablicy, z którą ma problem, to liczba klastrów. Musisz mieć mniej niż 2 ^ 32 klastrów w woluminie, którego kopię zapasową tworzysz. Zmień rozmiar klastra z 4 KB na 8 KB i powinieneś zacząć.

Aby sprawdzić rozmiar klastra, użyj:

fsutil fsinfo ntfsinfo F:

I powinieneś dostać coś takiego jak poniższy zrzut ekranu.

wprowadź opis zdjęcia tutaj

Jeśli jesteś ciekawy, skąd pochodzi ten numer 16TiB, ten post na blogu msdn powinien to wyjaśnić .

— Beznadziejny
źródło

Dziękujemy za troskę o RAID. Próbowałem przekonać mojego szefa, aby pozwolił mi użyć na nim RAID6, ale nie powiodło się. W rzeczywistości znajduje się w tablicy dysków 5 TB, a nie 2 TB (przepraszam za to, powinienem był podać). Powodem, dla którego wykorzystuje się tak mało danych, jest to, że nie wprowadziliśmy ich jeszcze do produkcji. Ale ostatecznie będzie to nasz nowy NAS. Tworzymy również kopie zapasowe bardzo często, abyśmy mogli łatwo odzyskać z uszkodzonej tablicy. Czy to oznacza, że gdybym odtworzył tablicę z większym paskiem, nie miałbym tego problemu?

— Chris Powell,

@ChrisPowell Przepraszam, źle napisałem (źle napisałem). Miałem na myśli klaster, a nie pasek. Musisz sformatować tablicę, z wyjątkiem tego czasu, wybierz 8 KB (lub więcej, jeśli chcesz) dla rozmiaru klastra.

— HopelessN00b

@ChrisPowell Dziękujemy za włożenie wysiłku w zadanie dobrego pytania ... i na które również mogę odpowiedzieć, bonus. :)

— HopelessN00b

Tylko aktualizacja; z przyjemnością dowiesz się, że ponownie rozmawiałem z moim szefem i przekonałem go, aby pozwolił mi zmienić NAS na RAID6 i uaktualnić dyski do 6 TB. Jeszcze raz dziękuję za pomoc.

— Chris Powell,

Kolejna aktualizacja: właśnie włączyłem dyski, skonfigurowałem macierz i sformatowałem ją z klastrem o wielkości 8 KB i nadal pojawia się ten błąd. Jakakolwiek rada? Sprawdziłem wszystkie moje klastry i jest znacznie poniżej 2 ^ 32.

— Chris Powell

16,7 TB to limit rozmiaru pliku dla systemu plików NTFS. Limit rozmiaru pliku NTFS5 wynosi 16 eksabajtów. Ponieważ jest to współużytkowany dysk pamięci, może on być sformatowany w systemie NTFS, a nie w formacie NTFS5. Musisz to sprawdzić. Wszystkie minusy, które otrzymuję, to ludzie, którzy zakładają, że piszesz do systemu plików NTFS5.

— Andrew S.
źródło

Pomniejsz wszystko, czego chcesz - ta odpowiedź jest poprawna

— Andrew S

WSB nie napisze pliku 16 TiB dla ~ 1 TiB danych do utworzenia kopii zapasowej, więc to nie tak. Rzeczywistym źródłem problemu jest limit implementacyjny NTFS dla klastrów 2 ^ 32 -1, w połączeniu z rozmiarem klastra 4KB , który był domyślny od bardzo dawna.

— HopelessN00b