Piani di backup nella console di gestione

I piani di backup sono le regole utilizzate dalla Console di gestione per definire la frequenza con cui eseguire il backup dei dati dell'applicazione, il periodo di conservazione dei backup dei dati dell'applicazione e dove e come replicare i backup dei dati dell'applicazione. Utilizza i piani di backup per creare modelli di criteri e profili delle risorse che ogni appliance di backup/recupero utilizza per gestire i dati. Una violazione dei piani di backup si verifica quando il backup dei dati non viene eseguito in base ai limiti impostati in un criterio.

La scheda Piani di backup fornisce due procedure guidate facili da usare per creare criteri di gestione dei dati da applicare alle applicazioni:

  • Modelli. Utilizza la procedura guidata Modelli per controllare la frequenza e la conservazione dei dati. Ti consente inoltre di eseguire il tiering dei dati e la loro replica. Per ulteriori informazioni, consulta la sezione Modello di backup.
  • Profili. Utilizza la procedura guidata Profili per controllare la posizione fisica e i pool di archiviazione in cui vengono archiviati i dati. Per ulteriori informazioni, consulta la sezione Profili delle risorse.

Consulta la sezione Best practice per i piani di backup per evitare alcuni degli errori più comuni che gli utenti commettono durante la creazione e la modifica dei modelli di criteri e dei relativi criteri associati.

Nuovi tentativi del job di backup

Quando un job pianificato non va a buon fine, lo scheduler riprova automaticamente fino a tre volte. La prima volta che un job non va a buon fine, lo stato del primo tentativo verrà contrassegnato come Ritentato e lo scheduler attenderà 4 minuti prima di inserire nuovamente il job in coda. Se il tentativo non va a buon fine una seconda volta, il nuovo tentativo viene messo in coda dopo 16 minuti. Se non va a buon fine per la terza volta, viene inserito in coda un ultimo tentativo dopo un periodo di attesa di 64 minuti. Dopo 3 tentativi di nuovo tentativo non riusciti (per un totale di quattro tentativi), lo stato del job di nuovo tentativo finale cambia da Nuovo tentativo a Non riuscito e non vengono tentati altri job per l'applicazione nel periodo di pianificazione.

Lo scheduler tratta un nuovo tentativo di un job come qualsiasi altro job disponibile. Se esistono più job in coda rispetto agli slot disponibili, il job di ripetizione in coda dovrà attendere uno slot. Se la finestra dei criteri si chiude prima che un job di ripetizione possa essere avviato, tutti i job di ripetizione in coda non verranno eseguiti e non verranno tentati ulteriori tentativi.

I tentativi di ripetizione dei job vengono registrati in Monitor > Job. Per identificare i tentativi di nuovo caricamento del job, tutti e quattro i job avranno lo stesso numero Job nel seguente formato, nell'ordine seguente:

  • Job_xxxxx (stato: riprovato)
  • Job_xxxxxa (stato: Ritentato; in coda dopo una sospensione di 4 minuti)
  • Job_xxxxxb (stato: Ritentato; in coda dopo un'attesa di 16 minuti)
  • Job_xxxxxc (stato: Non riuscito; in coda dopo una sospensione di 64 minuti)

La volta successiva che verrà tentato di eseguire un job di backup per questa applicazione, il job verrà eseguito in base alla pianificazione delle norme. Pertanto, se la pianificazione prevede uno snapshot al giorno in una finestra che inizia alle 01:00, il prossimo tentativo sarà il giorno successivo alle 01:00.

Modello di backup

Un modello di backup è una raccolta di criteri definiti nei piani di backup. Ogni criterio definisce la modalità di backup dei dati, la frequenza con cui viene eseguito il backup e il periodo di conservazione. Nello specifico, i criteri definiscono quanto segue:

  • I tipi di operazioni di backup dei dati (ad es. snapshot, replica)
  • La frequenza dell'operazione di backup dei dati dell'applicazione
  • Per quanto tempo conservare i backup dei dati dell'applicazione
  • Le impostazioni avanzate relative all'operazione di backup dei dati dell'applicazione
  • Indica se troncare i log. Gli aggiornamenti ai database come Microsoft SQL Server e Oracle sono accompagnati dalla creazione di log e metadati. I log spiegano le modifiche apportate ai database.
  • Dove vengono conservati i dati di backup (appliance di backup/ripristino locale, appliance di backup/ripristino remoto o posizione di archiviazione OnVault)

Combinando i criteri all'interno di un modello, puoi creare un singolo modello che definisce la conservazione a breve e lungo termine dei dati, nonché la posizione in cui verranno conservati e la durata della conservazione dei dati replicati.

Profili delle risorse

Un profilo di risorsa specifica i supporti di archiviazione per i dati protetti delle applicazioni e delle VM. Il criterio e il profilo della risorsa che compongono il piano di backup determinano il tipo di backup dei dati dell'applicazione da eseguire e dove archiviarli (quale pool di dischi può essere utilizzato). I profili delle risorse definiscono il pool di snapshot (se necessario) utilizzato o in cui vengono replicati i dati dell'appliance remota.

Oltre ai modelli e ai criteri, nei piani di backup crei anche profili di risorse. I profili di risorse definiscono dove archiviare i dati. I dati possono essere memorizzati nei seguenti modi:

  • Locale. L'appliance di backup/ripristino per cui è stato creato il profilo della risorsa.

  • Telecomando. L'appliance di backup/ripristino utilizzata per la replica remota. Questa appliance remota deve essere già accoppiata all'appliance locale selezionata.

  • OnVault. Lo spazio di archiviazione definito da un pool di archiviazione OnVault. I pool OnVault possono essere archiviazioni sotto il tuo controllo o vault di backup gestiti da Google Cloud indelebili e immutabili.

I profili delle risorse vengono applicati alle applicazioni in App Manager e funzionano in tandem con i modelli di criteri:

  • Un modello di criteri che non include un criterio di replica deve essere applicato a un'applicazione insieme a un profilo della risorsa che memorizza i dati solo localmente.
  • Un modello di criteri che include un criterio di replica deve essere applicato a un'applicazione insieme a un profilo della risorsa che memorizza i dati su un'altra appliance o nello spazio di archiviazione definito dal pool di archiviazione OnVault.

Definisci un profilo della risorsa per qualsiasi appliance di backup/ripristino aggiunta alla console di gestione.

Passaggi successivi