Configurazione dischi IBM x3250 M3 per server di backup

[I24Zi3L]

Salve,

forse è una domanda un po' sciocca.
In azienda ci avanza un server IBM x3250 M3 (versione 2 x HDD SATA 3,5") e due dischi Toshiba DT01ACA100 SATA III 3,5" da 1 TB.
Avendo questi pezzi pensavo di farci un server di backup con FreeNAS o Nas4Free creando delle unità iSCSI. Vorrei configurarci un Raid 1 ed acquistando ancora uno o due dischi estrarre settimanalmente un disco ed inserirne uno vuoto in maniera che si ricostruisca il Raid ed avere un disco con tutti i dati da custodire altrove.

Sulla questione ho dei dubbi:

1) Vi sembra un'idea stupida? :D
2) Non so se il tutto sia hot swap per poter estrarre ed inserire dischi a caldo.

Se avete commenti, osservazioni e/o critiche dite pure.

Grazie

[Tasslehoff]

Personalmente non ho mai ritenuto una buona idea fare una cosa del genere per diversi motivi.

Anzitutto si tratta di una operazione manuale, quindi suscettibile di mille intoppi e variabili, es un giorno ci si dimentica di portar via il disco, un altro si altro da fare, un altro ancora lo si lascia in giro ( :eekk: ).

In secondo luogo si tratta di una attività che tecnicamente è estremamente stressante e rischiosa, vista la densità dei dischi attuali scarrozzarsene uno e sottoporlo a traumi meccanici è una pessima idea.
Idem per una frequenza di rebuild, ridurrebbe sensibilmente l'aspettativa di vita delle unità e aumeterebbe i rischi di blocchi difettosi (non c'è niente di peggio di un backup che si crede sano ma che in realtà è inconsistente).

Dalla mia esperienza (in azienda e da tanti clienti) il fatto di fare un backup fatto bene, testato e documentando bene il processo di disaster recovery è già tanto.
Il fatto di conservare una copia del backup in un'altra sede è un'ottima cosa, la secondaria rispetto alla consistenza e affidabilità del backup primario; insomma imho meglio avere un backup solo ma fatto bene e ragionevolmente sicuro.

Del resto lo insegna l'esperienza, la stragrande maggioranza dei recovery è scatenata da errori umani o applicativi che compromettono i dati, non certo da uragani, incendi o furti (salvo casi particolari poi i server sono un pessimo articolo da rubare, valgono poco e si piazzano male...).

Io fossi in te installerei su quel server una normalissima distribuzione e lo userei per farci dei backup sopra usando un normalissimo filesystem di rete (nfs o samba, non vedo la necessità di usare iscsi), concentrandomi invece sulle modalità di backup (dati + bare metal) e sui restore.

[I24Zi3L]

Sinceramente non posso che essere d'accordo con te.

Però credo che sia sicuramente migliore del sistema che ora.
Premettiamo che lavoro in questa azienda da tre anni dove non si ha intenzione d'investire per un sistema informativo serio e che le mie attività spaziano dal carico scarico merci allo sviluppatore .Net passando per altre attività pseudo informatiche (:grrr:) pensa che ora il sistema di backup si basa su una serie di batch e robocopy che copia su delle cartelle consivise che risiedono su di un disco esterno USB collegato ad un normalissimo client Windows XP con l'aggiunta di un NAS da TB che per il momento tiene il backup della posta (*.dbx e *.pst). Il backup dei server viene fatto una volta ogni sei mesi con il programma predefinito di Windows Server 2003/8 ed il venerdì vengono messi su cassetta i dati più importanti assieme all'immagine di uno dei server a rotazione. Piccolo particolare: Ci vogliono almeno due cassette per terminare il backup ed lettore ha uno solo slot quindi passo tutta la settimana a cambiare cassetta per la verifica etc. :nono: Tò, mettici pure che una volta su tre il backup su cassetta fallisce... Ecco, partendo da questa situazione pensavo di cogliere l'occasione di questo server dismesso e dei dischi per migliorare almeno il backup: Ci farei l'immagine dei server ogni giorno e ci copierei i dati dei client direttamente (ora fanno un po' di giri) e l'unica operazione manuale che rimarrebbe è quella della sostituzione dei dischi una volta a settimana.

