Veeam Backup and the maintenance of a Reverse Incremental Job

Veeam reverse incremental backups are since their introduction one of the most appreciated features among their users. At the price of an increase in I/O on the backup storage when compared with a traditional incremental backup, it allows for a single full backup file and a long chain of increments, thus offering huge savings on disk space.

However many users ignore that even a Reverse Incremental backups are not “Set and Forget”. Even if a reversed chain can be years long, this kind of usage is not recommended, rather it can lead to several problems.

Let’s suppose we are saving 10 VMs in a single job. Their totale size is 1 Tb, and Veeam thanks to deduplication and compression creates a 500 Gb VBK file. Then after some time 2 of these VMs are deleted, and their total disk usage is lowered to 700 Gb. The supposed size of the new backup would be around 350 Gb, but we see instead the VBK file still is 500 Gb. This happens because there is no way to shrink the VBK file while running a job, unless we run an Active Full backup.

Another problem is fragmentation. Because of the way a Reverse Incremental works, its internal blocks are continuosly swapped and updated by new blocks. This actvity leads over time to an excessive fragmentation of the VBK file, and is useless to defrag the underlying NTFS filesystem for example since the fragmentation is “inside” the VBK itself. Again, the solution is an Active Full backup.

the main concern however is another one. During a restore we could face an error like this one:

Error during restore operation

What’s happened? The VBK file we are restoring from is basically corrupted, and the restore fails.

The error may remain unseen form months, usually because we restore only single files, read from non corrupted blocks inside the backup file. If the corrupted blocks are inside the VBK rather than the reverse files, it could be those blocks are never updated during daily increments, bacuse for example they host the operating system of the Guest OS and they are never updated after the initial installation. So you could realize those blocks are corrupted only after several months, right when you need to read them to do a restore…

To solve this problem, you first need to think that even Reverse Incremental backups need to be managed and maintained, specifically performing regular Active Full backups. This kind of backup creates a new VBK file without reading any of the previous file in the chain, thus creating a new chain. You can run an Active Full manually:

Manually start an Active Full

or even better by configuring the Job to do it in a scheduled way. In the next screen you can see an Active Full configured to run the first saturday of the month, every two months.

Periodic Active Full for a Reverse Incremental job

There is no best practice about how frequently you need to run an Active Full, I usually run them every two months. You need to figure out your best settings, trying to balance between an excessive frequency (that would frustrate the advantages of reverse incremental) and a too long chain (that would increase the risk of having corrupted blocks and bigger VBK files).

Moreover, you need to take into account two essentials facts when introducing Active Full into your schedules:
– backup execution times will obviously increase, so you better schedule active full during non-production times like weekends
– as long as the retention period of the backup jobs is not reached, you will have 2 full VBK files in your backup storage, so you better estimate space usage

Finally, how could we know when the last full backup has been made? You can read all the logs of the jobs inside Veeam, or you can use this quick powershell script I made:

# Check how old is the last successful active full backup in Veeam Backup & Replication
#
# Author: Luca Dell'Oca
# ldelloca@gmail.com
#
# You need to run this script directly in the Veeam Backup & Replication server.
#
# Version 1.0 - 26 March 2013
# Load Veeam Powershell Snapin
Add-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue
# Get successful backup executions where the backup was a full one, and list only the most recent one.
foreach($job in (Get-VBRJob | ? {$_.JobType -eq "Backup"}))
{
Get-VBRBackupSession | ?{$_.Jobname -eq $Job.name -and $_.JobType -eq "Backup" -and $_.IsFullMode -eq "True" -and $_.IsCompleted -eq "True" -and $_.Result -ne "Failed" -and ($_.isretrymode -eq $False -or $_.isretrymode -eq $True)} | Sort-Object EndTime -Descending | Select-Object -First 1 | select JobName, EndTime
}

 

Its output will be something like this (for non european readers, date are dd/mm/yyyy and actual date was 27th March at the time of writing this article):

Script output

You can see two backups where the last full was made almost 5 months before.

A lesson learned: there are NO “set and forget” solutions, NEVER.

One thought on “Veeam Backup and the maintenance of a Reverse Incremental Job

  1. Good article and insight. As a newbie to VEEAM it is extremely helpful to assist me in configuring the best environment I can, thanks!

Comments are closed.

Veeam Backup e la manutenzione di un sistema Reverse Incremental

I backup reverse incremental di Veeam sono da sempre una delle soluzioni più apprezzate dai suoi utilizzatori. Al costo di un incremento di I/O sullo storage di backup rispetto a un semplice backup incrementale, permette di avere sullo storage un unico file di tipo full e una lunga catena di incrementi, permettendo in questo modo di risparmiare un notevole quantitativo di spazio.

Quello che molti utenti ignorano tuttavia, è che un Reverse Incremental non è un backup di tipo “Set and Forget”. Nonostante una catena reverse possa avere una storia anche di anni, questo suo utilizzo non è per nulla consigliabile, e anzi può portare a diversi problemi.

