Che cos'è un backup a basso impatto?
In circostanze normali, il servizio di Backup e DR esegue un backup iniziale di importazione completa di un database che richiede molto tempo, dopodiché tutti i backup successivi sono backup incrementali molto più rapidi. Un backup incrementale confronta le bitmap dello snapshot corrente e di quello precedente e applica solo le modifiche incrementali.
Un backup con ridotto impatto è un tipo speciale di job di backup che si verifica quando un errore di sistema nel job di backup precedente genera un'immagine bitmap non affidabile o impedisce di leggere la bitmap. Il servizio che legge il bitmap è cbt_server in un ambiente Linux e AAMService in un ambiente Windows.
I backup con pochi splash sono più dispendiosi in termini di tempo rispetto a quelli eseguiti in condizioni normali perché richiedono di eseguire di nuovo un'importazione completa per ricreare un bitmap affidabile. Può quindi applicare le modifiche incrementali senza dover sostituire l'immagine completa.
Elementi che non causano backup con basso impatto
- Upgrade dei connettori
- Riavvio corretto del sistema
- Riavvii corretti di cbt_server o AAMService supponendo che il servizio sia ancora in esecuzione al momento del backup
- Failover che non hanno riscontrato gli errori che causano bitmap inaffidabili.
Cause di bitmap non attendibili
Un bitmap non attendibile si verifica quando qualcosa interrompe il job di backup, ad esempio:
- Un arresto anomalo dell'host
- Un arresto anomalo causa un'esperienza di splash bassa a causa dell'inaffidabilità delle bitmap. Sono inclusi lo scollegamento dell'alimentazione di una macchina fisica o qualsiasi altro metodo di disattivazione di Windows senza un arresto graduale o un errore della schermata blu. Questo accade anche se una macchina in un cluster presenta un errore della schermata blu che attiva il failover, poiché la bitmap della macchina in errore non è attendibile.
- Se tutti i server Windows di un cluster che hanno ospitato il database dal backup precedente non sono disponibili e non eseguono i servizi Actifio. Estraiamo bitmap da ogni host del cluster che ha ospitato il database dal backup precedente per trovare le modifiche e, senza tutte le bitmap, dobbiamo eseguire low-splash per mantenere l'integrità dei dati. Tieni presente che se un host di cluster che ospitava un database viene colpito da un BSOD, la bitmap potrebbe essere disponibile al momento del backup, ma non essere comunque attendibile, quindi con un'esperienza utente ridotta.
- Un aggiornamento del modulo del kernel non riuscito
- Un arresto anomalo o un riavvio nel daemon in modalità utente
- Un errore di impronta durante l'esecuzione di un backup. Il servizio di backup e RE esegue un "controllo dell'impronta" su ogni job di backup per verificare la presenza di errori.
- Errore durante il salvataggio nel vault, se durante l'arresto dell'OS il disco di archiviazione è pieno e il sistema non può scrivere tutti i dati nel vault.
- Failover del nodo SAP HANA, che causa il reindirizzamento del backup a un altro nodo.
- Il backup è in esecuzione in modalità degradata a causa dell'impossibilità di caricare il modulo del kernel. Questo accade in genere quando il sistema operativo è una versione non supportata.
- Se cbt_server o AAMService viene interrotto durante il backup, le bitmap non possono essere recuperate e il job di backup viene eseguito in modalità di splash ridotta.
Se AAMService non è inattivo per molto tempo, l'avvio di AAMService farà sì che i bitmap siano disponibili per un normale backup.
- Se cbt_server o AAMService viene interrotto per un periodo di tempo sufficientemente lungo da consentire al driver di mettere in coda alcuni gigabyte di eventi, le bitmap non possono essere ricreate e il backup sarà in modalità di lancio ridotto. La durata dell'operazione dipende dalla quantità di I/O del disco che si verifica nel database. In genere, sono necessari giorni di tempo di riposo di AAMService.
- L'arresto anomalo di cbt_server o AAMService può causare la mancata affidabilità delle bitmap per le bitmap attualmente caricate. I bitmap vengono caricati se il file monitorato è stato scritto negli ultimi 15 minuti, quindi in genere per un database in uso questo causerebbe un'esplosione ridotta.
- Se un volume contenente un file monitorato (ad esempio un file .mdf di SQL Server) viene smontato sull'host e poi rimontato, le bitmap non sono affidabili poiché non è possibile sapere cosa è stato scritto nel file mentre era smontato.