- Service Provider
- Posts: 41
- Liked: 1 time
- Joined: Sep 09, 2016 6:15 pm
- Full Name: Adam Fisher
Also curious, in the case of HCI where there may be one overall storage container with global inline dedupe, if the the production VM and the backup repository happened to live in the same container (this is slightly theoretical ) how big would the backup of a specific VM be? I realize this is mainly up to the storage and how it does dedupe, but has anyone seen this in action? Theoretically, the data for that VM is already written on disk for the production VM, so wouldn't the backup file be significantly smaller because of dedupe? Or does the process of Veeam backing up the VM and changing it from VMDK format to VBK format somehow change the blocks enough that the storage could still dedupe the data a bit, but you would really have two versions of "similar" data on disk, one for the prod VM and one for the backup file?
- Posts: 346
- Liked: 92 times
- Joined: Dec 13, 2015 11:33 pm
Putting your actual backups on the same storage as your VM's would, in theory, give you a huge dedup rate, but you're getting that because you're then not actually storing a full backup of your VM. If you get a single block corrupted it could affect your VM and your backup because both refer to that block. Additionally if that storage fails, your backup and your live data is gone.
- Posts: 106
- Liked: 27 times
- Joined: Oct 30, 2012 7:53 pm
- Full Name: Chris Jones
Remember, Veeam dedupe only works inside each backup file in a backup chain. If you have this scenario: VBK > VIB > VIB > VBK, dedupe from a Veeam perspective only occurs between blocks inside each of those four files. So you get dedupe between blocks inside the first VBK, then again only on blocks inside the first VIB, and so on. Veeam does not dedupe between backup files.
Deduplication at the storage layer provides deduplication across ALL of the blocks in ALL of the Veeam backup files, so your dedupe rate will be higher (assuming there are blocks to dedupe between files, which there should be if you have multiple full backup VBK files.
You should also ensure the data is decompressed before writing to disk, as storage level dedupe cannot occur efficiently on compressed blocks (same as you do if Veeam is writing to a dedupe appliance).
I'd also warn against storing your Veeam backup files on the same array as your primary storage. You should try to have at least some level of hardware separation for your production and backup data. I understand this isn't always possible, and typically your production storage is the highest performing storage in your environment, so you'd want to use it for fast restores. In this case, I'd recommend using Backup Copy jobs to ensure you have a copy of the required restore points on different media to maximise your data protection.
Users browsing this forum: Bing [Bot], Google [Bot], Majestic-12 [Bot] and 17 guests