Newsgroup: it.comp.hardware
Titolo: Data Storage, cosa è meglio!

Ciao, mi hanno chiesto che cosa sarebbe meglio per salvare in real time una
mole di dati di circa un GB. Io avrei pensato ad un secondo HD immagine da
piazzare sul server, ma se, sfiga vuole, il server va in corto e prende
fuoco il lavoro è comunque da buttare. Voi cosa consigliate? Soluzioni tipo
affidare questi backup a server su sistemi esterni all'azienda (penso ad
I.net) sono molto costose? (tenete presente che in quest'azienda c'è
fastweb, quindi non ci sono grossi problemi di banda in uscita...)


Prende fuoco??? Ma che server è? Di carta?
Le soluzioni migliori secondo me senza dover utilizzare aziende esterne o
far passare i dati attraverso Internet è quello  di prendere un secondo pc
collegato con la scheda di rete al server, oppure visto che mai il tuo
server prenderà fuoco, di prendere un secondo hard disk e  una scheda Raid
in modo che i backup vengano fatti nel momento in cui i file vengono
scritti, ovvero in realtime come chiedevi tu.
Susa

"Ghepardo" <pippoc...@TOGLIQUESTOtiscalinet.it> ha scritto nel messaggio
news:3mEV9.54996$AA2.2...@news2.tin.it...

Può anche utilizzare un appliance esterna dove memorizzare i dati
più importanti... ovvero un sistema NAS.
Ciao

 in corto e prende fuoco il lavoro è comunque da buttare.
Se il server va in corto anche se tu hai un sistema esterno non ti serve a
nulla, i dati glieli dovrai passare no?

 scritti, ovvero in realtime come chiedevi tu.
Grazie lo stesso x l'idea ma se rubano il server con i due hard disk?
Lo so che sono ipotesi assurde ma la legge di Murphy è bastarda e vera...
La scheda raid invece che cos'è, deve essere all'interno del server o può
stare anche a qualche metro di distanza?

 nulla, i dati glieli dovrai passare no?
Bè, a me interessa per farne un ripristino dati, è chiaro che se va in corto
per qualche giorno il lavoro è sospeso.

"Ghepardo" <pippoc...@TOGLIQUESTOtiscalinet.it> wrote in message
news:V8QV9.57446$AA2.2...@news2.tin.it...

La scheda Raid è una scheda pci e quindi è interna al server... e se
disgrazia vuole che crolli il soffitto e il tuo server viene schiacciato
allora perdi entrambi gli hd e le copie di backup non ti sono servite a
nulla. L'ideale è che i sistemi di backup si trovino in un'altra stanza.
Quindi io ti consiglio ancora o un hd usb con un luuungo cavo, o un secondo
pc collegato al primo. Ma la soluzione migliore rimane comunque la scheda
Raid.
Susa

 in un'altra stanza.
Beh... se la vogliamo mettere in questi toni:
- E se crolla il palazzo?
- E se cade un meteroite sul palazzo?

 Raid.
Grazie per la delucidazione, effettivamente la scheda RAID mi pare la
soluzione migliore, il problema rimane che in caso di furto del server ci si
dovrebbe attaccare al caz... ehh al tram!
Grazie ancora, ciao!

 scritti, ovvero in realtime come chiedevi tu.
secondo me è preferibile u sistema esterno. Forse un musor che cade o un 
incendio sono molto rari...ma un alimentatore danneggiato che rovina tutti 
i componenti del pc non è cosi' improbabile!
ciao
STEFANO


Accidenti che pessisimisti che siete... ;-)

 mole di dati di circa un GB. 
Io adotterei una doppia (o tripla) soluzione composta da:
- RAID (hardware o software)
- Backup incrementali su altra macchina (FTP, rsync)
- Backup incrementali ogni giorno e completi ogni settimana su nastro 
(DAT), magari doppio (uno lo tieni nello stesso armadio del server e 
l'altro in cassaforte).
Ciao
Mattia

 Accidenti che pessisimisti che siete... ;-)
