Tag Archives: Backup

Veeam NAS Sizing – Cache Repositories and Metadata

For those diving into NAS sizing, I wanted to share this write up to help explain the roles of the Cache Repositories and Metadata. The sizing of these components varies depending on the type of backup storage you’re using. This consideration has become increasingly important with the addition of object storage support in v12.

A Cache Repository is a storage location where Veeam Backup & Replication keeps temporary cached metadata (folder level hashes) for the NAS data being protected. A Cache Repository improves incremental backup performance because it enables Veeam to quickly identify source folders that don’t have any changes via matching hashes stored in the Cache Repository.

When NAS backup is targeting a disk-based repository, the cache metadata is held in memory so very little if any storage on the Cache Repository is required, roughly 1 to 2 GB for disk-based repositories.

Not to be confused with cached metadata (folder level hashes) on the Cache Repository, Metadata is created by Veeam used to describe the backup files, source, files name version and pointers to backup blobs. Most often, when performing restore, merge, transform operations, Veeam interacts with this Metadata rather than with the backup data.

Metadata is always redundant (“meta” and “metabackup” or “metacopyv2”). The actual placement and number of metadata copies is dependent on the repository configuration and type. This is important to understand because the number and placement of Metadata will impact how much storage is required.

Continue reading →

Facing the threat of cyberattacks: how does your disaster recovery solution stack up?

It’s a message every IT manager dreads.

‘Your personal files are encrypted by CTB-Locker. To decrypt the files, you need to pay 3 bitcoin.’

Yet, unfortunately, getting locked out of your company’s own data – and then being expected to pay a ransom to get it back – is becoming more common as cybercriminals get craftier. Like pesky bed bugs that have become immune to deterrents, ransomware attacks such as CryptoLocker, CryptoWall, Locky, TorrentLocker and Virlock are constantly evolving to sneak past all the new defences that IT security experts are busy building up.

Continue reading →

Changing Data Compression and Deduplication settings

2 Replies

So you probably already knew that you can change compression and deduplication settings for existing backup jobs, the new settings will not have any effect on previously created backup files in the chain. They will be applied to new backup files after the settings were created.

For deduplication, the changes take effect after you create an active full backup.

For Compression, the change takes effect to the very next backup files created.

Something that you may not have known is that if you use the reverse incremental backup method, the newly created backup files will contain a mixture of data blocks compressed at different levels.

Let’s say, you are backing up using reverse incremental with the compression set to ‘None’. After several job sessions, you wish to increase the compression by changing from ‘None’ to ‘Optimal’. Now, for reverse incremental backup chains, the full backup file is rebuilt with every job session to include new data blocks. As a result, the full backup file will contain a mixture of data blocks: data blocks compressed at the ‘None’ level and data blocks compressed at the ‘Optimal’ level.

If you want the newly created backup file to contain data blocks compressed at one level, you can create an active full backup. An active full backup will consist of retrieving all the data for the whole VM image from the production infrastructure and compress it at the new compression level. All subsequent backup files in the backup chain will also use the new compression level.

For space-saving goodness, I recommend checking out ReFS and how Veeam can leverage it, you can learn more about ReFS here https://hyperv.veeam.com/blog/benefits-of-refs-file-system-in-windows-server-2016/

Veeam BitLooker – “Deleted” does not necessarily mean actually deleted

A great new addition to Veeam Backup & Replication v9 is BitLooker (patent pending), this new feature is designed to cut down backup file size and replication bandwidth utilisation by 20% or more. Essentially it removes chunks of data congesting your backup storage and network resources with the below three capabilities

Excluding swap and hibernation files blocks
Excluding deleted files blocks
Excluding user-specified files and folders

Since NTFS never reclaims deleted data blocks* in the file system when files are deleted, this means that an image-based backup for a VM may have to process more data blocks than what are actually used in the file system

BitLooker works by analysing the NTFS Master File Table on the VM guest OS to identify deleted file blocks and zeros out these blocks. If a data block of the VM image contains only the deleted file blocks, Veeam Backup & Replication does not read this data block from the source volume.
If a data block of the VM image contains zeroed out blocks and other data, Veeam Backup & Replication copies this block to the target

By doing so, it reduces the size of an image-level backup file and bandwidth consumption for replication jobs.

Things to remember

Veeam Backup & Replication can only exclude deleted file blocks on the VM guest OS with Microsoft NTFS.
File exclusions can only be performed on a running VM
For users upgrading from previous versions: By default, BitLooker will be enabled for newly created jobs upon upgrade. However, it will not be automatically enabled on existing jobs to ensure the jobs do not change existing behaviors. BitLooker can be enabled manually in the advanced job settings or by using a PowerShell script. Link to Powershell Script
If you enable or disable the Exclude deleted file blocks setting for the existing job, Veeam Backup & Replication will apply the new setting from the next job session.
Excluding user-specified files and folders requires Enterprise edition licensing.
The option to exclude swap file blocks was available in previous product versions but was enhanced in v9 to also exclude hibernation files.

*You could manually reclaim before each backup using a tool such as sdelete from SysInternals but this will inflate thin-provisioned virtual disks and temporarily consume all available free disk space on the volume.

Sources:

https://helpcenter.veeam.com/backup/hyperv/dirty_blocks.html
https://www.veeam.com/blog/save-backup-storage-using-veeam-backup-replication-bitlooker.html