Erreur de sauvegarde Windows Server - Des volumes supérieurs à 16,7 To ne peuvent pas être protégés?

J'essaie d'utiliser la sauvegarde de Windows Server pour sauvegarder une matrice RAID sur mon nouveau serveur. Mais, quand je le fais, je rencontre cette erreur:

entrez la description de l'image ici

Le serveur exécute Windows Server 2012 R2 et la baie en question a une taille de 20 To (avec 18 To utilisables); moins de 1 To est actuellement utilisé.

Je sais que dans Windows Server 2008, vous ne pouviez pas sauvegarder des volumes supérieurs à 2 To en raison d'une limitation de VHD, mais que Microsoft est maintenant passé à VHDX, ce qui permet de sauvegarder des volumes de 64 To. Je suis également conscient que pour en profiter, le lecteur en question doit être GPT.

J'ai confirmé que mon disque est en fait GPT.

entrez la description de l'image ici

Lorsque j'exécute la sauvegarde de Windows Server, j'utilise l'option "Sauvegarder une fois" et je sauvegarde sur un lecteur réseau. J'utilise également ce que je pense être des paramètres standard. Mais, lorsque j'essaie d'exécuter la sauvegarde, on me présente l'erreur vue ci-dessus.

Je ne sais pas pourquoi cela plafonne à 16,7 To, car la sauvegarde de Windows Server peut sauvegarder des volumes allant jusqu'à 64 To. Quelqu'un peut-il me donner une idée de la raison pour laquelle cela peut se produire ou de ce que je peux faire de mal?

Mise à jour: j'ai reçu de nouveaux disques et créé à nouveau la baie mais j'obtiens toujours la même erreur. Je peux confirmer que mon nombre de grappes est inférieur à 2 ^ 32.

entrez la description de l'image ici

J'ai lu dans cette question que, apparemment, la sauvegarde Windows ne prend pas en charge la sauvegarde sur ou à partir de disques qui n'ont pas de secteurs de 512 ou 512e octets. En regardant le partage de fichiers sur lequel je tente de sauvegarder, il utilise des secteurs 4k. Serait-ce le problème sous-jacent? Si cela aide, le partage sur lequel j'essaie de sauvegarder est hébergé sur un serveur CentOS.

— Chris Powell
source

Il s'agit d'un message «protégé» et non d'un message spatial en soi. Les «paramètres standard» sont pour une sauvegarde de serveur Windows est d'utiliser DPM - Data Protection Manager. Il semble qu'il existe une limitation logicielle lors de l'utilisation de DPM. Vous voudrez peut-être voir si les paramètres autoriseront une copie octet par octet, sans la soi-disant `` protection '' activée, en supposant que vous avez un moyen de restaurer une copie octet par octet si vous en avez besoin.

— Andrew S

@AndrewS Non, c'est un message de la sauvegarde de Windows Server. «Protégé» semble être le nouveau mot à la mode dans les sauvegardes de nos jours. Même mon tableau de bord Avamar (produit de sauvegarde d'entreprise d2d) me dit qu'il a X To de données «protégées» pour nous.

— HopelessN00b

C'est une mauvaise utilisation malheureuse du mot «sauvegarde». Les dieux ITIL se mettent en colère, sans aucun doute. Mais, comme il s'avère que la limite de taille de fichier sur NTFS est de 16,7 To, c'est donc le problème - la sauvegarde (je suppose) est un fichier géant et 16,7 To est la limite pour cette taille. Microsoft et les autres fournisseurs peuvent le réduire et l'appeler une `` protection '' ou tout autre limace de marketing idiot qu'ils veulent, je l'appellerai toujours une `` sauvegarde ''.

— Andrew S

@AndrewS Il est utilisé comme mesure de la taille des données d'origine, avant la déduplication des données et les instantanés, etc. Et la taille limite des fichiers pour NTFS sur Server 2012 est de 256 To, et non de 16 To .

— HopelessN00b

FWIW: même problème ici. Server 2016, disques de 20 et 63 To, 16 Ko d'octets par cluster sur le volume, sous 2 ^ 32 clusters par volume, disque physique 512 secteurs d'octets et GPT. les ombres vss fonctionnent sans problème, les sauvegardes obtiennent la même erreur que vous. Je suis sur le point d'abandonner et d'écrire un putain de script PowerShell qui prend un instantané et exécute un script prédéterminé par dossier, et pour les fichiers à la racine, ce qui sera beaucoup plus difficile à gérer ...

— Cookie Monster

Réponses:

OK, la raison de l'échec de la sauvegarde de Windows Server est la taille de cluster que vous utilisez sur le volume. (Et je vais expliquer exactement pourquoi c'est à la fin, après le problème important de votre matrice RAID étant une bombe à retardement.)

