Hi
I like the concept of the VM Change Rate Estimation report, as we're trying to gauge how much bandwidth we need for Veeam Backup. I see that it tries to predict changes blocks based on the VM write rate.
In our case I'm seeing that our Veeam SQL VM is writing about 750GB-1TB of data per day. However, the VM's disks are only 250GB in total, so if we assume all blocks change, the max required would be 250GB if we backup once per day. Would it be possible for this report to have an option to cap the change rate to the size of the disks? I know I'm probably expecting too much, but it would make the report far more accurate if we could do this!
Thanks
Matt
-
- Enthusiast
- Posts: 36
- Liked: 5 times
- Joined: May 23, 2013 2:57 pm
- Full Name: Matthew Ray
- Contact:
-
- VP, Product Management
- Posts: 27368
- Liked: 2799 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: VM Change Rate Estimation report
Hi Matthew,
That's actually a good idea, however if all changes are written to the same blocks, then the CBT driver will return less data than it is displayed in the report. Unfortunately, we cannot track this kind of activity based on the write rate counter. And yes, SQL Servers/Exchange VMs are well-known for the huge number of changes produced every day.
Thanks for the feedback!
That's actually a good idea, however if all changes are written to the same blocks, then the CBT driver will return less data than it is displayed in the report. Unfortunately, we cannot track this kind of activity based on the write rate counter. And yes, SQL Servers/Exchange VMs are well-known for the huge number of changes produced every day.
Thanks for the feedback!
-
- VP, Product Management
- Posts: 6035
- Liked: 2860 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: VM Change Rate Estimation report
When this report was designed I had thought about this possibility, as certainly the same blocks might change mulitple times during the day, however, it's impossible to know if a user is only going to replicate once a day, or once every 15 minutes, and the end result regarding the amount of data transferred would be significantly different in those cases.
To my mind, the purpose of the report isn't to show how much data will be transferred, but rather to help identify the relative change rates of various VMs in their environment to allow for the human designing the solution some additional information to better estimate the potential data transfer in any given backup or replication scenario. For example, the report doesn't take into account any savings from compression or from WAN acceleration either.
To my mind, the purpose of the report isn't to show how much data will be transferred, but rather to help identify the relative change rates of various VMs in their environment to allow for the human designing the solution some additional information to better estimate the potential data transfer in any given backup or replication scenario. For example, the report doesn't take into account any savings from compression or from WAN acceleration either.
-
- Enthusiast
- Posts: 36
- Liked: 5 times
- Joined: May 23, 2013 2:57 pm
- Full Name: Matthew Ray
- Contact:
Re: VM Change Rate Estimation report
Hi Tom, yes you have a good point as you cannot assume that a VM will be backed up once per day. Indeed, we have some servers which are backed up 4 times per day, so my suggestion wouldn't be appropriate for these VMs.
-
- VP, Product Management
- Posts: 27368
- Liked: 2799 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: VM Change Rate Estimation report
Agree, Tom's use case has completely slipped my mind, however if you set "current day" as a reporting period, the report will give you the estimation of how much data is changed for each hour during the day. Should be useful.
Who is online
Users browsing this forum: No registered users and 1 guest