Errore di backup di Windows Server - Volumi superiori a 16,7 TB non possono essere protetti?

Sto cercando di utilizzare Windows Server Backup per eseguire il backup di un array RAID sul mio nuovo server. Ma, quando lo faccio, mi imbatto in questo errore:

inserisci qui la descrizione dell'immagine

Il server esegue Windows Server 2012 R2 e l'array in questione ha una dimensione di 20 TB (con 18 TB utilizzabili); meno di 1 TB è attualmente in uso.

So che in Windows Server 2008 non è stato possibile eseguire il backup di volumi superiori a 2 TB a causa di una limitazione nel disco rigido virtuale, ma ora Microsoft è passato a VHDX, il che consente di eseguire il backup di volumi da 64 TB. Sono anche consapevole del fatto che, per trarne vantaggio, l'unità in questione deve essere GPT.

Ho confermato che il mio disco è, in effetti, GPT.

inserisci qui la descrizione dell'immagine

Quando eseguo Windows Server Backup, utilizzo l'opzione "Backup una volta" e il backup su un'unità di rete. Sto anche usando quelle che credo siano impostazioni standard. Ma, quando tento di eseguire il backup, mi viene presentato l'errore sopra riportato.

Non sono sicuro del motivo per cui questo è limitato a 16,7 TB, poiché Windows Server Backup può eseguire il backup di volumi fino a 64 TB. Qualcuno può darmi qualche idea sul perché questo potrebbe accadere o cosa potrei fare di sbagliato?

Aggiornamento: ho ricevuto nuove unità e creato di nuovo l'array ma sto ancora ottenendo lo stesso errore. Posso confermare che il mio conteggio dei cluster è inferiore a 2 ^ 32.

inserisci qui la descrizione dell'immagine

Ho letto in questa domanda che apparentemente il backup di Windows non supporta il backup su o da dischi che non hanno settori di byte 512 o 512e. Guardando la condivisione file su cui sto tentando di eseguire il backup, utilizza settori 4K. Potrebbe essere questo il problema di fondo? Se aiuta, la condivisione su cui sto tentando di eseguire il backup viene ospitata su un server CentOS.

— Chris Powell
fonte

È di per sé un messaggio "protetto", non un messaggio spaziale. Le "impostazioni standard" sono per un backup del server Windows è utilizzare DPM - Data Protection Manager. Sembra che ci sia una limitazione del software quando si utilizza DPM. Potresti voler vedere se le impostazioni consentiranno una copia byte per byte, senza la cosiddetta 'protezione' abilitata, supponendo che tu abbia un modo per ripristinare una copia byte per byte se necessario.

— Andrew S,

@AndrewS No, questo è un messaggio da Windows Server Backup. Oggigiorno "Protetto" sembra essere la nuova parola d'ordine nei backup. Anche la mia dashboard di Avamar (enterprise d2d backup product) mi dice che ha X TB di dati "protetti" per noi.

— HopelessN00b,

Questo è uno sfortunato uso improprio della parola "backup". Gli dei ITIL si stanno arrabbiando, senza dubbio. Ma, come risulta, il limite di FORMATO FILE su NTFS è 16,7 TB, quindi questo è il problema: il backup (suppongo) è un file gigante e 16,7 TB è il limite per quella dimensione. Microsoft e gli altri fornitori possono manipolarlo e chiamarlo "protezione" o qualsiasi altra lumaca di marketing idiota che vogliono, lo chiamerò comunque "backup".

— Andrew S,

@AndrewS Viene utilizzato come misura della dimensione originale dei dati, prima della deduplicazione dei dati e dello snapshot e così via. E il limite della dimensione del file per NTFS su Server 2012 è 256 TiB, non 16 TiB .

— HopelessN00b,

FWIW: stesso problema qui. Server 2016, unità da 20 e 63 TB, 16 KB byte per cluster sul volume, meno di 2 ^ 32 cluster per volume, settori del disco fisico 512 byte e GPT. vss shadows funziona senza problemi, i backup ottengono lo stesso errore. Sto per rinunciare e scrivere un dannato script PowerShell che scatta un'istantanea ed esegue uno script predeterminato per cartella, e per i file alla radice, che sarà molto più difficile da gestire ...

— Cookie Monster

Risposte:

