Ho ancora bisogno di un backup se ho un sistema di archiviazione ridondante con funzionalità di rollback?


32

La mia organizzazione ha recentemente acquistato un sistema di archiviazione. Ha 1.5Petabyte, con RAID6, e c'è un mirror sincronizzato online in una posizione fisica diversa.

Il sistema consente il ripristino di rollback / file, per impostazione predefinita consentendo fino a 30 giorni, ma questo può essere aumentato.

È in corso una discussione se abbiamo bisogno di una sorta di backup aggiuntivo per i dati che vivono solo nella memoria.

Il sistema ha un ottimo livello di ridondanza, ha ridondanza geografica e consente un certo rollback, il che significa che possiamo recuperare fino al tempo definito (30 giorni per impostazione predefinita) o vecchi dati cancellati accidentalmente.

Dato questo scenario ha ancora senso avere un backup "tradizionale"? Per tradizionale, intendo un sistema di backup dedicato, con istantanee che possiamo recuperare nel caso qualcosa vada storto.

Ne abbiamo veramente bisogno? Mi sto perdendo qualcosa? Sto solo pensando in modo tradizionale ed essendo troppo zelante?


Se ti consente anche di replicare le istantanee su un altro dispositivo, puoi superare i problemi menzionati da Sven nella sua risposta.
Drifter104,

4
Decisamente correlato, ma forse non completamente duplicato a causa della separazione geografica e della capacità di rollback dell'istantanea: Perché RAID non è un backup?
un CVn

Finché rimuovi anche il tasto "cancella" da ogni tastiera del posto, sei d'oro ;-)
Tom Newton,

1
Certamente meglio di non averlo. Preferirei comunque che i backup vivessero su un supporto lontano da "errori di persone". Tuttavia, conosci la risposta alla tua domanda, ma comporta la fissazione di un prezzo per i tuoi dati. In bocca al lupo.
Tom Newton,

7
La tua funzionalità di "rollback" copre anche le modifiche ai volumi? Ad esempio, sarà in grado di recuperare se qualcuno rimuove tutti i volumi?
Vhu

Risposte:


40

Quello che descrivi è essenziale un RAID distribuito geograficamente e un RAID non è mai stato un backup .

La sincronizzazione online di solito significa che tutto ciò che fai sulla memoria principale viene immediatamente replicato nel sistema di backup, comprese operazioni come la cancellazione di (tutti) gli snapshot e / o dei volumi da parte di un utente malintenzionato o semplicemente un errore di amministrazione.


3
Oppure, poiché entrambi gli archivi probabilmente utilizzano lo stesso sistema operativo, un bug del software potrebbe distruggere i dati. Non probabile, un errore di amministrazione è più probabile, ma possibile.
Sunzi,

8
Vero. L'obiettivo è che nessuno sarà in grado di gestire le istantanee automatizzate. Ciò dovrebbe dare il livello di resilienza contro gli errori. Naturalmente si può anche cancellare un backup per errore.
nn il

2
@nsn ci sono molti altri errori correlati come bug nel software del dispositivo o bug negli script di gestione. Senza un backup da qualche altra parte stai affidando il tuo lavoro al fornitore ... Sei disposto a farlo? Quantificare anche il danno in caso di perdita. Forse la risposta dipende da quanto siano preziosi i dati. La società se n'è andata senza di essa?
usr

2
@ nsn > Naturalmente si può anche cancellare un backup per errore. < - Sì, ma diventa sostanzialmente più difficile quando il backup viene portato offline e collocato in un archivio sicuro fuori sede, ad esempio.
Rob Moir,

7

Il rollback di 30 giorni è una grande capacità, ma cosa succede se "criticamente-importante-file-xyz" diventa corrotto / danneggiato e questo non viene rilevato fino a più di 31 giorni dopo? Questa situazione è la differenza tra i piani di backup e di archiviazione, ma nella descrizione non viene menzionato quest'ultimo. I sistemi di archiviazione sono generalmente archiviati su nastro a costi molto bassi. Inoltre, non sono disponibili informazioni sul fatto che l'azienda abbia requisiti normativi o di altro tipo per conservare i dati per più di 30 giorni, come spesso accade.

