La vicenda OVHcloud ci ricorda l’importanza di avere un piano per il Disaster Recovery

[Redazione di Hardware Upg]

Link alla notizia: https://edge9.hwupgrade.it/news/clou...ery_96288.html

I disservizi causati dagli incendi ai server di Strasubrgo evidenziano l'importanza di preparare un piano di Disaster Recovery adeguato, che consenta di ripristinare almeno i servizi critici il prima possibile, perché l'imprevisto è sempre dietro l'angolo

Click sul link per visualizzare la notizia.

[canislupus]

Beh se non è stato fatto sono due le motivazioni:

1) Soldi (a nessun imprenditore piace spendere soldi per qualcosa che non si dovrebbe mai usare)
2) Incompetenza

Poi c'è da dire una cosa... un disaster recovery RARAMENTE avrà mai le medesime prestazioni di un sistema Online... spesso avrà funzioni molto limitate e dove non fosse possibile operare in tal modo, vi saranno limitazioni a livelli di banda oppure di prestazioni.

Dove lavoro io ce lo abbiamo... ma l'unica volta che per un problema ad un server dovevamo usarlo, è stato preferibile avere un down di diverse ore (e vi assicuro che si perdono tanti soldi) perchè il rollback avrebbe richiesto dei giorni.

Ovviamente questa è una situazione assurda, ma purtroppo il nostro sistema ha delle lacune strutturali che non sempre rendono possibile l'uso del disaster recovery (tranne se prende fuoco tutto il CED... )

[Rubberick]

Il punto è non arrivare ad una situazione dove succede il casino completamente scoperti.

Un sistema ridondato online dedicato è ovviamente esageratamente costoso, esistono però delle soluzioni intermedie a più livelli che permettono di tenersi su pur tamponando sui costi.

Non dico che un nas aggiornato periodicamente off-site sia la soluzione ma può esserlo per molte ditte medio-piccole.

[acerbo]

il disaster recovery nelle grandi aziende é implementato da almeno 20 anni, in telecom facevamo i test di switch del datacenter nei primi anni 2000. Alla BNP facciamo un test ogni 3 settimane in ogni regione ( EMEA, ASIA e AMERICA).
Dipende tutto dai costi che l'azienda é pronta a supportare, il sitarello di e-commerce che fattura 300.000 euro all'anno probabilmente non ha interesse ad accollarsi altri costi di gestione per un DR, chi invece ha i mezzi e omette certe accortezze si merita queste situazioni e dovrebbe licenziare il proprio direttore dei servizi informatici.

[Cfranco]

Mi pare che si faccia un po' di casino tra backup e disaster recovery
Il disaster recovery è una soluzione per evitare un down prolungato dovuto a calamità che colpiscono un data center, costa tanto avere una copia delle macchine in stand by perenne e anche metterlo in piedi e tenerlo pronto non è sempre banale, però in casi estremi permette di rimettere in linea i sistemi in tempi relativamente brevi e senza dover aspettare il ripristino dei danni.
Un backup geografico invece fa in modo che i dati ( e solo quelli ) siano replicati su diversi datacenter, in questo caso il downtime te lo fai tutto, ma hai garanzia che al termine potrai recuperare i dati, il costo è solitamente contenuto e l'implementazione non è diversa da un normale backup.

[canislupus]

Originariamente inviato da Cfranco

Mi pare che si faccia un po' di casino tra backup e disaster recovery
Il disaster recovery è una soluzione per evitare un down prolungato dovuto a calamità che colpiscono un data center, costa tanto avere una copia delle macchine in stand by perenne e anche metterlo in piedi e tenerlo pronto non è sempre banale, però in casi estremi permette di rimettere in linea i sistemi in tempi relativamente brevi e senza dover aspettare il ripristino dei danni.
Un backup geografico invece fa in modo che i dati ( e solo quelli ) siano replicati su diversi datacenter, in questo caso il downtime te lo fai tutto, ma hai garanzia che al termine potrai recuperare i dati, il costo è solitamente contenuto e l'implementazione non è diversa da un normale backup.

Esatto Cfranco... noi abbiamo in azienda copie ridondate in diverse aree geografiche e su diversi supporti (persino i nastri ).
Il Disaster Recovery è ben distante dal sito Online ed è perfettamente identico nella parte hw/sw... per scelte aziendali (avendo una signora linea dedicata) non abbiamo anche la medesima banda... quindi il nostro servizio verrebbe erogato a singhiozzo e comunque con delle forti latenze.

[Rubberick]

Ma, mi domando soprattutto per le dimensioni medio piccole non conviene avere un backup remoto aggiornato di un sistema di vm che possono essere rimesse su in tempi brevi dovessero saltare i server fisici dove le vm originali girano? non è un vero disaster recovery ma mi sembra un ottimo compromesso

[acerbo]

Originariamente inviato da Rubberick

Ma, mi domando soprattutto per le dimensioni medio piccole non conviene avere un backup remoto aggiornato di un sistema di vm che possono essere rimesse su in tempi brevi dovessero saltare i server fisici dove le vm originali girano? non è un vero disaster recovery ma mi sembra un ottimo compromesso

