Non decidere che un disco NAS sia guasto dopo una sola disconnessione, un allarme I/O o una riga SMART. Un cavo dati SATA difettoso, un connettore allentato, un cavo di alimentazione instabile, una porta guasta, un problema del controller e un disco danneggiato possono produrre sintomi sovrapposti. Il metodo affidabile è preservare l'evidenza originale, separare gli errori di collegamento da quelli del supporto, cambiare una variabile alla volta e vedere se i nuovi errori seguono il percorso del cavo o il numero di serie del disco.
Proteggere l'array e preservare la prima evidenza
Se il NAS è degradato o disconnette ripetutamente un membro, ridurre le scritture evitabili e confermare che i dati irrinunciabili esistano su un backup leggibile separato. Registrare lo stato dell'array prima di ricollegare qualsiasi cosa. Un test del cavo ha un costo basso, ma una rimozione accidentale del secondo disco o una ricostruzione tramite una connessione instabile può creare un problema di recupero molto più grande.
Salvare il modello, il numero di serie, lo slot, il nome del dispositivo, il rapporto SMART, la cronologia degli autotest, gli eventi del controller e l'ora esatta di ogni reset o errore I/O dell'unità interessata. La guida ZimaSpace per distinguere un disco RAID caduto da uno slot difettoso utilizza lo stesso principio: identificare prima il dispositivo fisico, poi tracciare cosa segue l'errore.
Non cancellare gli attributi SMART, i contatori del controller o i log di sistema prima di salvare una baseline. Molti contatori sono totali di vita e non torneranno a zero dopo la sostituzione di un cavo. Ciò che conta è se il valore grezzo aumenta dopo una modifica controllata. Fotografare il cablaggio e etichettare entrambe le estremità previene anche che una successiva sostituzione crei incertezza su quale percorso sia stato effettivamente testato.
Costruire due ipotesi concorrenti prima di testare
L'ipotesi A è un guasto del percorso di connessione: cavo dati SATA, connettore, porta, traccia del backplane, canale del controller, connettore di alimentazione o alimentazione instabile. Questo percorso produce più spesso reset del collegamento, errori CRC, downshift, timeout dei comandi, scomparsa improvvisa o gli stessi sintomi su diversi dischi collegati tramite lo stesso percorso hardware.
L'ipotesi B è un guasto dell'unità: supporto illeggibile, settori riallocati o in attesa in aumento, autotest falliti, guasto dell'elettronica interna, rumore anomalo o errori che seguono lo stesso disco con numero di serie attraverso cavi e porte noti come funzionanti. Una discussione su BleepingComputer illustra perché gli errori di trasferimento legati al cavo non dovrebbero essere automaticamente considerati come settori fisicamente danneggiati.
Mantieni entrambe le ipotesi aperte finché le prove non le separano. Un errore CRC non dimostra che il cavo sia attualmente guasto, e un errore di lettura non dimostra che l'unità debba essere scartata immediatamente. Il modello di test dovrebbe chiedersi quali nuovi contatori crescono, quale componente segue il sintomo e se l'unità può completare un autotest lungo su un percorso stabile.
Separare gli errori di collegamento dagli errori del supporto nei dati SMART
Il conteggio degli errori UDMA CRC, spesso mostrato come attributo SMART C7 o 199, è principalmente un indizio sul percorso di comunicazione. Level1Techs spiega che un errore UDMA CRC registra una corruzione rilevata tra l'unità e il controller host. Il cavo è una causa comune, ma anche il connettore, la porta, il backplane, il controller, l'instabilità dell'alimentazione o l'elettronica dell'interfaccia dell'unità possono essere responsabili.
Gli attributi orientati al supporto indicano una direzione diversa. Il conteggio dei settori riallocati, il conteggio dei settori in attesa correnti, gli errori offline non correggibili, gli errori non correggibili segnalati e un autotest lungo che termina con un errore di lettura sono prove più forti di un problema dell'unità. I nomi degli attributi del produttore e i formati grezzi variano, quindi confronta le tendenze e i risultati dei test invece di applicare una soglia universale a ogni modello.
Un totale CRC memorizzato non è sufficiente da solo. La spiegazione di HardForum su osservare se il valore CRC grezzo continua ad aumentare cattura la distinzione chiave. Se il conteggio rimane invariato dopo la sostituzione del cavo, potrebbe descrivere un evento passato. Se aumenta durante nuovi trasferimenti, il percorso attivo del collegamento è ancora instabile.
| Prove | Più coerente con cavo, porta o percorso di alimentazione | Più coerente con un'unità guasta | Ancora ambiguo |
|---|---|---|---|
| Conteggio UDMA CRC / CRC interfaccia | I nuovi incrementi si fermano dopo il cambio di cavo o porta | I nuovi incrementi seguono la stessa unità attraverso percorsi noti come funzionanti | Vecchio totale non zero che non aumenta |
| Settori riallocati o in attesa | Di solito non creato solo dal cavo dati | I conteggi aumentano o rimangono irrisolti dopo il test su percorso stabile | Un valore storico senza tendenza o risultato del test |
| Autotest SMART lungo | Supera ripetutamente dopo la riparazione del collegamento | Fallisce a un LBA ripetibile o alla fase di lettura su un altro sistema | Interrotto perché l'unità si è disconnessa |
| Log di sistema | Reset del collegamento, errore PHY, downshift, riconnessione del dispositivo | Lettura del supporto non correggibile, errore di sensore, LBA cattivo ripetuto | Timeout generico I/O senza dettagli di livello inferiore |
| Errore segue | Stesso bay, cavo, porta, backplane o ramo di alimentazione | Stessa unità con numero di serie | Più variabili cambiate insieme |
Cambia una variabile hardware alla volta
Spegni il NAS quando l'involucro o il controller non sono progettati per l'azione hot-swap esatta che intendi eseguire. Etichetta l'unità e il cavo, quindi sostituisci solo il cavo dati SATA con un cavo corto noto come funzionante che si blocca saldamente e non è piegato bruscamente. Mantieni la stessa unità, porta, connettore di alimentazione e bay per il primo confronto.
Avvia il sistema, salva una nuova baseline ed esegui un carico di lavoro rappresentativo limitato mentre osservi nuovi errori CRC, reset o disconnessioni. La comunità Unraid nota che gli errori CRC indicano comunemente la connessione SATA ma possono anche coinvolgere l'alimentazione. Se l'errore continua, passa a una porta o ramo di alimentazione noto come funzionante mantenendo costante l'unità.
Non sostituire il cavo, spostare l'unità, cambiare la porta e scambiare il cavo di alimentazione in un solo passaggio. Questo potrebbe far scomparire il sintomo, ma distrugge le prove necessarie per identificare il componente guasto. Dopo ogni modifica, registra il tempo trascorso, il carico di lavoro, la temperatura, le variazioni SMART e gli eventi di log in modo che il risultato possa essere confrontato e non solo ricordato.
Decidi in base a cosa segue il nuovo errore
Il cavo è la causa principale quando gli attributi del supporto dell'unità rimangono stabili, i test lunghi superano e i nuovi eventi di CRC o reset si fermano dopo la sostituzione del cavo dati. Ritirare il cavo sospetto invece di reinstallarlo altrove. Se il problema si ripresenta solo su una porta della scheda madre o uno slot del backplane, il componente guasto si trova a monte rispetto al cavo.
L'unità è la causa principale quando settori illeggibili, settori in attesa, eventi di riallocazione o guasti all'autotest continuano su un cavo e una porta noti come funzionanti, specialmente quando è coinvolto lo stesso LBA o disco con numero di serie. Tom's Hardware osserva similmente che gli errori CRC da soli indicano un problema nel percorso di trasferimento, non automaticamente un disco guasto; la sostituzione dell'unità richiede prove più solide dalla salute del supporto o da test di monitoraggio degli errori.
Un percorso condiviso è la causa principale quando diverse unità si guastano nello stesso alloggiamento, sulla stessa porta del controller o sullo stesso splitter di alimentazione. Se più unità si disconnettono insieme, ispeziona l’alimentatore, il backplane condiviso, l’HBA e i connettori prima di condannare più dischi. La causa principale è il componente comune ai guasti, non necessariamente il primo dispositivo segnalato nell’allerta.
Ripara la causa confermata prima di ricostruire
Per un problema confermato del cavo, sostituisci il cavo definitivamente, fissa entrambi i connettori, correggi pieghe o tensioni e stabilisci un nuovo valore di riferimento. Verifica letture e scritture ordinarie, quindi esegui la pulizia o il controllo di coerenza supportati dalla piattaforma. Un’unità sana può tornare in servizio se gli attributi del supporto restano stabili e non compaiono nuovi errori di collegamento sul percorso riparato.
Per un problema confermato dell’unità, copia prima i dati critici leggibili, sostituisci il disco secondo la procedura dell’array e monitora la ricostruzione. Interrompi e rivaluta se un altro membro sviluppa errori o la sostituzione si disconnette ripetutamente. La spiegazione di ZimaSpace su ridondanza RAID versus recupero da backup è il confine rilevante: la ricostruzione ripristina la ridondanza, non una copia pulita precedente dei dati danneggiati.
Passa a risolvere problemi di controller, backplane o alimentazione quando lo stesso percorso interessa più unità note funzionanti. Non avviare ricostruzioni ripetute per “vedere cosa succede”. La diagnosi è completa solo quando il componente sospetto è stato isolato, il percorso di sostituzione è stabile, i contatori smettono di aumentare, l’unità o l’array superano la verifica e i dati importanti restano recuperabili fuori dal NAS.
FAQ
Un conteggio UDMA CRC diverso da zero significa che l’unità sta guastandosi?
No. Registra errori di comunicazione rilevati sul percorso drive-host. Salva il valore attuale e verifica se aumenta dopo aver sostituito il cavo e testato una porta nota funzionante.
Un cavo SATA difettoso può creare settori in sospeso?
Un cavo difettoso crea più comunemente errori di trasferimento o di collegamento. Settori in sospeso o riallocati sono indizi più forti sulla salute del supporto, ma comandi interrotti e log ambigui possono sovrapporsi. Riprova l’unità su un percorso stabile prima di decidere.
Devo eseguire un test SMART lungo su un array RAID degradato?
Proteggi prima i dati leggibili e considera lo stress sui membri rimanenti. Esegui i test secondo le indicazioni della piattaforma NAS, evita di sovrapporre compiti pesanti e interrompi se si verificano disconnessioni o errori aggiuntivi.
Supporto e consigli
Altro da leggere

Perché la capacità del RAID rimane invariata anche dopo aver sostituito tutti i dischi?
La capacità RAID mostra ancora la vecchia dimensione dopo la sostituzione con un disco più grande? Controlla lo stato della ricostruzione, le partizioni dei...

Possono unità da 5400 RPM e 7200 RPM condividere lo stesso mirror RAID 1?
Un mirror RAID 1 con velocità miste può funzionare, ma le prestazioni, la capacità, il comportamento termico e il tempo di ricostruzione dipendono dal...

Perché la capacità del RAID rimane invariata anche dopo aver sostituito tutti i dischi?
Diagnostica perché un array RAID mostra ancora la sua vecchia capacità utilizzabile dopo l'installazione di dischi più grandi, quindi espandi ogni livello di archiviazione...

