Che cos'è un backup con impatto ridotto?
In circostanze normali, su un'appliance di backup/recovery di Backup e RE, Backup e RE esegue un backup iniziale completo del database che richiede molto tempo, mentre 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 splash ridotto è 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 l'impossibilità di leggere la bitmap. Il servizio che legge la bitmap è cbt_server in un ambiente Linux e AAMService in un ambiente Windows.
I backup con splash ridotto richiedono più tempo rispetto ai backup eseguiti in condizioni normali perché devono eseguire nuovamente un'importazione completa per ricreare una bitmap affidabile. Può quindi applicare le modifiche incrementali senza dover sostituire il backup completo.
Cose che non causano backup con schizzi ridotti
- Upgrade dei connettori
- Riavvia il sistema in modo controllato
- Riavvi graceful 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 affidabili
Una bitmap non affidabile si verifica quando un evento interrompe il job di backup, ad esempio:
- Un arresto non corretto dell'host:
- Un arresto non normale causa un low-splash a causa dell'inaffidabilità delle bitmap. Ciò include l'interruzione dell'alimentazione di una macchina fisica o qualsiasi altro metodo di spegnimento di Windows senza eseguire un arresto normale o un errore di schermata blu. Questo vale anche se una macchina di un cluster genera un errore di schermata blu che attiva il failover, poiché la bitmap della macchina con l'errore non è affidabile.
- Se tutti i server Windows in un cluster che hanno ospitato il database dal backup precedente non sono disponibili e non eseguono l'agente Backup e RE. Estraiamo le bitmap da ogni host del cluster che ha ospitato il database dall'ultimo backup per trovare le modifiche e, senza tutte le bitmap, dobbiamo eseguire un backup low-splash per mantenere l'integrità dei dati. Tieni presente che se un host del cluster che ospitava un database genera un errore BSOD, la bitmap potrebbe essere disponibile al momento del backup, ma non essere comunque affidabile, per cui è necessario un ripristino con un impatto ridotto.
- Un aggiornamento del modulo kernel non riuscito
- Un arresto anomalo o un riavvio nel daemon della modalità utente
- Un errore di fingerprint durante l'esecuzione di un backup. (Backup e RE esegue un "controllo dell'impronta" su ogni job di backup per verificare la presenza di errori).
- Errore durante la vaulting, 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à ridotta a causa dell'impossibilità di caricare il modulo kernel. In genere, questo accade quando la versione del sistema operativo non è supportata.
- Se cbt_server o AAMService viene interrotto durante il backup, non è possibile recuperare le bitmap e il job di backup viene eseguito in modalità low-splash.
Se AAMService non è inattivo per molto tempo, l'avvio di AAMService renderà disponibili le bitmap per un backup normale.
- Se cbt_server o AAMService viene interrotto 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à con impatto ridotto. Il tempo necessario dipende dalla quantità di I/O del disco che si verifica nel database. In genere, ciò richiede giorni di inattività di AAMService.
- L'arresto normale di cbt_server o AAMService può rendere inaffidabili le bitmap 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 impatto ridotto.
- 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, poiché non è possibile sapere cosa è stato scritto nel file mentre era smontato.