Ipotizziamo di salvare 10 VM in un unico job. La loro dimensione complessiva è 1 Tb, e Veeam tramite deduplica e compressione crea un file VBK di 500 Gb. Dopo qualche periodo vengono cancellate 2 VM, e la dimensione complessiva dei file VMDK si riduce a 700 Gb. Veeam ipoteticamente dovrebbe creare un file di backup di 350 Gb, ma notiamo invece che il file VBK continua ad essere 500 Gb. Questo avviene perchè non vi è possibilità di ridurre le dimensioni di un file VBK durante l’esecuzione del Job, l’unico metodo è realizzare un Active Full.

Un altro problema è la frammentazione. Per come funziona un Reverse Incremental, i blocchi in esso contenuti vengono continuamente sostituiti ed aggiornati da blocchi modificati. Questa attività porta col tempo a una eccessiva frammentazione del file VBK, frammentazione non risolvibile con normali procedure di defrag ad esempio della partizione NTFS dove i file vengono salvati, dato che è un frammentazione interna al file VBK stesso. Anche in questo caso, la soluzione è un backup Active Full.

Il problema maggiore però è un altro. Potrebbe capitare che durante un ripristino vi ritroviate con un errore simile al seguente:

Error during restore operation

Cosa è successo? Il file VBK da cui viene ripristinata una virtual machine è fondamentalmente corrotto, e il ripristino non è possibile.

Può capitare che non vi accorgiate di questo problema per diversi mesi, solitamente perchè fate spesso solo ripristini di tipo file, e quindi andate a leggere blocchi diversi da quelli che sono corrotti all’interno del file di backup. Se i blocchi corrotti sono contenuti nel file VBK, potrebbe oltretutto capitare che questi non vengano mai sovrascritti durante i backup schedulati, perchè ad esempio sono blocchi relativi ai file di sistema operativo del guest OS, che spesso non vengono più aggiornati dopo l’installazione iniziale. Questo fa si che ci si accorga del problema appunto dopo molti mesi, e quasi sicuramente quando si ha necessità di fare un ripristino…

Per risolvere il problema, come dicevo è necessario innanzitutto a pensare che anche i backup di tipo Reverse Incremental vanno gestiti e mantenuti, in particolare effettuando periodicamente un backup di tipo Active Full. Questo tipo di backup genera un nuovo file VBK senza leggere nessuno dei file precedenti della catena, diventando di fatto l’inizio di una nuova catena. E’ possibile realizzare un backup Active Full manualmente:

Manually start an Active Full

oppure, scelta migliore, configurare opportunamente il Job per realizzare periodicamente un Active Full. Nell’esempio sottostante viene creato un Active full il primo sabato del mese, ogni due mesi.

Periodic Active Full for a Reverse Incremental job

Non esiste una frequenza consigliata nel realizzare un Active Full, solitamente io li realizzo ogni due mesi. Ognuno deve, in base al proprio ambiente, trovare il corretto bilanciamento tra una frequenza eccessiva (che vanificherebbe i vantaggi di un reverse incremental) e una singola catena troppo lunga (che aumenterebbe il rischio di blocchi corrotti e VBK eccessivamente grandi).

Inoltre, bisogna tenere in considerazione due aspetti fondamentali nell’introdurre gli active full periodici nelle proprie schedulazioni: – i tempi di backup si allungano notevolmente, è bene quindi programmare l’active full in periodi di scarsa attività come ad esempio i weekend – fintanto che la retention del Job di backup non viene raggiunta, per un periodo di tempo ci saranno 2 file VBK a piena dimensione all’interno dello storage di backup, e il rischio di saturarlo è reale

Infine, come facciamo a sapere quando è stato realizzato l’ultimo backup di tupo Full? Possiamo alternativamente leggere a ritroso tutti i report di backup di Veeam, oppure utilizzare questo veloce script in powershell che ho realizzato:

# Check how old is the last successful active full backup in Veeam Backup & Replication
#
# Author: Luca Dell'Oca
# ldelloca@gmail.com
#
# You need to run this script directly in the Veeam Backup & Replication server.
#
# Version 1.0 - 26 March 2013
# Load Veeam Powershell Snapin
Add-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue
# Get successful backup executions where the backup was a full one, and list only the most recent one.
foreach($job in (Get-VBRJob | ? {$_.JobType -eq "Backup"}))
{
Get-VBRBackupSession | ?{$_.Jobname -eq $Job.name -and $_.JobType -eq "Backup" -and $_.IsFullMode -eq "True" -and $_.IsCompleted -eq "True" -and $_.Result -ne "Failed" -and ($_.isretrymode -eq $False -or $_.isretrymode -eq $True)} | Sort-Object EndTime -Descending | Select-Object -First 1 | select JobName, EndTime
}

 

Il suo output darà risultati simili a questo:

Script output

Ci sono due backup tra quelli presenti il cui utimo full è stato realizzato quasi 5 mesi prima.

La lezione che ricaviamo da questo articolo è semplice: NON esistono sistemi “set and forget”, mai.