Gli snapshot + RAID vengono considerati una buona soluzione di backup in loco?


19

I due motivi principali che mi vengono in mente per eseguire i backup sembrano essere risolti quando utilizzo sia le istantanee che il RAID insieme a btrfs. (Per RAID qui, intendo RAID1 o 10)

  • Cancellazione accidentale di dati: le istantanee riguardano questo caso
  • Guasto di un'unità e marcescenza dei bit
    • Errore completo: RAID copre questo caso
    • Unità che restituisce dati errati: la funzione di correzione degli errori RAID + btrfs copre questo caso

Quindi, come soluzione di backup in loco, questo sembra funzionare bene e non ha nemmeno bisogno di un dispositivo di archiviazione dati separato per questo!

Tuttavia, ho sentito che sia RAID che le istantanee non sono considerati backup adeguati, quindi mi chiedo se ho perso qualcosa.

A parte il fatto che btrfs non è ancora una tecnologia matura, riesci a pensare a qualcosa che mi è sfuggito? O il mio pensiero è corretto e questa è una soluzione di backup in loco valida?


2
Facciamo la tua stessa cosa: RAID 5 con Shadow Copy; tuttavia abbiamo anche due dischi rigidi USB fuori sede che eseguono il backup utilizzando Robocopy ogni notte (ruotare le unità due volte a settimana, quindi uno è sempre fuori sede). Questo ci fornisce anche backup per il ripristino di emergenza, ma non archivi a lungo termine , di cui la nostra piccola organizzazione non ha davvero bisogno. Dovresti eseguire l'aggiornamento per avere almeno una copia off-site dei dati sul tuo server come se il tuo array RAID dovesse morire, perderai anche le tue istantanee.
Austin '' Danger '' Powers

Se vuoi scoprire se è possibile che un array RAID fallisca nel suo insieme, colpiscilo con una mazza e prova a recuperare i tuoi dati. C'è un'intera classe di cose cattive che possono estrarre un'intera scatola senza eliminare l'intero sito. Detto questo, se i backup in loco sono solo una comodità che potrebbe salvarti il ​​recupero più lentamente dai backup off-site, in linea di principio possono essere cattivi come desideri.
Steve Jessop,

Sì, disponiamo già di backup off-site e di una soluzione on-site più "tradizionale". Il motivo per cui ho posto questa domanda perché ho letto le caratteristiche di btrfs e ZFS e mi chiedevo se fosse adatto come sostituto dei backup in loco.
小 太郎

Risposte:


42

No non lo è.

Cosa succede quando il tuo filesystem o volume RAID viene danneggiato? O il tuo server viene dato alle fiamme? O qualcuno formatta accidentalmente l'array sbagliato?

Perdi tutti i tuoi dati e i backup non reali che pensavi di avere. Ecco perché i backup reali si trovano su un sistema completamente diverso rispetto ai dati di cui si sta eseguendo il backup, poiché i backup proteggono da qualcosa che accade al sistema in questione e che potrebbe causare la perdita di dati. Mantenere i backup sullo stesso sistema di cui si esegue il backup e la perdita di dati su quel sistema può influire anche sui "backup".


Che ne dici di questa soluzione, dal momento che mi imbatto spesso in essa? Gli snapshot locali + snapshot remoti su un altro server (onsite o offsite) + RAID su entrambi i sistemi sostituiscono i backup tradizionali?
ewwhite

5
@ewwhite Supponendo che siano stati sottoposti a test di ripristino e una copia completa dei tuoi dati esiste su un sistema remoto, certo. Quindi è fondamentalmente un backup da disco a disco ... e adoro i backup da disco a disco.
HopelessN00b

11

Per il backup in loco , lo snapshot potrebbe essere abbastanza buono, a condizione che tu "esporti" regolarmente lo snapshot altrove, dove esiste come dati passivi.

Inoltre, verifica regolarmente se è possibile ripristinare la tua "istantanea spedita".

È così che ho implementato un backup rapido di alcuni dei miei server: archiviare i dati su ZFS, eseguire uno snapshot ZFS, inviare il delta a un altro server, dove viene ricreato l'intero filesystem (meno il servizio in esecuzione).

Naturalmente, il miglior backup è sempre fuori sede. Pertanto, dopo aver "spedito" l'istantanea (e) in un sistema separato, eseguire regolarmente un "tape-out" delle istantanee.

Quindi, nel mio sistema, il server che riceve i delta di istantanee, scarica regolarmente tutti i suoi pool ZFS (comprese le istantanee precedenti) su nastro.

E, naturalmente, prova i tuoi tape-out per assicurarti che possano essere ripristinati.

