When backing up with a VADP backup set a virtual machine with think disks, the stored size (compression ratio) is tightly linked with the fill up level of the disk, the more data, the lager the stored size.
Below are a few testing results providing more details on the topic.
Test 1, Thin Provisioning, LZOP compresssion:
- backup source VM-01 configuration:
- HDD1: 80.0 GB with 10% filled in data (it has Windows Operating System only),
- HDD2: 2.0 TB with 0% filled in data;
- backup source VM-02 configuration:
- HDD1: 80.0 GB with 35.0% filled in data,
- HDD2: 2.0 TB with 35.0% filled in data;
A VADP set was created for each vm, and a backup session run, the results were:
1. disk HDD1 backup compression ratio was around 14 to 1 for the 10.0 % fill level (Stored size of 6 GB compared with the original size of the vmdk of 80 GB), and 2.5 to 1 for 35.0% fill level (Stored size of 30 GB, compared with the original size of the vmdk of 80 GB).
2. disk HDD2 backup compression ratio was 16000 to 1 for the 0.0% fill level (Stored size of 0.13 GB compared with the original size of the vmdk of 2000 GB), and 4.0 to 1 for 35.0 % fill level (Stored size of 500 GB compared with the original size of the vmdk of 2000 GB).
As a conclusion, when backing up thin disks, the stored size / compression ratio depends on the disk fiill up level.
Test 2, Thick Eager Provisioning, LZOP compression:
- backup source VM-01 configuration:
- HDD1: 80.0 GB with 10% filled in data (it has Windows Operating System only),
- HDD2: 2.0 TB with 0% filled in data;
- backup source VM-02 configuration:
- HDD1: 80.0 GB with 35.0% filled in data,
- HDD2: 2.0 TB with 35.0% filled in data;
A VADP set was created for each vm, and a backup session run, the results were:
1. disk HDD1 backup compression ratio was around 4 to 1 for the 10.0 % fill level (Stored size of 32 GB compared with the original size of the vmdk of 80 GB), and 4 to 1 for 35.0% fill level (Stored size of 20 GB, compared with the original size of the vmdk of 80 GB).
2. disk HDD2 backup compression ratio was 4 to 1 for the 0.0% fill level (Stored size of 500 GB compared with the original size of the vmdk of 2000 GB), and about 4 to 1 for 35.0 % fill level (Stored size of 500 GB compared with the original size of the vmdk of 2000 GB).
As a conclusion, when backing up thick eager disks, the stored size / compression ratio does not depend on the disk fiill level.
Conclusion:
The tests above used a brand new vmdk (2 TB), formatted NTFS and populated with random data (30% fill level) in one writing operation, if a vmdk is in use for a long period of time, the way the operating system uses the disks may significantly increase the backup stored size (e.g. for a 2 TB vmdk at 30% fill level, the stored size can be 1.2 TB for the first backup).
The stored size for subsequent backup sessions is usually much smaller as on the one hand, if the CBT option is enabled, only the changed blocks are retrieved from the vmdk during backup, and on the other hand the Asigra delta algorithm is applied on top of the changed blocks retrieved from the backup source using the VMWare CBT feature, so a double backup data reduction occurs.
Below are a few testing results providing more details on the topic.
Test 1, Thin Provisioning, LZOP compresssion:
- backup source VM-01 configuration:
- HDD1: 80.0 GB with 10% filled in data (it has Windows Operating System only),
- HDD2: 2.0 TB with 0% filled in data;
- backup source VM-02 configuration:
- HDD1: 80.0 GB with 35.0% filled in data,
- HDD2: 2.0 TB with 35.0% filled in data;
A VADP set was created for each vm, and a backup session run, the results were:
1. disk HDD1 backup compression ratio was around 14 to 1 for the 10.0 % fill level (Stored size of 6 GB compared with the original size of the vmdk of 80 GB), and 2.5 to 1 for 35.0% fill level (Stored size of 30 GB, compared with the original size of the vmdk of 80 GB).
2. disk HDD2 backup compression ratio was 16000 to 1 for the 0.0% fill level (Stored size of 0.13 GB compared with the original size of the vmdk of 2000 GB), and 4.0 to 1 for 35.0 % fill level (Stored size of 500 GB compared with the original size of the vmdk of 2000 GB).
As a conclusion, when backing up thin disks, the stored size / compression ratio depends on the disk fiill up level.
Test 2, Thick Eager Provisioning, LZOP compression:
- backup source VM-01 configuration:
- HDD1: 80.0 GB with 10% filled in data (it has Windows Operating System only),
- HDD2: 2.0 TB with 0% filled in data;
- backup source VM-02 configuration:
- HDD1: 80.0 GB with 35.0% filled in data,
- HDD2: 2.0 TB with 35.0% filled in data;
A VADP set was created for each vm, and a backup session run, the results were:
1. disk HDD1 backup compression ratio was around 4 to 1 for the 10.0 % fill level (Stored size of 32 GB compared with the original size of the vmdk of 80 GB), and 4 to 1 for 35.0% fill level (Stored size of 20 GB, compared with the original size of the vmdk of 80 GB).
2. disk HDD2 backup compression ratio was 4 to 1 for the 0.0% fill level (Stored size of 500 GB compared with the original size of the vmdk of 2000 GB), and about 4 to 1 for 35.0 % fill level (Stored size of 500 GB compared with the original size of the vmdk of 2000 GB).
As a conclusion, when backing up thick eager disks, the stored size / compression ratio does not depend on the disk fiill level.
Conclusion:
- The Thin Provisioning disks filled with less data (less than 20%) are compressed more efficient than the Thick Eager Provisioning with the same fill level. The stored size / compression ratio for Thick Eager disks does not depend on the fill level.
- There is no difference between Thin and Thick Eager Provisioning disks backup statistics if the disks are filled with more than 20% heterogeneous data.
The tests above used a brand new vmdk (2 TB), formatted NTFS and populated with random data (30% fill level) in one writing operation, if a vmdk is in use for a long period of time, the way the operating system uses the disks may significantly increase the backup stored size (e.g. for a 2 TB vmdk at 30% fill level, the stored size can be 1.2 TB for the first backup).
The stored size for subsequent backup sessions is usually much smaller as on the one hand, if the CBT option is enabled, only the changed blocks are retrieved from the vmdk during backup, and on the other hand the Asigra delta algorithm is applied on top of the changed blocks retrieved from the backup source using the VMWare CBT feature, so a double backup data reduction occurs.