So, we’ve already covered at a high level some of the new features and improvements to Veeam Backup & Replication V9. Now that V9 has hit general availability, there are a few new features we think it’s important for Veeam users to know.
BitLooker
Not to be confused with encryption program BitLocker, BitLooker is Veeam’s patented data-reduction technology. BitLooker reduces copied data and therefore, backup file sizes, and replication bandwidth usage.
As we all know, in Windows, when you delete a file, you actually just delete the pointer to data on the disk. The data’s still there — it will be overwritten eventually — but until then, the data still sits on the disk. The problem that this creates in virtualized environments is that data still shows as being in use to the virtual storage infrastructure. So, because the actual data is still there, your backups don’t recognize it as different from any other data. For example, if you have a 1TB server and delete 500GB the server still backs up the whole 1TB, because the blocks making up the deleted data are still present.
How does BitLooker work? It’s able to detect the deleted files and the swap and hibernation files. Therefore, BitLooker excludes these files from the backup job, which makes the backups smaller and more efficient. In this example, it would remove the 500GB of deleted blocks from the backup and it would become smaller.
BitLooker also has a feature that allows us to exclude user-specified files and folders. For example, you might have a file server with a lot of data but you know it isn’t important to back up or is temporary. You can enable BitLooker to ignore that folder.
Note: if you are a large organization that experiences lots of file changes and deletions in a day, enabling this feature may put a performance strain on your backup server as it compares all of the data. Account for this when you calculate your server resources.
Also note: This feature only works on Windows NTFS operating systems at this time. Keep this in mind if you’re looking to upgrade to Windows Server 2016 as it will be using ReFS instead of NTFS. Look for updates in regards to Linux or ReFS support.
Also, also note: You have to go in and manually enable BitLooker on your upgraded jobs from V8. It will be enabled by default in V9.
Guest Interaction Proxy
This feature will for the most part benefit organizations with disparate geographic offices. This feature offloads processing to a Windows computer located at a remote site to reduce WAN bandwidth usage and increase performance of application-aware processing and guest file system indexing. What most people don’t realize is that if you back up a remote server with Veeam through a Veeam proxy, any application-aware processing (SQL, Exchange) and guest file indexing still has to happen on the “main” Veeam server. This allows that load to be offloaded locally to a Windows server. This really helps scalability with organizations that have remote offices.
This can also include a new mount server that can be attached to remote repositories to also reduce WAN bandwidth usage and increase file-level recovery performance from remote Veeam backup repositories. Again, while you can have remote Veeam repositories and proxies, the actual file-level restores still have to come from the “main” Veeam server. If that’s across a WAN, that’s a lot of additional traffic. Using the Guest Interaction Proxy can mean faster restores from remote repositories to the local server.
Per-VM Backup File Chains
Until now, backups were saved into one large file, encompassed as the job itself, instead of by machine. Now, you have the option to split it out as per-VM backup file chain, which can greatly improve the writing performance of your backup repositories as they’re able to leverage parallel VM processing.
Note: This will use more space and will actually limit some of your compression and deduplication from your backup job if you split them out individually. You’ll have to weigh the performance gains against the efficiencies lost. This feature was originally geared towards environments with dedicated deduplication storage appliances such as ExaGrid, Quantum or DataDomain, because dedupe happens post process for them.
Veeam is going for front-end write performance for deduplication appliances since they’re limited in the speed at which they can ingest new backup data.