Se questo non è il caso della tua situazione, allora dovresti essere bravo.


3
Sì vero. Il 30 è solo il valore predefinito che possiamo impostare altri valori. Comunque, anche l'archiviazione offline costa e non si attacca per sempre. Ci sarà sempre un giorno n + 1
nsn

2
Mi piace avere un periodo di 30 giorni, più mensili per l'ultimo anno, più un anno. Ho avuto un certo numero di file (importanti e vecchi) che svaniscono e non vengono rilevati nel periodo di tempo di rotazione. I backup annuali possono essere salvavita.
Brian Knoblauch,

@BrianKnoblauch: Sì, questo tipo di schema è una buona idea, sia per le istantanee online che per i backup offline.
Ben Voigt,

6

Avere macchine geograficamente separate entrambe con i dati è buono.

Cosa succede quando si verificano più errori che coinvolgono entrambi o tutti i siti? Un incendio in uno, il furto dei server nell'altro? Oppure c'è un problema con la linea tra di loro, quindi il server della posizione principale si spegne e il controller HD diventa scimmia e scrive spazzatura? O qualche insider compie azioni dannose su entrambi? Oppure l'FBI confisca i tuoi server in entrambe le posizioni a causa di sospetti (non lo faresti mai, ma forse sei co-ospitato in un datacenter con schmucks). Oppure ... mi vengono in mente diverse interruzioni "cloud" di alto profilo in cui tutto era ridondante, analizzato all'ennesima potenza, ma, tuttavia, le cose possono andare storte. Ti garantirò che sono tutti improbabili, ma hai riconosciuto che possono accadere cose improbabili.

Quindi, dipende da quanto sono importanti / preziosi questi dati? Cosa farà l'organizzazione se finirà?


3
Se hai due posizioni e perdi entrambe, probabilmente hai perso anche i tuoi backup. La maggior parte di questa risposta è un argomento per la replica su più di due siti, non un argomento a favore del backup.
Ben

2
Questo va per sempre. Ogni volta che si aggiunge un livello di ridondanza, ci si può sempre aspettare che fallisca (sia geografico, sia solo dischi). Se hai n dischi ridondanti puoi sempre chiedere "cosa succede se n + 1 si rompe". Puoi avere un incendio nella tua sala server e anche nella tua stanza di backup. Un lavoro interno può anche attaccare entrambi. Non ci sono sistemi sicuri al 100%. La cosa qui è sapere se tale configurazione può essere equivalente a un server "tradizionale" + backup
nsn

1
Penso che @nsn sia un ottimo punto, ma penso anche che la lezione da molte di queste risposte sia che avere il tuo backup esistente su un'infrastruttura tecnologica separata dai tuoi supporti di archiviazione sia una buona idea, perché rende molto più difficile per un incapacità di propagarsi e più difficile per un attore malintenzionato infettare entrambi (ma semplicemente più difficile). Vediamo regolarmente bug nei sistemi ridondanti che causano guasti a cascata. Avere una soluzione / fornitore diversi coinvolti aiuta. Questa copertura continua ancora, ma considero quel livello di separazione tecnologica come ragionevole precauzione nella maggior parte dei casi.
Nick,

@Nick, penso che tu abbia un commento molto valido. Darei una risposta.
nn

4

La domanda qui sembra essere quanto sia disconnessa e geograficamente distinta una copia replicata dei tuoi dati prima che sia un'infrastruttura di backup e non di elevata disponibilità / ridondanza. Il mio istinto è che sei vicino, ma hai ancora bisogno di un backup.

