Newsgroup: it.comp.os.linux.sys
Titolo: Dischi ssd e raid 1

Per non perdere dati, che differenza di affidabilita' c'e' tra una
Debian casalinga su due dischi, da 500 giga l'uno, in raid 1 e su un
solo disco ssd da 500 giga?
La spesa e' la stessa: 80*2 = 360*1, l'ssd lo danno con un MTBF di 2
milioni di ore, cioe' 228 anni, percio' non si rompe mai - se non ho
capito male. Grazie in anticipo a chi puo' darmi qualche consiglio.
 
-- 
Tanti saluti
 

 milioni di ore, cioe' 228 anni
 
Ci credo quando lo vedo.
 

 solo disco ssd da 500 giga?
 
La sfiga non fa distinzioni, quindi direi che con due supporti in RAID1 
(di qualsiasi tipo) hai la metà delle probabilità di perdere tutto.
 
Bye.

Il Tue, 02 Apr 2013 09:19:57 +0000, Yoda ha scritto:
 

La differenza è che:
1) 2M ore è un numero non testabile e non garantibile da nessuno. Solo un 
markettaro lo userebbe ed un ciufolone lo accetterebbe come vero.
 
2) Per quanto i dati dei vendors possano essere affidabili, la sfiga ci 
vede benissimo e quindi "ciu is megl dan uan" nella maggior parte delle 
ipotesi
 
3) Google è di là ---> e può indirizzare le tue idee in merito, 
soprattutto sulla affidabilità e la durata degli SDD perchè, come 
leggerai, il mondo reale è ben diverso da quello dei markettari e varia 
molto soprattutto in base all'utilizzo che se ne fa.
 

 Per non perdere dati,
 
si fa il backup.
 
Il RAID1 [1] serve a non interrompere i servizi se salta un disco, non a
proteggere i dati.
 
Detto questo: assumendo che sia l'HD che l'SSD abbiano la stessa
probabilita' di rottura, mettendone 2 raddoppi la probabilita' che
almeno 1 si rompa, mentre dimezzi la probabilita' che si rompano
entrambi.
 
Ciao Jack
 
[1] in generale tutti i RAID veri (il RAID0 non e' un vero e proprio
RAID) servono a evitare (fino ad un certo punto) il downtime dovuto alla
rottura di uno o piu' dischi.
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

rottura di uno o piu' dischi.
 
Grazie, non mi era chiaro il ruolo del raid1, percio' ho fatto domande
per me inutili, ma ringrazio anche gli altri per le risposte, anche se
rinuncio volentieri a entrambi: raid1 e ssd, e' roba per reti aziendali.
Per Skull, era la seconda: "grosso problema d'aritmetica" LOL! m'avevano
appena dato i prezzi per tel e li' per li' mi son sbagliato:-))
 
Un'ultima cosa: potete dirmi in breve il backup come lo fate, o meglio
come mi consigliate di farlo? con "cp -au", con "cpio", o con altro che
non sia roba grafica ma da farlo da console, forse - penso - prima di
"shutdown -h now", grazie in anticipo?
 
-- 
Tanti saluti
 

 "shutdown -h now", grazie in anticipo?
 
qui passo la palla :)
 
Ciao Jack



 
Io personalmente per workstation e server uso backuppc
Devo ancora risolvere per il mirror del pool di backuppc, per il momento 
spero che non si spacchino tutte le macchine contemporaneamente :)
-- 
I fatti mi cosano

 proteggere i dati.
 
Non nego l'importanza del backup e condivido che raid1 e backup sono 2 
cose diverse. Infatti se su un raid1 faccio la cazzata di cancellare una 
dir importantissima, oppure si introia un database o qualsiasi altra 
catastrofe che non dipenda dall'integrità dei dischi, il raid non mi e 
di nessun aiuto.
 
Però se un disco si rompe (e murphy non ci mette lo zampino), mi 
rimangono ancora i miei dati sull'altro disco e ho il tempo di 
recuperare la situazione. Quindi anche se il raid non sostituisce il 
backup, non si può dire che serva solo a non interrompere i servizi, se 
non sei sfortunato ti può anche salvare il culo in caso di disco rotto.
 
 
 
 
 

 entrambi.
 
