Ошибка резервного копирования Windows Server - не удается защитить тома размером более 16,7 ТБ?


10

Я пытаюсь использовать Windows Server Backup для резервного копирования массива RAID на моем новом сервере. Но, когда я делаю, я сталкиваюсь с этой ошибкой:

введите описание изображения здесь

Сервер работает под управлением Windows Server 2012 R2, а размер рассматриваемого массива составляет 20 ТБ (при использовании 18 ТБ); в настоящее время используется менее 1 ТБ.

Я знаю, что в Windows Server 2008 вы не могли создавать резервные копии томов размером более 2 ТБ из-за ограничения в VHD, но теперь Microsoft перешла на VHDX, который позволяет резервировать тома объемом 64 ТБ. Я также знаю, что для того, чтобы воспользоваться этим, рассматриваемый диск должен быть GPT.

Я подтвердил, что мой диск на самом деле GPT.

введите описание изображения здесь

Когда я запускаю Windows Server Backup, я использую опцию «Резервное копирование один раз» и выполняю резервное копирование на сетевой диск. Я также использую то, что я считаю стандартными настройками. Но, когда я пытаюсь запустить резервное копирование, я получаю сообщение об ошибке выше.

Я не уверен, почему это ограничивается 16.7 ТБ, поскольку Windows Server Backup может резервировать тома до 64 ТБ. Кто-нибудь может дать мне некоторое представление о том, почему это может происходить или что я могу делать неправильно?

Обновление: я получил новые диски и снова создал массив, но все еще получаю ту же ошибку. Я могу подтвердить, что число моих кластеров меньше 2 ^ 32.

введите описание изображения здесь

В этом вопросе я читал, что, по-видимому, резервное копирование Windows не поддерживает резервное копирование на диски или с дисков, на которых нет ни 512, ни 512-байтовых секторов. Глядя на файловый ресурс, на который я пытаюсь сделать резервную копию, он использует 4 тыс. Секторов. Может ли это быть основной проблемой? Если это помогает, общий ресурс, на который я пытаюсь сделать резервную копию, размещается на сервере CentOS.


По сути, это защищенное сообщение, а не пробел. «Стандартными настройками» для резервного копирования на сервере Windows является использование DPM - Data Protection Manager. Похоже, существует ограничение программного обеспечения при использовании DPM. Возможно, вы захотите посмотреть, позволят ли настройки выполнять побайтовое копирование без включения так называемой «защиты», при условии, что у вас есть способ восстановить побайтовое копирование, если вам нужно.
Андрей С

1
@ AndrewS Нет, это сообщение из Windows Server Backup. «Защищенный», кажется, новое модное слово в резервных копиях в эти дни. Даже моя приборная панель Avamar (продукт для резервного копирования на уровне предприятия d2d) сообщает, что у нас есть «ТБ» данных, «защищенных» для нас.
HopelessN00b

2
Это неудачное неправильное использование слова «резервное копирование». Боги ITIL злятся, без сомнения. Но, как выясняется, ограничение размера файла для NTFS составляет 16.7 ТБ, поэтому проблема заключается в том, что резервная копия (я предполагаю) представляет собой один гигантский файл, а 16.7 ТБ - это ограничение для этого размера. Microsoft и другие поставщики могут исправить это и назвать это «защитой» или любым другим идиотским маркетинговым слагом, которого они хотят, я все равно буду называть это «резервной копией».
Андрей С

@AndrewS Он используется как мера исходного размера данных, до дедупликации данных и моментальных снимков и тому подобное. И ограничение размера файла для NTFS на Server 2012 составляет 256 ТБ, а не 16 ТБ .
HopelessN00b

FWIW: та же проблема здесь. Сервер 2016, 20 и 63 ТБ дисков, 16 КБ байтов на кластер на томе, менее 2 ^ 32 кластеров на том, физический диск 512 байт на сектора и GPT. VSS тени работают без проблем, резервные копии получают ту же ошибку, что и вы. Я собираюсь сдаться и написать чертов сценарий PowerShell, который делает снимок и запускает заранее определенный сценарий для каждой папки и для файлов в корневом каталоге, что будет гораздо более сложной задачей ...
Cookie Monster

Ответы:


8

