Best practice per i criteri del piano di backup

Seguire queste best practice ti aiuta a evitare alcuni degli errori più comuni commessi dagli utenti durante la creazione e la modifica dei modelli di criteri.

Devi configurare i modelli di criteri in base ai tuoi scopi di punto di recupero (RPO) e di tempo di recupero (RTO). Nel tempo potresti dover apportare modifiche a questi modelli.

Acquisizione del backup dei dati iniziali

La prima volta che un criterio in un modello di criteri crea un backup dei dati di un'applicazione, esegue il backup dei dati nella loro interezza. I backup successivi saranno incrementali.

Per proteggere più applicazioni con un unico modello di criteri, applica il modello di criteri solo ad alcune delle applicazioni. Al termine della raccolta iniziale completa dei dati, applica il modello di norme ad altre applicazioni. Ripeti la procedura finché il modello di criteri non è stato applicato a tutte le applicazioni.

Ridimensionamento dei volumi

Se redimensioni un volume contenente dati protetti, per alcuni tipi di applicazioni, la volta successiva che viene eseguito il criterio di snapshot per quel volume potrebbe essere eseguita un'operazione di backup completo, indipendentemente dal numero di volte in cui è stato eseguito il backup dei dati del volume in passato. Sono inclusi i file VMDK di VMWare ridimensionati e i backup basati su agenti di applicazioni Microsoft Windows e Linux che non si trovano su LVM.

Se devi ridimensionare un volume per i tipi di applicazioni interessati, valuta l'impatto che l'acquisizione di tutti i dati avrà sui server delle applicazioni, sulla rete e sull'appliance di backup/recupero.

Concorrenza dei job

Per impostazione predefinita, un'appliance di backup/ripristino può eseguire sei job di snapshot contemporaneamente. Se hai pianificato più del numero consentito di job per lo stesso periodo di tempo, lo scheduler dei criteri avvierà il maggior numero di job consentito e inserirà in coda gli altri job.

Poiché la progettazione di rete, il layout dei dati e le classi di archiviazione di ciascun utente sono diversi, sperimenta la concorrenza fino a raggiungere il numero ottimale di job simultanei.

Programmazioni dei criteri

La Console di gestione supporta due metodi per specificare una pianificazione dei criteri durante la configurazione di un criterio:

  • Con finestra. Definisce una pianificazione del backup degli istantanei distinta che rispetta una frequenza e una finestra temporale specifiche (ad esempio, esegui un backup ogni 30 minuti, ogni giorno dalle 09:00 alle 17:00 UTC). Puoi chiedere all'appliance di backup/recupero di eseguire più job di backup a un intervallo di frequenza specificato o una volta in un determinato intervallo di tempo.
  • Continuo. Definisce una pianificazione di backup di snapshot continuo (ad es. eseguire un job di backup ogni otto ore, avviando il primo job alle ore 01:00 UTC). In questa pianificazione delle norme, i job vengono eseguiti continuamente (24 ore su 24, 7 giorni su 7) nell'intervallo di tempo specificato.

Calcolo della frequenza

Il periodo è il tempo che intercorre tra le esecuzioni pianificate e la frequenza è il numero di job eseguiti per unità di tempo. Ad esempio, se una pianificazione prevede l'esecuzione dei job ogni 4 ore, il periodo è di 4 ore e la frequenza prevista è di 6 volte al giorno. Se un job richiede un'ora per il completamento e il criterio ha una frequenza di 12 ore, il job del criterio verrà eseguito di nuovo 11 ore dopo il completamento del job precedente.

Assicurati di selezionare una frequenza che soddisfi gli scopi dei punti di recupero (RPO) richiesti e che consenta tempo sufficiente per il completamento di un job.

  • La frequenza minima consigliata per un criterio snapshot è 1 ora (RPO locale).
  • Un criterio StreamSnap può fare riferimento a qualsiasi criterio Snapshot con frequenza di almeno 1 ora (RPO remoto).

Protezione dei log del database in un criterio del piano di backup

Quando crei un criterio di istantanea per un database, hai la possibilità di acquisire anche i relativi file di log con una frequenza specificata. La frequenza con cui vengono acquisiti i log del database è definita separatamente da quella del database. Ad esempio, un database può essere acquisito ogni giorno e i relativi log ogni ora.

La frequenza del backup dei log del database è impostata in minuti e la frequenza con cui vengono acquisiti i log non deve superare quella con cui viene acquisito il database associato. Ad esempio, se la frequenza di acquisizione di un database è ogni 24 ore, la frequenza di acquisizione dei file di log deve essere inferiore a ogni 24 ore.

La frequenza e la conservazione sono definite nelle impostazioni avanzate del criterio di snapshot del database. L'acquisizione dei log viene eseguita senza tenere conto dei limiti di giorno, della finestra o della frequenza con cui viene acquisito il database associato.

La funzionalità di protezione dei log viene attivata tramite le impostazioni avanzate Attiva il backup dei log del database in un criterio di snapshot del piano di backup. La frequenza e la conservazione sono definite anche nelle impostazioni avanzate per un criterio del piano di backup.

Lo spazio fisico necessario per ospitare i log di un database viene gestito automaticamente dalla console di gestione. Come minimo, la Console di amministrazione valuterà le dimensioni dei log tipici e il relativo periodo di conservazione e aggiungerà spazio in base alle esigenze.

Per attivare il backup dei log e gestire in modo più efficiente i requisiti di archiviazione per i log del database, consulta questa tabella.

