Changed Block Tracking (CBT) è una funzionalità introdotta in VMware vSphere 4.0 per permettere l’impementazione di backup incrementali nativi lato sorgente. VMware VDAP espone questa funzionalità (insieme a tutte le altre per i backup agentless) e di conseguenza tutti i programmi di backup nativi per VMware la utilizzato.
Il problema è che settimana scorsa è stato individuato un bug molto critico che rende i dati del CBT non più attendibili! E questo riguarda tutte le versioni di vSphere 6 (inclusa l’ultima Update 1a).
Il CBT biene utilizzato per velocizzare i backup (copiando solo i blocchi modificati dall’ultimo backup), ma in queste condizioni i dati copiati potrebbero essere incosistenti!
Questa la descrizione ufficiale del problema (benché non vengano fornite maggiori informazioni tecniche):
This issue occurs due to an issue with CBT in the disklib area, this causes the change tracking information of I/Os that occur during snapshot consolidation to be lost. The main backup payload data is never lost and it is always written to the backend device. However, the corresponding change tracking information entries which occur during the consolidation task are missed. Subsequent calls to CBT APIs do not include these missed blocks, hence a backup based on this CBT data is inconsistent.
- Downgrade degli host ESXi alla versione 5.5, vedere Reverting to a previous version of ESXi (1033604); con il consegente eventuale downgrade the virtual Hardware Version dalla 11 ala 10, se necessario vedere Downgrading the virtual machine hardware version in ESX/ESXi (1028019).
- Spegnimento delle virtual machine prima di un incremental backup.
- Fare un full virtual machine backup invece dei backup incrementali.
L’ultima ovviamente è la soluzione con il minor impatto e nel caso di Veeam è possibile semplicemente disabilitare l’uso del CBT all’interno delle advanced job settings. I backup e le repliche saranno sempre incremental, ma lato sorgente ci vorrà più tempo dato che è tutto full. Notare che gli Active Full backup possono essere corrotti dato che pure in questo caso viene usato il CBT per individuare le aree vuote di un virtual disk e saltarle.
Curioso come nonostante siano passati vari mesi dall’uscita di vSphere 6.0 e sia uscito persino un Update (in realtà sia l’update 1 che quello 1a), vi sia ancora qualche motivo per aspettare prima di aggiornare a questa versione in produzione, soprattutto in ambienti business critical.
Per maggiori informazioni su questo bug, vedere l’articolo KB2136854 (Backups with Changed Block Tracking can return incorrect changed sectors in ESXi 6.0).
Aggiornamento di novembre 2015: con la patch ESXi600-201511401-BG il problema viene risolto. Vedere la relativa KB 2137546.