Che però non è equivalente a dire che dimezza la possibilità di perdere dati
 
Prendendo un determinato periodo di tempo per esempio un anno, 
l'affermazione probabilistica è certamente vera.
 
Pero' è anche vero che quando dopo 3 mesi ti accorgi che un disco è 
rotto, non aspetti gli altri 9 mesi per verificare che il dato 
statistico venga rispettato.
 
Magari, verifichi subito di avere un backup e provvedi subito a 
sostituirlo, riducendo così la possibilità di rottura doppia a quei 4/5 
giorni in cui ti procuri un disco nuovo e lo sostituisci.
 

 non sei sfortunato ti puņ anche salvare il culo in caso di disco rotto.
 
il culo te lo salva il backup in qualsiasi caso.
Il RAID ti salva il culo in un sottoinsieme molto limitato dei casi in
cui il backup e' utile.
 
E visto che cmq per un RAID hai bisogno di almeno 2 dischi, se non hai
bisogno di stare online 24/7, conviene fregarsene del RAID e mettere uno
dei 2 dischi in un case esterno e usarlo per fare un bel backup.
Chiaramente il disco va scollegato dal pc (e dall 230V) quando non sta
facendo il backup.
Oppure i soldi che avresti usato per il secondo disco li usi per fare un
backup sulla nuvola, cosi non rischi che i ladri, uando ti entreranno in
casa, ti rubino anche il disco di backup.
 
Ciao Jack


 dei 2 dischi in un case esterno e usarlo per fare un bel backup.
 
Neanche per sogno, non conviene affatto.
Sicuramente conviene avere il backup, ma
non come alternativa al RAID.
Sono due cose diverse, pensate per scopi
diversi.
Potrei concederti che il backup ha piu`
priorita` del RAID, ma non sono cose
interscambiabili.
 
bye,
 
-- 
 
piergiorgio

 casa, ti rubino anche il disco di backup.
 
Non ho molta fiducia nelle nuvole. specialmente quando lo vedo proposto 
alle aziende.
Quando all'azienda XYZ ho dato i miei dati ho specificato che l'uso 
poteva essere fatto solo a fini amministrativi. Secondo me i fini 
amministrativi non comprendono che qualcuno li sbatta su un più o meno 
sicuro servizio do cloud!!!
 
Poi se usi una normale adsl hai un download ragionevolmente veloce, ma 
l'upload a 256k non è il massimo.
 
Comunque, mi piace dropbox, ci tengo su qualcosina che mi è comodo avere 
dappertutto, soprattutto script. Ma evito di tenerci password e numeri 
di carta di credito. Benché sia ragionevolmente certo che a dropbox non 
freghi nulla dei miei dati.
 
 
 

 interscambiabili.
 
son d'accordo, ma se mi vieni a dire che metti un RAID1 cosi non perdi i
dati se ti si rompe un HD mi spiace ma non sono d'accordo.
Prima si mette in piedi un backup, poi se non si vuole avere downtime
e/o perdere il lavoro fatto dall'ultimo backup allora ok mettere un
RAID.


 RAID.
 
Che il backup serva sono d'accordo, che il RAID
sia *solo* per il downtime, no.
 
Se faccio il backup giornaliero, che e` abbastanza
frequente direi, e creo dei dati dopo un backup, ma
l'HDD si rompe prima del successivo, ho dei problemi.
Se quei dati sono il risultato di un esperimento che
richiede un mese di lavoro, pur facendo backup ogni
giorno, ho perso un mese di lavoro.
 
In quel caso serve un RAID-1, con 3 mirror persino.
 
Quindi il RAID-1 e` una sicurezza per i dati, non
solo per il downtime.
 
Chiaro che non sostituisce il backup, ci mancherebbe,
e` semplicemente una sicurezza in piu` *per i dati*
(oltre che il downtime).
 
