Newsgroup: it.comp.hardware.storage
Titolo: Disastro con raid 5

In azienda sembra che sia partito il controller, e che i dati non siano 
piï¿œ recuperabili. Un tecnico avrebbe detto che i dati non sono 
recuperabili proprio a causa della configurazione raid E' possibile che 
un sistema raid 5 metta al riparo dalla rottura dei dischi ma non del 
controller? Sarebbe un beffa...

"Danilo" <a@b.c> ha scritto nel messaggio

Basta collegare gli HD a un controller identico o comunque della stessa 
famiglia.
-- 
Saluti
Alec (31,72+,265,CT)
Powered by AMD Phenom II X3 710 @ X4 3.4GHz
Fueled by ATi - Sapphire HD3300-OC
OnLine by Alice TuttoIncluso 7M

controller? Sarebbe un beffa...
Nessun RAID mette al riparo da una rottura del controller, perch� una
rottura del controller pu� equivalere a una rottura di tutti i dischi
che ci sono attaccati.
Pu� anche darsi che si tratti di una rottura che lascia tutto intatto
e basta sostituire il controller, ma non � detto. Ci pu� essere una
rottura che corrompe i dati.
Per difendersi dalla rottura di un controller bisogna ridondarlo
(duplexing).
In ogni caso � bene avere un backup recente.
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 beffa...
Amenochï¿œ il chip di gesitone hardware abbia sistematicamente corrotto 
tutte le scritture (cosa ripeto rara, dato che occorre tempo per fare 
ua cosa del genere, e poi sarebbero apparsi dei messaggi d'allerta se 
il controller in uso ï¿œ di buona qualitï¿œ), come ha detto Alec 
probabilmente se collegate i dischi ad un controller dello stesso 
modello ï¿œ probabile che i dati possano essere recuperati.
Comunque anche se si ha un RAID5 il bakcup non deve essere 
trascurato...specie in ambienti lavorativi.


Mi sa che e' una bella scusa per non recuperare i dati

Danilo wrote:

in genere basta usare un controller uguale (sperando di trovarlo).
ma il tecnico ha provato con un controller uguale, o ha semplicemente
sentenziato la morte, perchï¿œ il problema potrebbe proprio essere il
fatto di non trovare piï¿œ il controller.
verifica anche i firmware dei controller, ho giï¿œ avuto problemi con
controller uguali, ma firmware diversi ...
-- 
my blog: 
www.r3lative.it

 (server video)
Probabilmente li lo fanno anche per una questione di prestazioni...

 fatto di non trovare piï¿œ il controller.
LOL... buona la seconda misï¿œ.

 raid la TV andava a nero.
Li si scrive/cancella in continuazione e in "real time".

 no, si legge e basta, piï¿œ o meno.
Ma anche no...dipende dall'uso.

 di volte nel caso di una pubblicitï¿œ.
Conosco quegli apparecchi... li usa anche mio fratello che lavora in 
una TV privata tra l'alto. E li ci caricano dati anche due volte al 
giorno, dipende dal palinsesto :)

 fai? tutto � corrotto, punto.
vorrei far notare che esiste il controllo d'errore.
Se un dato viene scritto sbagliato per un motivo o per un altro, il
controller se ne accorge e si adegua.
Se un cavo per qualche ragione � guasto, il controller manda in fail
il disco. Il controller � anche in grado di mandare off-line l'intero
array se necessario. 
E' vero che un controller guasto pu� fare qualsiasi cosa, ma � anche
vero che dovrebbe segnalare la situazione. Poi ovvio che se si usano
dei controller da due lire tutto � possibile.
-- 
MirkoB.   
ne...@bsi-net.it
Motoretta BMW R1150R Nera...
L'indirizzo em@il non � da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente.

 tutti i dischi contemporaneamente, array perso.
L'array non � perso, al limite � perso il dato. In ogni caso il
controller � (e deve essere) in grado di capire che c'� un problema!
Se il controller deve scrivere A e per qualche ragione viene scritto B
se ne accorge.


 controller? Sarebbe un beffa...
Capitato ad un cliente tempo fa.
Addirittura si erano corrotti alcuni dati che il controller impazzito
aveva scritto in modo sbagliato.
Sostanzialmente il database centrale del cliente si era totalmente
corrotto.
-- 
Freccia@Bulldozer63 :D

 filo a GND � troppo tardi.
connessione fisica scsi? (a parte che scsi non esiste pi�, ma ora c'�
sas) Ma guarda che il controller se ne accorge se c'� qualcosa che non
va. Se un cavo � andato il controller manda in fail il disco oppure
(forse pi� probabile) manda offline l'array.
Considera che il disco viene mandato in fail non solo quando si guasta
irrimediabilmente, ma anche solo quando vengono generati un certo
numero di errori.


 e io di quello parlavo! :D
guarda, � da molto che non ho a che fare con controller scsi, ma mi
sento di dire che anche su scsi in caso di cavo guasto venisse mandato
offline l'array.


 viaggia sulle interfacce piï¿œ moderne).
Infatti i comandi di base piï¿œ o meno sono rimasti invariati... ï¿œ 
cambiato piï¿œ che altro il protocollo di comunicazione.

 un filo a GND � troppo tardi.
Mah, da esperienze remote se il controller non � in grado di scrivere
dati corretti per qualsivoglia motivo d� per perso l'intero array, non �
che continua a scrivere rumenta sui dischi.
Il che chiaramente non esclude schifocontroller che non controllino
la propria connessione con i dischi, ma io non ne ho mai visti e
immagino sia necessario un certo impegno per scrivere un firmware
del genere.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png

 corrotto.