Nota: si desidera che l'istantanea abbia luogo durante l'attività del disco in pausa e preferibilmente in coordinamento con il database (se presente) per garantire coerenza; altrimenti, la cura potrebbe essere peggiore della malattia. Ecco perché la funzionalità 'live snapshot' di NetApp ed EMC è molto utile: rimanderanno lo snapshot di un LUN fino a quando il database che utilizza il LUN ha indicato che è sicuro eseguire lo snapshot.


Puoi approfondire come scaricare le tue snapshot ZFS su nastro?
ewwhite

@ewwhite puoi sempre fare il backup della .zfs/snapshotsdirectory o montare una delle istantanee da qualche altra parte per fare un tape-out. Quindi è un backup separato per diverse istantanee.
pepoluan

Lo sto facendo con zvols, in realtà ... quindi non ho una directory .zfs da cdinserire.
ewwhite

@ewwhite Ahh, vedo ... in quel caso, potresti essere in grado di usare zfs send $SNAPSHOT_NAME > $YOUR_TAPE_DEVICE, e in seguito fare un zfs receive $RESTORE_NAME < $YOUR_TAPE_DEVICE. Tuttavia, onestamente non ho esperienza con il backup di zvol, però ...
pepoluan

8

Cosa ha detto HopelessN00b. No.

I backup corretti si trovano su un dispositivo separato rispetto al dispositivo sottoposto a backup. Cosa succede quando si perdono due o più unità? Cosa succede quando la stanza del server si esaurisce? Cosa succede quando qualcuno distrugge accidentalmente l'array?

(Avviso aneddoto: una volta ho sentito di qualcuno che aveva PXE impostato per installare automaticamente l'ultima versione di Fedora. Il suo UPS non è riuscito. Dopo un'interruzione di corrente, il suo server si è riavviato ed è stato impostato su avvio PXE e ... ha installato Fedora sui suoi dati. punto? Succedono cose strane. Fortunatamente, aveva backup adeguati.)

Preferibilmente, hai almeno tre copie dei tuoi dati, una memorizzata completamente fuori sede nel caso in cui il data center si esaurisca.


6

Le snapshot correttamente implementate DEVONO essere supportate dall'archiviazione poiché backup decenti le utilizzano come primissima fase di creazione di un processo di backup. È comunque una cattiva idea utilizzare le istantanee per il backup primario. Motivi:

1) Gli snapshot e la memoria back-end NON POSSONO fallire. Quindi i backup reali devono utilizzare un set di mandrini separato o c'è una grande possibilità di perdere contemporaneamente sia il set di lavoro primario sia i dati di backup.

2) Istantanee "masticano" lo spazio utilizzabile. È logico utilizzare l'archiviazione rapida e costosa per gli attuali dati caldi e gli snapshot e i backup off-load che sono dati ghiacciati per uno storage più economico e più lento. Funziona molto bene con 1) BTW.

3) Le istantanee di solito rallentano l'intero processo. La maggior parte dei sistemi utilizza Copy-on-Write e questo approccio crea frammentazione. Il reindirizzamento su scrittura è più veloce ma consuma MOLTO spazio. Pochissimi fornitori hanno implementato correttamente le istantanee. NetApp con WAFL e Nimble Storage con CASL (non sono affiliato con nessuno di essi). Praticamente tutti gli altri hanno problemi. Ad esempio, Dell Equallogic attiva l'aggiornamento della pagina 15 MB (e lo spreco) su ogni singolo byte modificato. È caro.


6

Sì. È un modo perfetto per archiviare i backup. Nient'altro è necessario, diamine, anche fare i controlli di integrità sono solo tempo perso.

Solo per confermare - prima di dare più consigli ... lavori per un mio concorrente, giusto? Lo sai davvero? No? Oh.

Scusa, NUTS. No, per niente. Scusa amico.

Il problema è che sei totalmente aperto a qualsiasi errore che si verifica in (a) il sistema e (b) il livello del sistema operativo. Fondamentalmente proteggi solo contro qualcuno che elimina alcuni dati. Bello. È un errore che si verifica spesso.

Da cosa non stai proteggendo è:

  • Un picco di potenza che cancella la macchina. Ci sono stato, visto quello.
  • Qualche controller raid difettoso o memoria che scrive sh ** sul disco - non c'è niente.

E una lunga lista di altre cose.

Questo è - naturalmente, a meno che tu non lavori per un mio concorrente - per favore fai sempre un backup:

  • Su un altro computer
  • Che si isola da almeno picchi di potenza (anche se si dispone di un USV).

Questo è il motivo per cui i nastri oscillano: non sono collegati e nulla di breve o di fuoco o inondazione non li danneggia. Picco di potenza: arriva il lettore di nastri e forse il robot, ma i nastri non nel lettore non saranno interessati.

BEST sarebbe il backup fuori sede (ho già menzionato cose come il fuoco e le inondazioni?) (Ancora una volta, quando lavori per un concorrente - non esiste un incendio dell'edificio, non è assolutamente necessario, come l'assicurazione antincendio, per favore, risparmia quei soldi).