Un altro esempio e` uno scrittore che, anche lui, fa
un backup al giorno.
Se di buon umore, tra due backup ti scrive un capitolo,
cosa succede se l'HDD muore nel mezzo, a fine giornata?
Perde un giorno completo di lavoro ed un capitolo, e
magari anche il filo del libro.
 
bye,
 
-- 
 
piergiorgio

 roba grafica ma da farlo da console
 
Normalmente uso rsync. Per avere una copia fedele:
 
# rsync -avhHPAX --delete /origine/ /destinazione
 
Piglia il comando qui sopra solo come un suggerimento di massima. Che 
*cosa* vuoi backuppare ha la sua rilevanza.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
 
http://www.worldcommunitygrid.org/index.jsp
 
http://www.rnaworld.de/rnaworld/
 
http://home.edges-grid.eu/home/
 
 
http://www.gpugrid.net/
 

 In quel caso serve un RAID-1, con 3 mirror persino.
 
Serve che i dati siano creati in più copie su più dischi. Se ciò avviene, 
a parità di numero di dischi usati e di copie distinte di dati non vedo 
però come il fatto che i dischi siano anche in RAID possa di per sé 
aggiungere *sicurezza*.
 
Per contro, fra due situazioni: 1 file creato su un RAID1 di due dischi e 
2 file creati su due dischi non in RAID (uno per ogni disco), sicuramente 
la seconda situazione è più sicura (per quanto riguarda i pericoli 
ascrivibili ad eventuali errori umani o a bug). Con due file distinti, 
creati su un RAID1 a due dischi, si va in pari.
 
IMHO.


 creati su un RAID1 a due dischi, si va in pari.
 
Il pericolo principale che quei sistemi proteggono
e` proprio la rottura di un disco e non il fatto
che qualcuno cancelli i dati.
 
Certo, un mirror di mirror e` ancora piu` sicuro.
 
I sistemi di acquisizione video usavano RAID-5,
per velocita` (in scrittura) e sicurezza.
 
Il backup veniva fatto, ovviamente, ma non ogni
quarto d'ora.
 
Oggigiorno credo usino SSD (in RAID qualcosa).
 
bye,
 
-- 
 
piergiorgio

 creati su un RAID1 a due dischi, si va in pari.
 
Teoricamente si, ma:
1) Quel sistema per i file in uso (gestionale e database) può essere 
fatto solo a fine-giornata, quando chiudi tutto. Mentre sul raid1 la 
copia è continua e se ti si rompe il disco alle 17.30 non ti sei perso 
un intera giornata, comunque anche col raid1 a fine giornata è opportuno 
fare un backup.
 
2) Nel momento che fai il backup hai un I/O molto elevato e utilizzare 
la macchina diventa scomodo. Per cui il backup in pratica può essere 
fatto quando non c'è nessuno, non ogni 5 minuti (comunque per il raid e 
simultaneo). Quindi puoi benissimo perdere una giornata di lavoro. E se 
quel giorno hai lavorato e una gran rottura di balle
 
Con 3 dischi io farei un raid1 e mi terrei l'altro come disco esterno
poi userei rsync o altra strategia in base al tipo di dati. Se poi i 
dati sono pochi rispetto al disco penserei anche ad una rotazione.
 
Comunque dipende. Se stiamo parlando di 2 tera di film. Avere 3 copie 
distinte I=interno (A,B)Esterni è più sicuro, ma e più probabile fare 
cavolate di disallineamento fra le tre copie (specie se si comincia a 
portare in giro un disco per scambi) e poi fare grosse cazzate quando si 
deve stabilire come riallineare. Nulla che non sia gestibile con un po' 
di metodo, ma aumenta il rischio dovuto al fattore umano.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

*cosa* vuoi backuppare ha la sua rilevanza.
 
-- 
Tanti saluti
 

 fatto solo a fine-giornata
 
Io pensavo invece a qualcosa di semi-istantaneo, basato su incron.


 Io pensavo invece a qualcosa di semi-istantaneo, basato su incron.
 
Dipende sempre dal traffico che si genera.
 
Inoltre, credo, sia realmente fattibile solo
con file che non sono in uso...
Quindi l'evento e` "close" di un file, ma se
un disco si rompe prima, sei punto e daccapo.
 
bye,
 
-- 
 
piergiorgio


