Помилка резервного копіювання Windows Server - обсяги, більші за 16,7 ТБ, не можна захистити?

Я намагаюся використовувати резервну копію Windows Server для резервного копіювання масиву RAID на новому сервері. Але коли я це роблю, я стикаюся з цією помилкою:

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

Сервер працює під управлінням Windows Server 2012 R2, а масив, про який йде мова, має розмір 20 ТБ (з 18 ТБ); наразі використовується менше 1 ТБ.

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

Я підтвердив, що мій диск насправді є GPT.

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

Коли я запускаю резервну копію Windows Server, я використовую опцію "Резервне копіювання один раз" і створюю резервну копію на мережевому диску. Я також використовую стандартні настройки. Але, коли я намагаюся запустити резервну копію, мені з’являється помилка, помічена вище.

Я не впевнений, чому це обмежує 16,7 ТБ, оскільки резервне копіювання Windows Server може створювати резервні копії обсягів до 64 ТБ. Хтось може дати мені зрозуміти, чому це може статися або що я можу робити неправильно?

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

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

У цьому запитанні я читав, що, мабуть, резервна копія Windows не підтримує резервне копіювання на або з дисків, у яких немає ні 512, ні 512e байтових секторів. Дивлячись на файл спільного використання файлів, на який я намагаюся створити резервну копію, він використовує 4k сектори. Чи може це бути основним питанням? Якщо це допомагає, частка, на яку я намагаюся створити резервну копію, розміщується на сервері CentOS.

— Кріс Пауелл
джерело

Це "захищене" повідомлення, а не пробіл. "Стандартні настройки" для резервного копіювання сервера Windows - це використання DPM - Менеджера захисту даних. Здається, існує обмеження програмного забезпечення під час використання DPM. Ви можете дізнатися, чи налаштування дозволять виконувати копію байта за байтом, без включеного так званого "захисту", якщо у вас є спосіб відновити копію байта за байтом.

— Андрій S

@AndrewS Ні, це повідомлення із резервної копії Windows Server. Цими днями "захищений" є новим модним словом для резервного копіювання. Навіть мій інформаційний панель Avamar (корпоративного продукту резервного копіювання d2d) повідомляє мені, що він має X TB даних, "захищених" для нас.

— HopelessN00b

Це невдале вживання слова "резервна копія". Боги ІТІЛа сердяться, без сумніву. Але, як виявляється, обмеження розміру ФАЙЛУ на NTFS становить 16,7 ТБ, тож у чому полягає проблема - резервне копіювання (я здогадуюсь) - один гігантський файл, а 16,7 ТБ - межа для цього розміру. Майкрософт та інші постачальники можуть обманювати це і називати його «захистом» або будь-яким іншим ідіотичним маркетинговим кухонь, який вони хочуть, я все одно називатиму його «резервним копією».

— Андрій S

@AndrewS Він використовується як міра початкового розміру даних, перш ніж дедуплікація та знімок даних тощо. А обмеження розміру файлу для NTFS на сервері 2012 - 256TiB, а не 16 TiB .

— HopelessN00b

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

— Cookie Monster,

Відповіді:

Гаразд, причина відмови резервного копіювання Windows Server - через розмір кластера, який ви використовуєте на гучності. (І я точно поясню, чому це в кінці, після того, як важлива проблема вашого RAID-масиву є бомбою часу.)

Але перш ніж вирішити проблему резервного копіювання, нам потрібно вирішити цю проблему за допомогою установки RAID.

Не використовуйте RAID5 з великими дисками. І не використовуйте RAID5 з масивами з великою кількістю членів. Маючи лише один диск для парності, ви практично впевнені, що зіткнетесь з (URE-помилкою читання) URE або іншим збоєм диска з багатьма великими дисками, тому у вас немає реального надмірності. Якщо вам доведеться використовувати паритет RAID, використовуйте RAID6, але навіть тоді, паритет RAID має серйозні недоліки, тому довго і наполегливо подумайте, перш ніж зупинитися на паритеті RAID.

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

Як тільки ви перейдете у свій розумний стан RAID-масив, ви також вирішите цю проблему, оскільки він буде меншим, ніж 16 TiB, на які зараз скаржаться. Але, якщо ви хочете знати, це не проблема розміру масиву, з яким виникає проблема, це кількість кластерів. Потрібно мати менше 2 ^ 32 кластерів в обсязі, який ви створюєте резервну копію. Змініть розмір кластера від 4 Кб до 8 Кб, і вам слід буде добре йти.

Щоб перевірити розмір кластера, використовуйте:

fsutil fsinfo ntfsinfo F:

І ви повинні отримати щось на зразок скріпки нижче.

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

Якщо вам цікаво, звідки походить цей номер 16TiB, це повідомлення в блозі MSDN має очистити його для вас .

— БезнадійноN00b
джерело

Дякуємо за турботу щодо RAID. Я намагався переконати свого боса, щоб він дозволив мені використовувати RAID6 на ньому, але не вдався. Це насправді в масиві 5TB дисків, а не 2TB диски (вибачте, я повинен був вказати). Причина того, що на ній використовується так мало даних, це тому, що ми ще не ввели їх у виробництво. Але, зрештою, це буде наш новий NAS. А також ми виконуємо резервні копії дуже часто, щоб легко відновитись із деградованого масиву. Отже, чи означає це, що якби я відтворив масив з більшим розміром смуги, у мене цього питання не виникне?

— Кріс Пауелл

@ChrisPowell Вибачте, помиляюсь (помилково введено). Я мав на увазі сказати кластер, а не смуга. Вам потрібно переформатувати масив, за винятком цього разу, виберіть 8 КБ (або більше, якщо хочете) для розміру кластеру.

— HopelessN00b

@ChrisPowell Дякую за те, що доклали зусиль, щоб задати гарне запитання ... і я можу відповісти також, бонус. :)

— HopelessN00b

Просто оновлення; ви будете раді дізнатись, що я знову поговорив зі своїм начальником, і я переконав його, щоб він дозволив мені переключити NAS на RAID6 і модернізувати накопичувачі до 6 ТБ. Ще раз дякую за допомогу.

— Кріс Пауелл

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

— Кріс Пауелл

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

— Андрій С
джерело

Мінус всього, що вам потрібно - ця відповідь правильна

— Andrew S

WSB не запише файл у форматі 16 TiB для ~ 1 TiB даних для резервного копіювання, тому це не так. Фактичним джерелом проблеми є обмеження впровадження NTFS кластерів 2 ^ 32 -1 в поєднанні з розміром кластера 4KB , який був за замовчуванням дуже довгий час.

— HopelessN00b