Impostazione Input
Troncare o eliminare il log dopo il backup Deve essere impostato su Sì per svuotare il log di produzione. Seleziona questa opzione per gestire l'eliminazione dei log. Verrà eseguita l'eliminazione dei log alla fine di ogni backup dei log. Il valore predefinito è Non troncare.

Se un criterio con Attiva il backup dei log del database è impostato su No, e se Tronca o elimina i log dopo il backup è impostato su Sì, l'eliminazione dei log viene eseguita al termine di ogni backup del database, eliminando tutti i log.
Periodo di conservazione del backup dei log Il backup dei log nel disco di staging di Backup e RE verrà conservato fino al valore impostato qui. La conservazione dei log di backup può essere diversa dalla conservazione degli istantanei.
Registrare le dimensioni della crescita del disco di staging Imposta una percentuale in base alla quale aumentare il disco di staging del backup dei log, se necessario.
Tasso di variazione stimato Stimare la percentuale di variazione giornaliera dei dati del database.
Comprimi il backup dei log del database Utilizzalo per consentire l'esecuzione del backup dei log del database in modalità compressa utilizzando l'API di database a livello di app.
Attivare il backup dei log di database L'opzione Abilita il backup dei log del database consente al criterio del piano di backup di eseguire il backup di un database e di tutti i file di log associati. Il backup dei log viene eseguito quando viene eseguito il job di backup dei log. Le opzioni sono Sì o No. Se impostato su Sì, le opzioni correlate vengono attivate.
RPO Quando l'opzione Abilita il backup dei log di database è impostata su Sì, l'RPO definisce la frequenza del backup dei log di database. La frequenza è impostata in minuti e non deve superare l'intervallo di backup del database.
Eseguire la replica dei log (Utilizza la tecnologia StreamSnap) Se l'opzione Attiva il backup dei log del database è impostata su Attiva, l'impostazione avanzata Replica i log consente di replicare i backup dei log del database in un'appliance di backup/recupero remoto. Affinché un job di replica del backup dei log venga eseguito, nel modello deve essere incluso un criterio di replica StreamSnap insieme a un profilo della risorsa che specifica un'appliance di backup/recupero remoto e deve essere completata almeno una replica riuscita del database. Puoi quindi utilizzare il backup del log sul sito remoto per qualsiasi immagine del database all'interno dell'intervallo di conservazione del backup del log replicato. Questa funzione è attiva per impostazione predefinita.

La replica dei log utilizza la tecnologia StreamSnap per eseguire la replica tra le appliance di backup/ripristino locale e remota; la replica dei log passa direttamente dal pool di snapshot locale al pool di snapshot sull'appliance remota.

Nota: la replica dei log non avviene finché il database non è stato protetto e l'immagine di backup del database non è stata replicata nell'appliance di backup/ripristino remota.
Inviare i log al pool OnVault Se impostato su Sì, i log verranno replicati in uno o più pool di archiviazione OnVault consentendo i ripristini in un determinato momento da un pool OnVault su un altro sito.

Priorità e pianificazione dei job

Tutte le attività vengono eseguite come job. I job vengono eseguiti in base alle pianificazioni configurate al momento della creazione dei criteri.

Alcuni lavori richiedono molto più tempo di altri. I job di scadenza sono rapidi. I job di snapshot dipendono da variabili come le dimensioni dell'applicazione o della VM e la quantità di dati modificati dall'ultimo snapshot. Lo snapshot iniziale di qualsiasi applicazione o VM contiene tutti i dati nuovi, pertanto questi job possono richiedere molto tempo.

Il programmatore dei criteri identifica quando devono essere eseguiti uno o più criteri applicati alle applicazioni e avvia un job che inserisce il criterio in una coda quando si verifica l'ora di inizio pianificata. Per ogni tipo di criterio è presente un meccanismo di pacing per garantire che il sistema non sia sopraffatto dai job in esecuzione. Questo meccanismo di pacing utilizza gli slot di job per raggiungere questo stato stabile, il che significa che anche se un job dovrebbe iniziare in un determinato momento, verrà eseguito solo quando è disponibile uno slot di job.

Se è pianificata l'esecuzione di più applicazioni contemporaneamente con la stessa priorità del job, la selezione dell'applicazione da eseguire è randomizzata per garantire l'equità tra tutte le applicazioni che hanno la stessa priorità.

Nuovi tentativi di esecuzione del job

Quando un job non va a buon fine, lo scheduler tenta automaticamente di eseguirlo di nuovo. La prima volta che il job non va a buon fine, lo scheduler attenderà 4 minuti prima di metterlo a disposizione per il nuovo tentativo. Dopo 3 tentativi di esecuzione non riusciti, il job viene contrassegnato come non riuscito e non vengono più effettuati nuovi tentativi. Verrà eseguito un tentativo per il job successivo in base alla pianificazione del criterio.

Lo scheduler tratterà un nuovo tentativo di un job come qualsiasi altro job disponibile. Se sono disponibili più job rispetto agli slot per ospitarli, i job vengono messi in coda. Ciò potrebbe comportare la mancata attivazione di un nuovo tentativo di esecuzione all'interno della finestra e il job potrebbe essere contrassegnato come non riuscito.

I tentativi di ripetizione dei job vengono registrati in Monitor. Per identificare i tentativi di ripetizione dei job, il monitor aggiunge prima a, poi b e infine c al nome di ogni job di ripetizione.

Passaggi successivi