Ormai quasi nessuno ha server fisici, a parte esigenze particolari sono tutte VM.
Il fatto di avere un piano di ripresa che ti permette di switchare i servizi da un DC ad un altro é una cosa che va progettata e implementata per bene ed ha i suoi costi.
Tutte le applicazioni devono essere disegnate per poter funzionare in maniera trasparente da un sito all'altro e ci vuole un meccanismo di failover che dirotta il traffico da una rete ad un'altra, con tutte le configurazioni e i dati replicati in tempo reale. Già il fatto di avere un database sincronizzato da un DC ad un altro comporta tantisssime difficolta. E' una cosa molto piu' semplcie a dirsi che a farsi, paradossalmente é piu' fattibile per piccole realtà rispetto a grandi e complesse infrastrutture. Il "semplice" backup dei dati puoi farlo su un nas ridontato , ma bisogna avere coscienza di quali sono i dati importanti da backuppare e spesso questo nelle piccole/medie aziende si sottovaluta.

[jepessen]

Originariamente inviato da canislupus

Poi c'è da dire una cosa... un disaster recovery RARAMENTE avrà mai le medesime prestazioni di un sistema Online... spesso avrà funzioni molto limitate e dove non fosse possibile operare in tal modo, vi saranno limitazioni a livelli di banda oppure di prestazioni.

Il che e' perfettamente normale. Il piano di disaster recovery deve essere utilizzato, per l'appunto, per riparare ad un disastro di grosse proporzioni, non per i normali backup e restore. Per questo si tengono in genere anche copie locali dei dati, per avere maggiori prestazioni nel caso in cui i backup locali siano disponibili, in genere quando non succede un disastro.

[jepessen]

Originariamente inviato da Rubberick

Ma, mi domando soprattutto per le dimensioni medio piccole non conviene avere un backup remoto aggiornato di un sistema di vm che possono essere rimesse su in tempi brevi dovessero saltare i server fisici dove le vm originali girano? non è un vero disaster recovery ma mi sembra un ottimo compromesso

Intanto in genere non e' una buona idea, lo spazio di una macchina virtuale e' decisamente maggiore di quello occupato 'solamente' dal backup dei dati. Quindi se paghi lo spazio di archiviazione potrebbe non essere una situazione conveniente. Inoltre il backup remoto dove lo metti? Perche' se devi metterlo in un sito a parte allora e' la stessa cosa di mettere i backup dei dati in un sito a parte, non cambia niente. Potrebbe avere senso avere uno snapshot di un server per evitare di dover reinstallare a mano tutti i programmi, nel caso fosse una cosa complessa, da rimettere su nel caso si faccia casini con i programmi, ma fare la stessa cosa anche per i dati non mi pare una mossa intelligentissima.

[fabioss87]

Da come ho letto, zerto si applica ai private host ( quindi soluzioni ben piu costose rispetto alle classiche vps da 5 euro ) in quel caso non vedo ulteriori strumenti per effettuare anche una semplice copia della vm su altra regione. La materia è molto complessa, bisognerebbe leggersi i contratti e capire quei famosi backup che ti fanno pagare dove finiscono. Bhe adesso lo sappiamo, ma erano ridondati su altre regioni?

[mgiammarco]

Siamo sempre alle solite, il marketing cloud di tutti i cloud provider dipinge il cloud come "la perfezione che non si romperà mai" (pensate che da una multinazionale con cui collaboro avevano suggerito di mettere il software che gestisce i macchinari critici in cloud; alla mia domanda "Ma se salta la connessione internet i macchinari che fanno, esplodono?", la risposta del commerciale è stata "ma no internet non salta mai") e adesso si fa il bell'articolo paraculo del tipo "il cloud si rompe come tutto il resto è colpa vostra che dovevate organizzarvi prima".
Beh io allora dico questo (analizzando per lavoro tante offerte SLA cloud ed essendo rivenditore hosting):
1) in quasi nessun contratto è chiaro se è previsto che la macchina riparta su un secondo datacenter in caso di guasto del primo
2) non mi è ancora chiaro come abbiano preso fuoco 4 datacenter come cerini quando ci dovrebbero essere dei sistemi antincendio d'avanguardia e i server e i rack sono generalmente d'acciaio e non di materiali facilmente infiammabili

Perché non fate un articolo che spiega i sistemi antincendio e la propagazione delle fiamme?

[FedericoV]

Concordo con Giammarco, non ci vedo chiaro, va approfondito. Al primo fumo e fuoco dovevano partire i gas, se c’erano, le polveri, o in alternativa l’acqua. I danni normalmente li crea più l’anti incendio, dell’incendio stesso, perché viene spento subito.
Che poi brucino più sale una dopo l’alta, questo è ancora più insolito.
Forse il provider è andato al risparmio (ma le certificazioni, se le aveva, come le ha ottenute?)

Che vi fossero clienti senza DR, purtroppo questo è normale. In tanti pensano che che il Cloud sia magico, ma è solo un altro data center. Il provider poi non fa mai nulla fuori contratto, altrimenti non risulterebbe competitivo.
Diciamo che per i clienti questo è un disastro, ma per i fornitori di infrastruttura on premise, questo è un bel giorno :-)

[giovanni69]

https://edge9.hwupgrade.it/news/clou...ade_97381.html

[igiolo]

Originariamente inviato da mgiammarco

1) in quasi nessun contratto è chiaro se è previsto che la macchina riparta su un secondo datacenter in caso di guasto del primo
2) non mi è ancora chiaro come abbiano preso fuoco 4 datacenter come cerini quando ci dovrebbero essere dei sistemi antincendio d'avanguardia e i server e i rack sono generalmente d'acciaio e non di materiali facilmente infiammabili

Perché non fate un articolo che spiega i sistemi antincendio e la propagazione delle fiamme?

92 minuti di applausi