Deduplication Issues
Hi,
following scenario:
Since VMP does not support pRDM, we have to use multiple VMDKs to be able to offer large storage capacity. We wanted to move data off from one drive to another one (one VMDK to another VMDK) by using robocopy. I expected that deduplication would kick in and make sure that the copied date will not be put into the archive again. This has not worked. The data was backup up again into the archive doubling the amount of space needed for the backup.
1. Any idea what went wrong?
2. If I have the same file but different metadata (ownership, mod date etc) would Acronis detect the file as a dupe or would it store it twice?

- Accedi per poter commentare

Hi Vasily,
Before:
Server with VMDKs on datastore A, mapped on the Windows Server as drive D:. Full/new backup created.
After:
Same server with VMDKs ob datastore B, mapped on the Windows Server as drive E:, a large partial set of files moved from D: to E:. Using always incremential update.
So dedup only works on a disk-sector basis? This makes it pretty much useless, because it requires each VM to-be-deduped to have the exact disk and file setup. Files must stay at the exact same sector on both machines.
- Accedi per poter commentare

Hi ece,
The deduplication is performed on disk sector level rather than on files one which explains the behavior you see. Basically while indeed inline deduplication is most effective when backing up cloned VMs, it is still quite effective when backing up similar VMs (with the same OS or deployed from the same template), since there will be a lot of matches in sectors especially in OS data. The benefit of such deduplication approach is the speed and the drawback is lesser effectiveness.
Note that for better deduplication effectiveness there is "true" deduplication required with post backup dataprocessing on the storage side. An example of such system is Acronis Storage Node component which is a part of Acronis Backup and Recovery product - it stores a database of hashes and compares each new datachunk hash with the existing ones during post-processing stage. The inline deduplication is using an alternative method which is not resources consuming and doesn't require any additional post-processing agent but it's less effective. In fact any product which advertises deduplication without using some kind of post-processing engine is actually using inline deduplication.
Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager
- Accedi per poter commentare

it is still quite effective when backing up similar VMs (with the same OS or deployed from the same template), since there will be a lot of matches in sectors especially in OS data.
I am not fimiliar with the exact details, but I always though the sectors are a chained list, which contain a pointer to the next block, meaning that even the same file across different VMs (unless they are cloned) will not be deduped, because the blocks will differ, as soon as the file start in a different sector (simplified), because the pointer to the next block will be different. Correct?
- Accedi per poter commentare

Hi ece,
The sectors actually are not in a chained list, so there are no pointers inside each sector. But yes - the copied files will not be deduped in case of sector-based deduplication (which calculates the hashes of groups of sectors) since their allignment might be different. The only way to ensure proper deduplication in such cases is to use file-level backup approach (available in Acronis Backup and Recovery for example) which can handle duplicate files as it's file-based.
Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager
- Accedi per poter commentare

Thanks for the feedback, Vasily.
Couldn't you merge VMProtect and B&R into one unified solution with best of both worlds? ;)
Okay, one could dream, right? :)
- Accedi per poter commentare

Hi ece,
Actually these are our plans for the next version of vmProtect (10th one), i.e. to have unified platform for both ABR and vmProtect products :) Can't get into details, but thats something that we are working on now.
Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager
- Accedi per poter commentare