Mais avant d'aborder le problème de sauvegarde, nous devons résoudre le problème avec votre configuration RAID.

N'utilisez pas RAID5 avec de grands disques. Et n'utilisez pas RAID5 avec des tableaux avec beaucoup de membres. Avec un seul disque de parité, vous êtes pratiquement certain de rencontrer une URE (erreur de lecture irrécupérable) ou une autre panne de disque avec autant de disques volumineux, vous n'avez donc pas de véritable redondance. Si vous devez utiliser le RAID de parité, utilisez le RAID6, mais même dans ce cas, le RAID de parité présente de sérieux inconvénients, alors réfléchissez bien avant de vous installer sur le RAID de parité.

Je recommanderais de briser cette baie de 20 To et de la recréer en RAID 10. Vous obtiendrez de bien meilleures performances et une véritable redondance pour vos données. Comme vous n'utilisez que 1 To de toute façon, il vous reste encore 9 To pour une croissance future, et franchement, si vous y parvenez, vous devez rechercher un périphérique NAS ou un serveur de stockage dédié.

Une fois que votre matrice RAID sera dans un état raisonnable, vous résoudrez également ce problème, car il sera plus petit que les 16 TiB dont il se plaint actuellement. Mais, si vous voulez savoir, ce n'est pas la taille du tableau avec lequel il a un problème, c'est le nombre de clusters. Vous devez avoir moins de 2 ^ 32 clusters dans le volume que vous sauvegardez. Modifiez la taille de votre cluster de 4 Ko à 8 Ko et vous devriez être prêt à partir.

Pour vérifier la taille de votre cluster, utilisez:

fsutil fsinfo ntfsinfo F:

Et vous devriez obtenir quelque chose comme le clip d'écran ci-dessous.

entrez la description de l'image ici

Si vous êtes curieux d'où vient ce numéro 16TiB, ce billet de blog msdn devrait le clarifier pour vous .

— HopelessN00b
source

Merci pour votre inquiétude concernant le RAID. J'ai essayé de convaincre mon patron de me laisser utiliser RAID6 dessus, mais sans succès. Il s'agit en fait d'un tableau de disques de 5 To, pas de disques de 2 To (désolé, j'aurais dû le préciser). La raison pour laquelle si peu de données sont utilisées est parce que nous ne l'avons pas encore mis en production. Mais ce sera finalement notre nouveau NAS. Et nous effectuons également des sauvegardes très souvent afin que nous puissions facilement récupérer à partir d'une baie dégradée. Donc, cela signifie-t-il que si je recréais le tableau avec une taille de bande plus grande, je n'aurais pas ce problème?

— Chris Powell

@ChrisPowell Désolé, j'ai mal parlé (faute de frappe). Je voulais dire cluster, pas rayé. Vous devez reformater le tableau, sauf que cette fois, sélectionnez 8 Ko (ou plus, si vous le souhaitez) pour la taille de votre cluster.

— HopelessN00b

@ChrisPowell Merci d'avoir fait l'effort de poser une bonne question ... et une autre à laquelle je pourrais aussi répondre, bonus. :)

— HopelessN00b

Juste une mise à jour; vous serez heureux de savoir que j'ai de nouveau parlé à mon patron et je l'ai convaincu de me laisser passer le NAS en RAID6 et de mettre à niveau les disques à 6 To. Merci encore pour votre aide.

— Chris Powell

Autre mise à jour: je viens de rentrer les disques, j'ai installé la baie et formaté avec une taille de cluster de 8 Ko et je reçois toujours cette erreur. Aucun conseil? J'ai vérifié mes clusters totaux et c'est bien en dessous de 2 ^ 32.

— Chris Powell

16,7 To est la taille limite de fichier pour le système de fichiers NTFS. La taille maximale de fichier de NTFS5 est de 16 exaoctets. Puisqu'il s'agit d'un lecteur de stockage partagé, il pourrait bien être au format NTFS, et non au format NTFS5. Vous devrez vérifier. Tous les inconvénients que j'obtiens sont des gens qui supposent que vous écrivez dans un système de fichiers NTFS5.

— Andrew S
source

Moins tout ce que vous voulez - cette réponse est correcte

— Andrew S

WSB n'écrira pas un fichier de 16 TiB pour ~ 1 TiB de données à sauvegarder, donc ce n'est pas ça. La source réelle du problème est la limite d'implémentation NTFS de 2 ^ 32 -1 clusters, combinée à une taille de cluster de 4 Ko , qui est la valeur par défaut depuis très longtemps.

— HopelessN00b