Fai finta per un momento che sia successo qualcosa di catastrofico; sei stato violato e il tuo database di produzione diventa un disastro.
Fino a che punto (tempo) dovresti ottenere dal tuo ultimo backup e riprendere le normali operazioni?
Naturalmente, "immediatamente" è "ideale", ma mi piacerebbe vedere alcune risposte reali. Forse alcune situazioni reali della vita reale in cui ti trovi attualmente riguardo ai backup.
Per i database, dovrebbe essere banale implementare il backup più recente. È puramente una questione di quanto grande è il tuo database, quanto a quanto tempo ci vuole per ripristinare. Se si tratta di un enorme database, potrebbero essere necessarie ore, ma questa è la vita. Se ai padroni non piace, possono spuntare per un secondo server.
Se hai avuto una vera catastrofe, dovresti essere in grado di raggiungere il backup fuori sede in non più di un'ora. Se impiega più tempo, potresti volere una nuova strategia offsite.
Se si tratta di un hack, piuttosto che un problema hardware, è più importante (e richiede tempo) per essere sicuro di non essere nuovamente hackerato. Questo è il crollo del tempo. Identifica come ti hanno preso e chiudi il buco. Se non lo fai, allora stai solo perdendo tempo.
Per le basi di codice, dovresti essere in grado di distribuirlo in modo estremamente rapido. Dovrebbe essere solo questione di ridistribuire il codice di produzione, che, si spera, è automatico o vicino ad esso. Se la distribuzione è in gran parte manuale, fai qualcosa al riguardo. Una volta ho trattato questo pessimo pacchetto .Net che era tutte le DLL che dovevano essere registrate manualmente, e non tutte sono state salvate nello stesso posto. Nightmare.
La cosa più importante da fare è praticare. Porta la tua gente nel weekend e fai una ricostruzione in metallo. Poi portali in un bar per una critica. Tutti dovrebbero sapere dov'è tutto, qual è il piano e quale è la loro parte nel piano. Se devi prendere una decisione durante una crisi, hai fallito. Dovrebbe essere automatico.
I'm asking how long it should take to restore to a backup.
Questa è in realtà una questione politica, perché più è breve il tempo che più denaro avrà un costo.
Se la tua azienda non può permettersi tempi di inattività, è necessario pianificare di conseguenza e disporre di hot spare (computer avviati, pronti a subentrare). Può trattarsi di macchine fisiche o istanze di vmware "altrove".
Se puoi permetterti un tempo di inattività di un'ora, puoi eseguire vmware all'interno dei tuoi server e avere istantanee regolari che potrai poi ripristinare in un altro host vmware e continuare.
Se puoi permetterti un tempo di inattività di 8 ore, puoi eseguire il ripristino dal nastro a un disco freddo.
Se puoi permetterti un periodo di inattività di 24 ore, puoi recuperare il nastro da un'altra posizione fisica e acquistare un nuovo computer da reinstallare.
Si noti inoltre che i backup devono essere recenti affinché funzioni. Ciò richiede di nuovo una buona pianificazione per garantire che siano sempre sufficienti.
E fai esercitazioni antincendio se è importante per la tua attività, dovresti fare pratica per assicurarti di poterlo fare correttamente quando si verifica un disastro.
Dipende da quanti soldi la società sarà fuori dal sistema che non è disponibile. In alcune aziende grandi o mission critical ... non puoi andare giù. Là deve essere un piano di failover o multipli. Non posso davvero parlarne, ma sono sicuro che alcune persone su serverfault possono (probabilmente questa domanda farebbe molto meglio).
Tuttavia, posso parlare con una società più piccola e con budget limitato. Ho lavorato per (piccole, 10 persone) società alcuni anni fa e per noi era 2 ore fino a quando il normale ordine di lavoro era considerato dalla direzione ragionevole, e il backup non era generalmente mai più di 4 ore. Più a lungo, o più indietro per il backup, poi la società ha iniziato a perdere denaro. Mantenere i backup che si sono verificati più spesso di così costerebbe più della perdita.
In questo caso, dipendeva anche da quale backup: on-site o off.
I backup del sito non duravano più e venivano eseguiti meno frequentemente (una volta al giorno, ogni notte), ma erano disponibili solo se l'edificio prendeva fuoco o qualcosa del genere. Non abbiamo mai dovuto usarli, per fortuna, e ho dimenticato quale fosse il limite di tempo per il backup e la corsa - ma era certamente nell'ordine dei giorni, se ricordo.
I backup del sito erano solo discariche dei datastore (s) e delle cartelle condivise sul server. Tornando online significava il ripristino dei dati su una macchina diversa in ufficio (la mia macchina di sviluppo in realtà ... avevamo un budget) fino a quando il server non veniva riparato - questo in genere richiedeva 15 minuti al massimo. Le persone potrebbero continuare a lavorare. Dopo che il server è stato riparato, il "sistema" è stato portato offline mentre i dati sono stati scaricati dalla mia macchina, sottoposti a backup e ripristinati sul server. Il server è stato quindi riportato online e siamo pronti per partire. Di solito ci sono voluti 30-40 minuti (dopo che il server era stato riparato). Questo è successo due volte nei 2 anni in cui ero lì. Una volta era un problema di riscaldamento nell'armadio del server, e abbiamo aspettato che l'A / C venisse corretto.
Un server in standby è sempre la scelta migliore e continua a passare da master a standby come operazione settimanale / mensile per garantire che non vi siano ostacoli (come la modalità standby, ad esempio, il carico di punta del sito non è sufficiente). .
Se stai per registrare, è molto importante testare spesso perché gli schemi cambiano / gli sviluppatori dimenticano le cose e lo è, devi scrivere un codice che analizzerà e migra da vecchi dati invece che da un ripristino diretto. Questa è la situazione peggiore.
Leggi altre domande sui tag backups