Per riunire (scegliere la ciliegia) alcuni pensieri nelle altre risposte e commenti, puoi andare molto lontano lungo il percorso di "beh, la tecnologia X non copre lo scenario di disastro Y, quindi non è un backup" e ad un certo punto devi decidere cosa è ragionevole per te, che sembra essere il motivo per cui lo stai chiedendo. La mia opinione su questo, e penso che quella di molti dei commentatori, è che il backup deve esistere su un'infrastruttura tecnologica separata dai dati in uso in modo che guasti, incidenti e azioni dannose non possano propagarsi o avere un ostacolo molto più alto da attraversare. Un esempio dato nei commenti è qualcuno che cancella i volumi, che secondo me è uno scenario valido, non pie-in-the-sky. Ma inoltre, un esempio del mondo reale dal mio lavoro. L'università per cui lavoro (ma per fortuna non Gestire questa infrastruttura per) ha alcune infrastrutture di virtualizzazione ad alta disponibilità che supportano molte strutture del campus. È su più siti, ma è tutto in esecuzione sulla piattaforma di un fornitore. Un oscuro bug è apparso un giorno che ha causato un errore a cascata che prima ha rimosso un singolo server, quindi quando il carico è stato spostato, ha eliminato il resto di quel sito e quindi quando il carico è stato spostato di nuovo, ha eliminato gli altri siti di hosting quell'infrastruttura. (Credo che abbiano risolto questo problema da allora). I dati non sono stati persi in questo caso, ma è possibile immaginare uno scenario che coinvolga i dati dove si trovavano. Un oscuro bug è apparso un giorno che ha causato un errore a cascata che prima ha rimosso un singolo server, quindi quando il carico è stato spostato, ha eliminato il resto di quel sito e quindi quando il carico è stato spostato di nuovo, ha eliminato gli altri siti di hosting quell'infrastruttura. (Credo che abbiano risolto questo problema da allora). I dati non sono stati persi in questo caso, ma è possibile immaginare uno scenario che coinvolga i dati dove si trovavano. Un oscuro bug è apparso un giorno che ha causato un errore a cascata che prima ha rimosso un singolo server, quindi quando il carico è stato spostato, ha eliminato il resto di quel sito e quindi quando il carico è stato spostato di nuovo, ha eliminato gli altri siti di hosting quell'infrastruttura. (Credo che abbiano risolto questo problema da allora). I dati non sono stati persi in questo caso, ma è possibile immaginare uno scenario che coinvolga i dati dove si trovavano.

Volete che il vostro backup sia immune da tutto ciò, e persino accessibile mentre l'infrastruttura è inattiva. Se i dati non sono disponibili per una settimana durante la ricostruzione del RAID, è bello poter ripristinare i documenti aziendali critici dal backup (anche se non richiesto). Se il tuo RAID scompare, quindi si replica sull'altro tuo sito, vorrai davvero che il backup provenga da un fornitore separato o su alcuni supporti isolati come il nastro.

Detto questo, ripeterò nuovamente che il backup dovrebbe essere su un'infrastruttura separata dai dati. Ci sono molti livelli di isolamento qui, ma penso che tutto ciò che è collegato tramite la replica diretta sia troppo vicino per essere un backup. Avrai bisogno di qualcosa in più.


1

Presupposto: il sistema di archiviazione verrà utilizzato da molte applicazioni.

Ritengo che farai molto meglio con un sistema di backup separato.

RAID e mirroring non sono backup ma la funzionalità di rollback integrata può sostituire un sistema di backup tradizionale.

MA:

Preferisco che i criteri di recupero siano basati su applicazioni / dati e non basati su archiviazione perché:

  1. le applicazioni presentano requisiti diversi relativi al recupero e alla perdita accettabile di dati (alcuni imposti da varie normative: supporti di sola lettura, crittografia, conservazione degli ultimi X anni, ecc.),
  2. alcune applicazioni hanno (molto) buoni strumenti di backup e ripristino (oracle, mssql) e sono un modo consigliato per fare la parte di backup / ripristino (come Oracle DBA, preferisco e farò tutti i miei backup relativi a Oracle con rman).
  3. crescita, l'utilizzo dello spazio può crescere molto più rapidamente di quanto ti aspetti, ora questo sistema può contenere 30 giorni di dati di rollback, questo non è garantito in futuro
  4. più economico, il costo dell'utilizzo di nastri più grandi per adattarsi alle politiche di backup / ripristino, dopo diversi anni di crescita, sarà inferiore rispetto al costo di acquisto di nuovi dischi più grandi per rispettare la stessa finestra di rollback di oggi
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.