Che cos'è un backup a basso impatto?
In circostanze normali, su un'appliance di backup/recupero del servizio di Backup e DR, Backup e RE esegue un backup completo iniziale di un database che richiede molto tempo, e poi tutti i backup successivi sono backup incrementali molto più veloci. Un backup incrementale confronta le bitmap dello snapshot corrente e di quello precedente e applica solo le modifiche incrementali.
Un backup a basso 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 inaffidabile o l'impossibilità di leggere il bitmap. Il servizio che legge la bitmap è cbt_server in un ambiente Linux e AAMService in un ambiente Windows.
I backup a basso impatto richiedono più tempo rispetto ai backup eseguiti in condizioni normali perché devono eseguire nuovamente l'importazione completa per ricreare una bitmap affidabile. Può quindi applicare le modifiche incrementali senza dover sostituire il backup completo.
Elementi che non causano backup a basso impatto
- Aggiornamenti dei connettori
- Riavvii controllati del sistema
- Riavvii controllati di cbt_server o AAMService, presupponendo 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 affidabili
Un bitmap inaffidabile si verifica quando qualcosa interrompe il job di backup, tra cui quanto segue:
- Un arresto anomalo dell'host:
- Un arresto anomalo causa un'immagine di avvio di bassa qualità a causa della scarsa affidabilità delle bitmap. Ciò include l'interruzione dell'alimentazione di una macchina fisica o qualsiasi altro metodo per spegnere Windows senza eseguire un arresto normale o un errore della schermata blu. Ciò vale anche se una macchina in un cluster genera un errore di schermata blu che attiva il failover, poiché la bitmap della macchina in errore non è affidabile.
- Se tutti i server Windows in un cluster che hanno ospitato il database dall'ultimo backup non sono disponibili e non eseguono l'agente Backup e RE. Estraiamo le bitmap da ogni host del cluster che ospita il database dall'ultimo backup per trovare le modifiche e, senza tutte le bitmap, dobbiamo eseguire lo splash basso per mantenere l'integrità dei dati. Tieni presente che se un host del cluster che ospitava un database si blocca, la bitmap potrebbe essere disponibile al backup ma comunque inaffidabile, quindi è necessario un ripristino a basso splash.
- Aggiornamento del modulo kernel non riuscito
- Un arresto anomalo o un riavvio nel daemon della modalità utente
- Un errore di impronta durante l'esecuzione di un backup. (Il servizio di backup e DR esegue un "controllo dell'impronta" su ogni job di backup per verificare la presenza di errori.)
- Errore durante il trasferimento nel vault, se durante l'arresto del sistema operativo 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 nodo diverso.
- Backup in esecuzione in modalità degradata a causa dell'impossibilità di caricare il modulo kernel. Ciò si verifica in genere quando il sistema operativo è una versione non supportata.
- Se cbt_server o AAMService viene arrestato durante il backup, le bitmap non possono
essere recuperate e il job di backup viene eseguito in modalità a basso splash.
Se AAMService non è inattivo per molto tempo, l'avvio di AAMService comporterà
la disponibilità di bitmap per un backup normale.
- Se cbt_server o AAMService viene arrestato per un periodo di tempo sufficiente a far sì che il driver metta in coda alcuni gigabyte di eventi, le bitmap non possono essere ricreate e il backup sarà in modalità low-splash. Il tempo necessario dipende dalla quantità di I/O del disco nel database. In genere, ciò richiede giorni di inattività di AAMService.
- L'arresto anomalo di cbt_server o AAMService può rendere le bitmap inaffidabili per quelle attualmente caricate. Le bitmap vengono caricate se il file monitorato è stato scritto negli ultimi 15 minuti, quindi in genere per un database occupato questo causerebbe un basso splash.
- Se un volume contenente un file monitorato (ad es. un file .mdf di SQL Server) viene smontato sull'host e poi rimontato, le bitmap non sono affidabili perché non è possibile sapere cosa è stato scritto nel file mentre era smontato.