Considerando che le cassette oramai 6 anni pensavo di proporre questo sistema per cercare di migliorare le cose anche se non avevo pensato che la frequenza dei rebuild potesse inficiare sull'efficenza dei dischi.

Condivido anche sulla questione del disaster recovery.
In effetti in tre anni non ho mai assistito ad incendi e/o uragani, poi ovviamente il CED è chiuso a chiave e ci sono i rilevatori di fumo. Però diciamo che ci sono più burocrati che tecnici quindi il backup settimanale dev'essere tenuto in un'altra stanza ed una volta al mese in un'altra sede.

L'uso dell'iSCSI mi è stato suggerito da un collega in transito per via della maggiore velocità di trasferimento.
Per quanto riguarda il disaster recovery ho provato il nuovo Windows Image Backup su un client Windows 7 e sembra che funzioni bene anche dovendo fare un bare-metal, non ho avuto modo di prova con i server ma vedo che nei file *.vhd trovo tutti i file eventualmente da ripristinare. Invece non ho idea di come ripristinare un sistema col programma di backup di Windows Server 2003.

Ma speriamo di non averne mai bisogno perché avendo tutto fisico e nulla di rindondato dovremmo appena ordinare un server uguale per poterlo ripristinare. :sperem:

[I24Zi3L]

Ma al di la dell'affidabilità come idea è fattibile?
Ogni tanto sento la voce che i dischi SATA sono tutti hot swap anche se non viene specificato perché nascono proprio così.

Beh, il server credo che abbia un controller hot swap.

[Tasslehoff]

Ma al di la dell'affidabilità come idea è fattibile?
Ogni tanto sento la voce che i dischi SATA sono tutti hot swap anche se non viene specificato perché nascono proprio così.

Beh, il server credo che abbia un controller hot swap.Tecnicamente dovrebbe essere così nella quasi totalità dei casi, praticamente bisogna verificare caso per caso.
Anzitutto il controller dev'essere configurato come interfaccia AHCI o Raid, in caso contrario niente hotplug.
Poi non è scontato che il server abbia un controller hot swap.

[Tasslehoff]

Sinceramente non posso che essere d'accordo con te.

SNIPCapisco perfettamente la frustrazione che provi nel trovarti a lavorare in una condizione simile, ahimè ci siamo passati tutti (o quasi). :rolleyes:

Visto lo scenario che descrivi io valutarei (o magari proporrei in ottica migliorativa) il cambio di drive e cassette per i backup, potrà sembrarti una soluzione obsoleta ma in realtà gli LTO sono ancora il miglior sistema per effettuare backup (per mille motivi, capacità, costi, durata dei dispositivi, affidabilità), rispetto al passato poi oggi hai un transfer rate molto alto, una maggiore comodità (con LTOfs puoi usare i nastri come se fossero semplici drive esterni, chiaramente sono unità lineari quindi la ricerca dei dati è piuttosto lunga, insomma è più comoda l'interfaccia ma non sono dischi USB), un rapporto di compressione notevole e una grande capacità.
Insomma gli LTO si sono evoluti tanto e il loro uso si è esteso (dai backup anche alle archiviazioni massive in ambito video), i costi iniziali di un drive non sono banali, però si ripagano facilmente visto il basso costo dei nastri.

In alternativa ci sono anche i drive RDX, sono come piccoli hard disk estraibili e pensati per questo tipo di utilizzo, molto resistenti e con delle buone performance.
I drive costano poco (nell'ordine del centinaio di euro o poco più) e non richiedono necessariamente un controller SAS (ci sono anche USB), ma i supporti sono molto costosi, molto più dei drive LTO.

Per il backup bare metal di server Windows puoi provare a usare Drive Snaphot, per server GNU/Linux o Unix vai script bash che con un ciclo for si spazzoli tutti i volumi con dump.

Per il test non hai bisogno di un server identico, anzi imho è molto più utile provare a fare un restore usando una virtual machine (scegli tu l'hypervisor, basta anche un semplice e gratuito Vmware Player), in caso di guasto difficilmente i troverei ad avere subito a disposizione un server identico (o lo stesso riparato), è molto più realistico pensare di ripristinare subito il servizio usando una VM, far lavorare gli utenti su questa e poi con calma spostare il tutto sul server nuovo o riparato.