Comunque il backup quasi istantaneo mi sembra una complicazione quasi 
inutile.
 
A quel punto è quasi come se avessi un raid1, se fai una bischerata di 
cancellare tutto e hai un backup quasi istantaneo te la replica 
immediatamente.
 
L'unico vantaggio è che "alla sera" se stacchi il disco e un 
fulmine/ladro/inondazione colpisce il PC il disco che avevi in tasca si 
salva (ammesso che tu fossi abbastanza lontano).
 
Ti concedo anche una maggior flessibilità sulla scelta di cosa 
backuppare. A discapito però di un impegno molto maggiore del PC.

immediatamente.
 
Dovresti avere un sistema di "rolled journaling" per cui ogni azione che fai
viene committata solo dopo 24 ore, o archiviata come diff.
 
Le richieste di spazio sono pero' abbastanza importanti (sul mio PC di casa,
vedo quasi 1-2 GB di traffico al giorno), sicche' servirebbe una gestione un
bel po' oculata del sistema, con un "workspace" unjournaled ed un sistema di
snapshot sincronizzato ad es. con gli update del sistema (non ha senso, fare
il backup journaled-incremental di un update massivo: conviene farlo insieme
ad un full backup). Meglio ancora sarebbe, se il sistema avesse modo di fare
comunicare il modulo disk-level con quello file-level, in modo che modifiche
provocate da scritture su file dichiarati "non interessanti" siano ignorate:
 
   --> modifico il settore 172734 del file /etc/passwd
	-> il journal registra timestamp e valore precedente del settore,
	   e il valore attuale nel backup
   --> modifico il settore 172734 del file messages
	-> il journal registra timestamp e aggiorna il valore attuale nel
	   settore
 
Dopo di che uno si ritrova con una time machine :-D
 
Leonardo
 
-- 
Were I Glenallan's Earl this tide, and were you Roland Cheyne,
My spur would be in my horse's side, the bridle upon his mane.
If they hae twenty thousand blades and we twice ten times ten,
Yet they hae but their tartan plaids, and we're mail-clad men.

 immediatamente.
 
Ma nemmeno per idea: dipende da *come* imposti il backup. :)
 
Comunque il discorso qui lo stiamo facendo, almeno io lo sto facendo, 
solo per principio! :)
 
È ovvio che, per esempio per quanto riguarda la protezione da bischerate, 
esistono altri strumenti più appropriati: versioning filesystem in primis.
 
Io avevo scritto di incron, ma allora anche un semplice 
"... | tee /qui/uno /là/due /altrove/tre ..." potrebbe creare copie 
distinte dei file.
 
Il RAID1 è un modo molto comodo di avere una o più copie dei file, su 
dischi diversi, non lo discuto. Se è un di più, male certo non fa: ma non 
è affatto la prima cosa a cui si deve pensare quando l'obiettivo è la 
sicurezza dei dati, e direi nemmeno la seconda. A parità di dischi usati 
esistono metodi magari molto meno comodi ma, sono ancora convinto, più 
sicuri. Se alla fine si vuole aggiungere pure un RAID1, però, non mi 
oppongo mica. :)


 oppongo mica. :)
 
Dipende dal modello di rischio e dal livello
di sicurezza che si vuole avere.
 
Se, altro esempio, si devono proteggere dei
dati nel momento stesso in cui sono creati,
non si puo` pensare ad un backup, dato che
non e` possibile farlo, serve un RAID.
Cosi` come se il rischio maggiore che si
corre e` la rottura dei dischi.
 
Se il rischio maggiore e` l'utente che si
cancella i dati, allora sicuramente il RAID
*non* e` la prima soluzione.
 
Insomma, non esiste una risposta generica,
bisogna valutare l'applicazione ed i rischi,
caso per caso.
 
bye,
 
-- 
 
piergiorgio

 solo per principio!
 
Anche i miei erano solo interventi di principio e anche gli altri che ho 
letto. Tutto sommato mi sembra che tutto il thread sia stato 
costruttivo. Senza sparate oltranziste in favore dell'uno o dell'altro, 
ma semplicemente per spiegarne i casi di utilizzo.