Dopo aver visto un sistema "RAID-5 SCSI HotSwap" con 3 dischi fissi andare
in allarme perchè se ne erano danneggiati contemporaneamente due su tre ho
perso parte del mio ottimismo sui sistemi di backup :-(
... pessimismo & fastidio...


Accipicchia...mai vista una sfig ehm sfortuna simile... :-\

 fuoco il lavoro è comunque da buttare. Voi cosa consigliate? Soluzioni
tipo
Se non hai problematiche di sicurezza (furto) dei dati ti consiglierei di
mettere un controller raid sul server, aggiungere un disco e fare un bel
raid 1. Poi la notte, a mezzogiorno, o comunque in un orario in cui nessuno
lavora, programmi un comando che copia i dati dal server a uno dei client.
Se il server è importante non sarebbe male pensare ad un sistema di backup
migliore ed a fare un ghost ogni tanto su un disco estraibile da portarti a
casa o in un altro luogo sicuro.

> Accipicchia...mai vista una sfig ehm sfortuna simile... :-\
beh...un mesetto fa: server linux che effettua il backup di una rete di 5 
pc.
un giorno lo porto in assistenza...nelfrattempo penso..."se si dovesse 
rompere l'HD SCSI del mio pc proprio oggi sarebbe uan sfiga incredibile".
14:00..tornoa lavoro...accendo il pc...SGRRRR SGRRRR! bene! HD 
completamente morto!!!!
fortuna che avevo salvato i dati importanti su cd!
mai sottovalutare la sfiga :)
ciao
STEFANO

 perso parte del mio ottimismo sui sistemi di backup :-(
Attenzione che il sistema RAID non č un sistema di backup!!!
Sempre e in ogni caso ogni server con configurazione RAID dei dischi va
affiancato ad un ottimo sistema di backup su nastro! Che puň essere DAT
oppure dei tandberg (per citare i piů famosi... ma penso che siano che gli
unici validi)! Naturalmente va studiata nei minimi particolari tutta la
strategia di backup!
Per le certificazioni ISO poi i nastri (obbligatori) devono essere
conservati in una stanza diversa dentro un armadio blindato e ignifugo!
E questo č solo il minimo...
Ciao ciao
--
MirkoB.
jjm...@libero.it

 Attenzione che il sistema RAID non è un sistema di backup!!!
Il termine backup è generico.
Anche il classico mirroring di alcuni sistemi RAID rientra nella categoria
dei sistemi di backup (ovviamente è un backup mirato alla tolleranza dei
guasti hw, non è un backup inteso come "copia di riserva nel caso la
principale venga erroneamente modificata").

 Attenzione che il sistema RAID non è un sistema di backup!!!
[...]
Mi risulta che un sistema RAID ha un MTBF *minore* [*] di quello dei suoi 
(singoli) componenti.
In altre parole, più un sistema informatico/meccanico/... è complesso, più è 
facile che si guasti... Si installa un RAID per migliorare *non* 
l'affidabilità, ma la *tolleranza* del sistema per i *guasti*.
Se ho affermato qualcosa di impreciso, fatemelo sapere, così starò in piedi 
corretto.  :-))
[*] La relazione tra gli MTBF mi ricorda un pochino la definizione di
    media armonica. ;-)

 l'affidabilità, ma la *tolleranza* del sistema per i *guasti*.
Alla fine dei conti aumenti l'affidabilità totale del sistema! Non è che il
sistema non si guasti più... ma anche a causa di un guasto (in questo caso
sui dischi) il sistema funziana senza battere ciglio!
Il sistema ha "tollerato" (come dici tu) magnificamente il problema e in
questo modo è diventato molto più affidabile!
Non capisco dove vuoi arrivare con la tua affermazione!


 dei sistemi di backup (ovviamente č un backup mirato alla tolleranza dei
Ma tu consiglieresti un raid se ti chiedessero un sistema di backup? Io no!
O meglio... se consiglio un raid di conseguenza ci sta anche un valido
sistema di backup!


 Alla fine dei conti aumenti l'affidabilità totale del sistema!
<Achtung! lana caprina>
Un sistema con RAID (più in generale, con qualsiasi forma di 'ridondanza') 
non si ferma, anche se si *guasta*: si parla di _tolleranza del sistema per 
i quasti_.
D'altra parte, poiché un tale sistema (più complesso) si *guasta* *più* 
*spesso*, esso risulta *meno* *affidabile*.  Sono due concetti distinti, mi 
pare.
Da un punto di vista pratico, siamo perfettamente d'accordo: è importante 
che il sistema NON si fermi per uno (o più) guasti.  Tuttavia non definirei 
"più affidabile" un sistema che si guasti con maggior frequenza... anche se 
è più tollerante/resistente ai guasti.
In altre parole, un sistema complesso è più fragile (dunque *meno* 
affidabile) di un sistema semplice; per la sua *particolare* 
*configurazione*, un sistema con RAID, pur essendo soggetto a guasti più 
frequenti[*], li tollera meglio.  Per un sistema senza RAID, un guasto, 
ancorché più raro, può essere fatale.
-- (H)istoreo
[*] Il cosiddetto MTBF di un componente ha un significato squisitamente
    *statistico*.  ;-)