Хорошо, причина сбоя резервного копирования Windows Server заключается в размере кластера, который вы используете на томе. (И я точно объясню, почему это в конце, после того, как важная проблема, связанная с тем, что ваш RAID-массив является бомбой замедленного действия.)

Но прежде чем приступить к решению проблемы с резервным копированием, нам нужно решить проблему с вашей настройкой RAID.

Не используйте RAID5 с большими дисками. И не используйте RAID5 с массивами с большим количеством членов. Имея только один диск четности, вы практически наверняка столкнетесь с (неустранимая ошибка чтения) URE или другим дисковым отказом с таким большим количеством дисков, поэтому у вас нет реальной избыточности. Если вам нужно использовать RAID с контролем четности, используйте RAID6, но даже в этом случае RAID с контролем четности имеет серьезные недостатки, поэтому подумайте долго и усердно, прежде чем переходить к RAID с контролем четности.

Я бы рекомендовал разбить этот массив размером 20 ТБ и воссоздать его в RAID 10. Вы получите гораздо лучшую производительность и реальную избыточность ваших данных. Так как в любом случае вы используете только 1 ТБ, у вас все еще есть 9 ТБ для будущего роста, и, честно говоря, если вам удастся это сделать, вам нужно искать выделенное устройство NAS или сервер хранения.

Как только вы переведете RAID-массив в разумное состояние, вы также решите эту проблему, потому что он будет меньше, чем 16 TiB, на которые он сейчас жалуется. Но, если вы хотите знать, проблема не в размере массива, а в количестве кластеров. Вы должны иметь менее 2 ^ 32 кластеров на томе, который вы резервируете. Измените размер кластера с 4 КБ до 8 КБ, и все должно быть в порядке.

Чтобы проверить размер кластера, используйте:

fsutil fsinfo ntfsinfo F:

И вы должны получить что-то вроде скриншота ниже.

введите описание изображения здесь

Если вам интересно, откуда взялся этот номер 16TiB, это сообщение в блоге msdn должно прояснить его для вас .


Спасибо за вашу заботу о RAID. Я пытался убедить своего босса разрешить мне использовать RAID6, но безуспешно. На самом деле это массив из 5 ТБ, а не 2 ТБ дисков (извините, я должен был это указать). Причина, по которой на нем используется так мало данных, заключается в том, что мы еще не запустили его в производство. Но в конечном итоге это будет наш новый NAS. И мы также очень часто выполняем резервное копирование, поэтому мы можем легко восстановить поврежденный массив. Итак, означает ли это, что если я воссоздаю массив с большим размером полосы, у меня не будет этой проблемы?
Крис Пауэлл

1
@ChrisPowell Извините, я ошибся (опечатка). Я хотел сказать, кластер, а не полоса. Вам необходимо переформатировать массив, за исключением этого времени, выберите 8 КБ (или больше, если хотите) для размера вашего кластера.
HopelessN00b

2
@ChrisPowell Спасибо, что приложили усилия, чтобы задать хороший вопрос ... и еще один, на который я мог бы ответить, бонус. :)
HopelessN00b

1
Просто обновление; вы будете рады узнать, что я снова поговорил со своим боссом и убедил его позволить мне переключить NAS на RAID6 и обновить накопители до 6 ТБ. Еще раз спасибо за вашу помощь.
Крис Пауэлл

Еще одно обновление: я только что подключил диски, настроил массив и отформатировал его с размером кластера 8 КБ, и я все еще получаю эту ошибку. Любой совет? Я проверил общее количество кластеров, и оно намного меньше 2 ^ 32.
Крис Пауэлл

0

16,7 ТБ - это предел размера файла для файловой системы NTFS. Ограничение размера файла NTFS5 составляет 16 эксабайт. Поскольку это диск с общим хранилищем, он вполне может быть отформатирован в NTFS, а не в NTFS5. Вам нужно будет проверить. Все минусы, которые я получаю, - это люди, которые предполагают, что вы пишете в файловую систему NTFS5.


Минус все, что вы хотите - этот ответ правильный
Andrew S

1
WSB не будет писать файл 16 ТиБ для ~ 1 ТиБ данных для резервного копирования, так что это не так. Фактическим источником проблемы является ограничение реализации NTFS в 2 ^ 32 -1 кластеров в сочетании с размером кластера 4 КБ , который долгое время использовался по умолчанию.
HopelessN00b
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.