Troppo spesso vedo persone che fanno domande sulle strategie di backup che dovrebbero utilizzare per i loro database. Non sembra mai fallire, ogni domanda di questo tipo che mi sono imbattuto in una varietà di forum non include mai una volta i loro requisiti di ripristino. Sono stato spesso perplesso per aver considerato i tuoi requisiti di ripristino prima di progettare la tua strategia di backup. Quando viene premuto per i requisiti, ricevo spesso requisiti di backup, ad esempio:
- I backup non devono comportare tempi di inattività
- Necessità di poter eseguire il backup dei registri di ripristino archiviati
- I backup devono essere scritti su nastro
Questi requisiti vanno bene, ma secondo me non dovresti mai progettare la tua strategia di backup senza prima documentare i tuoi requisiti di ripristino e ottenere l'occorrenza di gestione.
Quindi ecco alcune domande che mi pongo durante la progettazione di una strategia di backup. Nota che queste domande sono tutte incentrate sul lato del recupero delle cose.
- Quanta perdita di dati posso permettermi quando ripristino il database? Zero perdita di dati? È accettabile un'ora di perdita di dati dopo il ripristino del database?
- Devo eseguire il rollforward delle transazioni, ad esempio eseguire un ripristino point-in-time?
- Dovrò ripristinare il contenuto di uno schema lasciando intatti gli altri schemi?
- Quanto tempo ho per rendere operativo il database dopo un errore?
- Da che tipo di guasti devo recuperare? Ovviamente, devo essere in grado di eseguire il ripristino da un guasto completo del server o dalla perdita di un disco. Ma devo essere in grado di recuperare da errori umani come qualcuno che ha eliminato accidentalmente una tabella?
- Mi verrà richiesto di ripristinare il backup su altri server come parte dell'aggiornamento dello sviluppo o del test dei database da una copia di produzione?
Se chiedi alla maggior parte delle persone nella comunità Oracle in questi giorni, ti diranno di utilizzare RMAN per eseguire il backup del database. RMAN è un ottimo prodotto e per molte cose è migliore dei vecchi backup a caldo o a freddo gestiti dall'utente. Alcuni DBA Oracle ti diranno di utilizzare RMAN per eseguire backup a caldo ed eseguire il database di produzione in modalità registro archivio. In questo modo, coprirai molti degli scenari di ripristino che probabilmente dovrai affrontare. Ma cosa succede se la tua risposta alla domanda 4 è che hai 1 ora per tornare operativo e il tuo database ha una dimensione di 10 TB. Buona fortuna nel tentativo di eseguire un ripristino completo di un database da 10 TB in 1 ora con RMAN. E RMAN non sarà in grado di aiutare con la domanda 3 poiché RMAN non esegue il backup a livello di schema.
Ci sono molti strumenti a disposizione del DBA per il backup e il ripristino dei dati nel database. Questi strumenti includono, ma non sono limitati a:
- Recupero di Oracle's Recovery Manager (RMAN)
- Backup gestiti dagli utenti Oracle
- Esportazione/importazione Oracle o Data Pump
- Istantanee basate su disco
- Replica basata su disco
- Data Guard di Oracle
Allora quale usi? Beh, ognuno ha i suoi pro e contro. Una volta che conosci i tuoi requisiti di ripristino, gli strumenti per eseguire il backup del database iniziano a diventare più chiari. E potrebbe essere necessario utilizzare più di uno strumento di backup per soddisfare tutti i requisiti di ripristino. Se usi, come qualche suggerimento, RMAN con la modalità Registro archivio e nient'altro, e il tuo manager viene da te e dice "è necessario ripristinare e far funzionare questo database da 10 TB in 1 ora!" il tuo lavoro potrebbe essere in gioco.
Il che porta al punto successivo, documentare i requisiti di ripristino e inserirli nel contratto di servizio (SLA). Durante la scrittura e la verifica dello SLA, la tua direzione potrebbe dire di volere una perdita di dati pari a zero. È in questo momento che puoi esporre i pro e i contro dell'implementazione di una soluzione a perdita di dati zero... e menzionare anche i costi! Molte aziende rifiutano l'alto costo di una soluzione a perdita di dati zero, ma per altre aziende il costo è piccolo rispetto all'onere finanziario della perdita di qualsiasi transazione. È qui che entrano in gioco la contrattazione e il baratto. Se la direzione insiste su una soluzione a perdita di dati zero, allora deve trovare i fondi per supportarla perché RMAN (gratuito) non la fornirà. Dopo aver documentato i requisiti di ripristino nello SLA, sarà difficile per la direzione chiederti di ripristinare qualcosa che la tua strategia di backup non è progettata per supportare. Se lo SLA è in vigore e ti chiedono di recuperare ogni singola transazione e la tua strategia di backup non lo consente, allora hai un documento che dice che non è mai stata richiesta nessuna perdita di dati e questo può aiutarti a salvare il tuo lavoro.
Detto questo, una volta che i requisiti di ripristino sono documentati nello SLA, assicurati che la tua strategia di backup ti consenta di eseguire ogni scenario di ripristino documentato nello SLA. Il tuo lavoro potrebbe dipendere da questo. Se lo SLA dice zero perdita di dati e tu non implementi Data Guard anche se la direzione era disposta a finanziarlo, allora potrebbero licenziarti perché non stavi portando a termine il tuo lavoro.
Infine, nessuna strategia di backup/ripristino è completa a meno che non sia stata testata a fondo. Dovresti testare ogni strategia di ripristino richiesta per assicurarti di poter soddisfare tutti i requisiti indicati nello SLA. I test devono essere eseguiti almeno una volta all'anno per due motivi... uno, assicura che le modifiche al sistema non influiscano negativamente sulla tua capacità di eseguire un ripristino richiesto e due, ti tiene aggiornato su come eseguire il ripristino in modo che se devi farlo sul serio, non stai armeggiando per la procedura. Durante i test, potresti scoprire che la tua metodologia di backup supporterà gli scenari di ripristino richiesti, ma è bello avere se ne hai bisogno.
E non posso dirlo abbastanza... Prova, prova e prova!