Beh ok, in questo caso capisco che ci sia perdita di dati, perch�
il dato corrotto va a distruggere una struttura pi� ampia.
Ma nel caso di un fileserver al massimo si dovrebbero corrompere
i file scritti o modificati durante il guasto, non l'intero fs.


 
Sicuramente i dati non erano recuperabili, perchï¿œ li abbiamo recuperati 
da un backup, nemmeno tanto recente. Non ï¿œ infrequente che 
l'amministratore si assenti anche per giorni, per cui i messaggi di 
allerta ï¿œ probabile che non sono stati letti.

 
Il controller non si trovava piï¿œ, probabilmente era vecchiotto.

  
Nemmeno io... ma percaritï¿œ, tutto puï¿œ accadere a questo mondo :D

 sono stati letti.
Non ï¿œ escluso infatti...

 un filo a GND � troppo tardi.
intanto presumo sia un caso piuttosto raro, in ogni caso a me era
successo una cosa simile, il bus scsi con qualche problema, ma veniva
indicato come guasto di un hd (3 in 2 mesi), ed infatti al 3� hd hanno
sostituito il cestello dischi (e relativo backplan oltre all'hd ) senza
perdita di dati o altro ...
la macchina � andata avanti fino alla sua naturale dismissione senza
altri problemi.
-- 
my blog: 
www.r3lative.it

 i file scritti o modificati durante il guasto, non l'intero fs.
scusa, ma un controller mica sa se quello che scrive sono file, file di
sistema o struttura del fs ... quindi se deve corrompere, corrompe in
modo indistinto tutto quello che gli capita ....
piï¿œ che altro mi sembra strano che non siano apparsi errori. sarebbe
interessante sapere di che controller si trattava ... a naso direi
molto economico ...
-- 
my blog: 
www.r3lative.it

Danilo wrote:

ï¿œ uno dei tanti motivi per cui i server devono essere di certe marche,
almeno ti garantiscono la reperibilitï¿œ dei componenti per almeno i 3
anni di garanzia :)
cosa che in genere gli assemblatori o marchi "meno" noti non sono in
grado di garantire (se non a parole)
l'ultima che ho sentito era un commerciale che vendeva la garanzia come
assicurazione... tralascio il mio sarcastico commento, sul cosa poteva
assicurarsi in caso di guasto ...
-- 
my blog: 
www.r3lative.it

 in modo indistinto tutto quello che gli capita ....
Quello che intendo � che un controller che ha un problema di qualche
tipo non riesce a scrivere o leggere correttamente i dati per cui viene
richiesto l'accesso, non � che si mette a scrivere dati a casaccio per 
sport.
Se sui dischi c'� un database e i dati errati sono quelli del file dati, �
possibile che l'intero file dati si corrompa e in alcuni db questo pu�
essere fatale.
Se quello era un fileserver i dati corrotti saranno relativi ai file che 
sono
stati creati/modificati durante il fail, ma tutto il resto del fs dovrebbe
continuare ad avere una sua consistenza.
Con questo comunque non escludo casi in cui (magari a causa di un fail
prolungato nel tempo e con grande traffico dati) la corruzione del fs possa
arrivare al punto di non ritorno, � che mi sembra difficile che un array 
possa
sputare fuori dati sballati per giorni e giorni senza che nessuno si chieda
che vuol dire 'file doc corrotto, impossibile aprire'.


 aprire'.
imho la scrittura/aggiornamento dei blocchi dedicati alla gestione del
fs comportano problemi ben piï¿œ gravi, e considera che qualsiasi
scrittura puï¿œ comportare l'aggiornamento di quelle aree, quindi basta
inserire un file nuovo, cancellarne uno, o anche il solo aggiornamento
della data comporta la corruzione del fs... a quel punto che sia un db
server o un file server ha poca importanza ... devi solo sperare nel
backup
-- 
my blog: 
www.r3lative.it

 Nemmeno io... ma percarit�, tutto pu� accadere a questo mondo :D
mi accodo alla perplessit� generale, e vorrei aggiungere che
insieme ai dati vengono trasmessi/ricevuti anche i comandi
SCSI e questi vanno interpretati, non semplicemente digeriti
poi non credo non ci sia un minimo di controllo di parit� in
tutta la trasmissione/ricezione dati, e se c'� un bit/circuito/cavo
a "0" il sistema se ne accorge e nel giro di qualche secondo o
minuto, viene segnalato un errore, o qualche disco viene disconnesso
dopodich� sta all'amministratore gestire la fase critica
il protocollo SCSI � molto affidabile e per questo anche molto
rigido, uso ancora SCSI in alcuni sistemi e quando si verifica
una rottura nei cavi (o un minimo di malfunzionamento) il
controller se ne accorge subito e fa il RESET
idem, se un bus � a "0", � compromessa l'intera catena
comandi+dati ed anche qui il controller se ne accorge
in quanto il disco non risponder� al comando
ciao
luca
ps: non riesco a partecipare alla discussione perch� �
troppo veloce :)

 della data comporta la corruzione del fs...
Vabb�, se usi fat12 sui tuoi array mica � colpa mia :-)


 Il controller non si trovava più, probabilmente era vecchiotto.
sono ragionevolmente certo che su 
ebay.de
, .
co.uk
 o .com lo avresti 
trovato.. il mercato italiano di parti di classe "enterprise" (vedi ad 
esempio nastri e tape library) è inesistente
S.