Ora, potresti pensare "oh, le inondazioni non si verificano mai". Assicurati di esserne sicuro. Vedi, ecco un video di un'inondazione del 09.09.09 di un datacenter di vodaphone. Sono sicuro che capirai dove si trova il problema per un backup interno / nel computer:

http://www.youtube.com/watch?v=ttcQy3bCiiU



4

Lezione imparata da due unità RAID-1 che si guastano entro mezz'ora l'una dall'altra: RAID non è un meccanismo di backup, né forma né forma.

Il RAID è un meccanismo di disponibilità che riduce i tempi di inattività in caso di guasti hardware, ma non ti aiuterà affatto in caso di virus, cancellazione / modifica dei dati o semplice guasto hardware catastrofico.


1
In caso di alcune classi di guasti hardware. Se la scheda RAID non funziona, i contenitori sono spariti.
mfinni,

3

Molti amministratori esperti seguono la cosiddetta regola dei backup 3-2-1:

  • Dovresti avere almeno tre copie dei tuoi dati, inclusa la fonte principale. Vale a dire un singolo backup non è sufficiente e le copie all'interno dello stesso sistema fisico non contano.

  • Dovresti utilizzare almeno due diversi metodi di backup.

  • Dovresti avere almeno una copia fuori sede dei tuoi dati.

Le istantanee violano tutte e tre le parti:

  • Si utilizza solo una singola macchina fisica. Tutto ciò che riguarda l'intera macchina, come un guasto all'alimentatore, potrebbe portare con sé tutti i tuoi dati.

  • Stai utilizzando un solo metodo per i tuoi backup. Se qualcosa non va, lo scoprirai solo quando ripristini il backup in una situazione di crisi.

  • Non hai backup fuori sede. Inondazioni e incendi accadono solo agli altri, finché non accadono a te ...

Perciò:

  • È necessario disporre di almeno un backup su un computer separato sulla LAN.

  • È necessario disporre di almeno un backup che non viene generato utilizzando le istantanee. Forse un buon vecchio tararchivio incrementale potrebbe essere in ordine? O una rsynccopia di base?

  • È necessario disporre di almeno un backup remoto, il più lontano possibile dalla posizione corrente e sicuramente non nello stesso edificio.

Va anche sottolineato che le istantanee a livello di blocco hanno circa le stesse garanzie di coerenza come staccare la spina dalla macchina e quindi copiare sui dischi. In generale, è necessario eseguire fsckun ripristino o sperare che il diario sia sufficiente.

Le istantanee a livello di filesystem dovrebbero essere migliori, ma non garantirebbero comunque la coerenza dei file. Per molte applicazioni (vengono in mente i server di database), copiare i file di un'istanza live può essere completamente inutile, poiché potrebbero trovarsi in uno stato incoerente. Dovresti utilizzare il proprio meccanismo di backup a livello di applicazione per garantire l'esistenza di una copia pulita, per la quale si applicherebbe anche la regola 3-2-1.

Infine, tieni presente che in questo momento stiamo parlando solo di copie dei tuoi dati attuali . Per evitare errori (o violazioni della sicurezza, del resto) che non vengono rilevati per un certo periodo di tempo, è necessario disporre di diverse copie precedenti dei dati per un certo periodo di tempo.


Supponendo che gli snapshot di btrfs siano qualcosa di simile agli snapshot di ZFS in termini di garanzie di coerenza (e con quanta ispirazione btrfs attinge da ZFS, non vedo perché non sarebbe il caso), lo snapshot rappresenterà il momento-in-disco sul disco dati temporali. Quindi il file system sarà in uno stato coerente se si esegue il rollback a un'istantanea, ma se i dati vengono conservati nella RAM e scaricati solo periodicamente e tali dati sono necessari per dare un senso a ciò che è sul disco (vedi software del server di database), quindi quei particolari molto probabilmente i file saranno in uno stato incoerente dopo (o prima!) il rollback.
un CVn

2

Di per sé non è affatto una soluzione di backup . Ridurrà o rimuoverà i tempi di inattività in alcuni scenari di errore, ma non ti protegge affatto da molti altri

Ovviamente può essere una parte molto preziosa di una soluzione di backup + disponibilità più arrotondata:

  • RAID plus snapshot sullo stesso hardware
  • Copie sul sito su altro hardware (ricorda: esistono modalità di errore che eliminano l'intero box, controller, unità e tutto in una volta)
  • Copie remote semi-disconnesse
  • e ovviamente copie offline + offsite appropriate per veri disastri

Inoltre: assicurati di testare regolarmente i tuoi backup. Il momento peggiore per scoprire che i tuoi backup non funzionano è quando devi recuperare qualcosa da loro ...

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.