OK, il motivo per cui Windows Server Backup non riesce è a causa della dimensione del cluster che si sta utilizzando sul volume. (E spiegherò esattamente perché è alla fine, dopo che l'importante questione del tuo array RAID è stata una bomba a orologeria.)

Ma prima di affrontare il problema del backup, dobbiamo risolvere il problema con la tua configurazione RAID.

Non utilizzare RAID5 con dischi di grandi dimensioni. E non usi RAID5 con array con molti membri. Con un solo disco di parità, sei praticamente certo di imbatterti in un URE (errore di lettura irrecuperabile) o in un altro errore del disco con così tanti dischi di grandi dimensioni, quindi non hai una reale ridondanza. Se devi usare il RAID di parità, usa RAID6, ma anche in questo caso, il RAID di parità presenta gravi inconvenienti, quindi pensa a lungo prima di accontentarti del RAID di parità.

Consiglierei di suddividere quell'array da 20 TB e ricrearlo in RAID 10. Otterrai prestazioni molto migliori e ridondanza reale per i tuoi dati. Dato che stai usando solo 1 TB, hai ancora 9 TB per la crescita futura e, francamente, se lo colpisci, devi cercare un dispositivo NAS o un server di archiviazione dedicato.

Una volta portato l'array RAID in uno stato ragionevole, risolverai anche questo problema, perché sarà più piccolo dei 16 TiB di cui attualmente si lamenta. Ma, se vuoi sapere, non è la dimensione dell'array con cui ha un problema, è il numero di cluster. È necessario disporre di meno di 2 ^ 32 cluster nel volume di cui si esegue il backup. Cambia la dimensione del tuo cluster da 4 KB a 8 KB e dovresti essere pronto.

Per verificare la dimensione del cluster, utilizzare:

fsutil fsinfo ntfsinfo F:

E dovresti ottenere qualcosa di simile al seguente screenclip.

inserisci qui la descrizione dell'immagine

Se sei curioso di sapere da dove provenga quel numero 16TiB, questo post sul blog msdn dovrebbe chiarirlo .

— HopelessN00b
fonte

Grazie per la tua preoccupazione per RAID. Ho provato a convincere il mio capo a lasciarmi usare RAID6, ma non ci sono riuscito. In realtà è in una matrice di dischi da 5 TB, non in dischi da 2 TB (mi dispiace, avrei dovuto specificarlo). Il motivo per cui vengono utilizzati così pochi dati è perché non li abbiamo ancora messi in produzione. Ma alla fine sarà il nostro nuovo NAS. Inoltre eseguiamo backup molto spesso per consentirci di ripristinare facilmente da un array degradato. Quindi, ciò significa che se ricreassi l'array con una dimensione di striping maggiore non avrei questo problema?

— Chris Powell,

@ChrisPowell Siamo spiacenti, ho sbagliato a scrivere (errato). Volevo dire cluster, non striscia. È necessario riformattare l'array, tranne questa volta, selezionare 8 KB (o più, se lo si desidera) per le dimensioni del cluster.

— HopelessN00b,

@ChrisPowell Grazie per lo sforzo di porre una buona domanda ... e anche una a cui potrei rispondere, bonus. :)

— HopelessN00b

Solo un aggiornamento; sarai felice di sapere che ho parlato di nuovo con il mio capo e l'ho convinto a farmi passare il NAS a RAID6 e aggiornare le unità a 6 TB. Grazie ancora per il tuo aiuto.

— Chris Powell,

Un altro aggiornamento: ho appena inserito le unità, ho impostato l'array e formattato con una dimensione del cluster di 8 KB e sto ancora ricevendo questo errore. Qualche consiglio? Ho controllato i miei cluster totali ed è ben inferiore a 2 ^ 32.

— Chris Powell,

16,7 TB è il limite di dimensione del file per il file system NTFS. Il limite della dimensione del file di NTFS5 è 16 exabyte. Poiché si tratta di un'unità di archiviazione condivisa, potrebbe essere formattata NTFS, non formattata NTFS5. Dovrai controllare. Tutti i punti negativi che sto ricevendo sono persone che presumono che tu stia scrivendo su un file system NTFS5.

— Andrew S
fonte

Meno tutto ciò che vuoi - questa risposta è corretta

— Andrew S

WSB non scriverà un file di 16 TiB per ~ 1 TiB di dati per il backup, quindi non è quello. La vera fonte del problema è il limite di implementazione NTFS di 2 ^ 32 -1 cluster, combinato con una dimensione del cluster 4KB , che è stata l'impostazione predefinita per molto tempo.

— HopelessN00b,