Feature Request: Cmdlet to query repository usage by VM/agent/share/...
We would like to issue a feature request to get more data about storage usage in repositories. Often storage use by VM or agent or share is used as a base for customers internal accounting.
Cmdlet name proposal
Get-VBRRepoUsage
Filter options proposal
The Cmdlet should support the following filters
* name [optional]: Name of VM/agent/share/...
* type [optional]: Filter by type VM/agent/share/...
* repository [optional]: Filter by repository name
* job [optional]: Name of the job issued the backup
Output proposal
For each combination of saved object, type, repository and job there should be an output object.
Name,Type,Repository,Job,Amount Logical Bytes,Amount Physical Bytes
VM1,vm,repo-1,backup job 1,10000,1000
Server-1,agent,scale-out-2,backup job 2,20000,525
//nas-1/users,share,scale-out-2,backup job 3,5000,100
VM1,vm,repo-2,backup job 4,10000,250
Amount Logical Bytes = Amount in bytes before compression deduplication
Amount Physical Bytes > Amount in bytes after compression deduplication stored in repository
Conclusion
Feedback for this request like improvement ideas are strongly welcome.
Best wishes
Stefan
-
- Influencer
- Posts: 23
- Liked: 2 times
- Joined: Feb 21, 2013 11:53 am
- Contact:
-
- Product Manager
- Posts: 10099
- Liked: 2693 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Feature Request: Cmdlet to query repository usage by VM/agent/share/...
Hi Stefan
Thanks for the request.
I moved it to the PowerShell subforum because it's PowerShell related.
You are talking about logical, physical size in your example.
Is it about FastClone space savings with reFS/XFS?
Currently Veeam Back & Replication doesn't know anything about it, because the filesystem doesn't provide such information directly.
But we are researching this topic what can be done in a future version.
Best,
Fabian
Thanks for the request.
I moved it to the PowerShell subforum because it's PowerShell related.
You are talking about logical, physical size in your example.
Is it about FastClone space savings with reFS/XFS?
Currently Veeam Back & Replication doesn't know anything about it, because the filesystem doesn't provide such information directly.
But we are researching this topic what can be done in a future version.
Best,
Fabian
Product Management Analyst @ Veeam Software
-
- Influencer
- Posts: 23
- Liked: 2 times
- Joined: Feb 21, 2013 11:53 am
- Contact:
Re: Feature Request: Cmdlet to query repository usage by VM/agent/share/...
Hi Mildur,
thanks for your reply and moving the topic to the right forum. Regarding your question:
>You are talking about logical, physical size in your example.
>Is it about FastClone space savings with reFS/XFS?
From my point of view this is a general thing that has to be independet of the storage and file system.
I´ll try to explain in an example.
Example VM Backup
When backing up a VM Veeam reads an amount of data that has changed and needs to be backed up. I refer to this a logical size - of course you can use other wording finally. Then Veeam starts to work on this data uses dedup and compression. Some data is left and it is written to a repository. This is what I refer to as physical size.
Background: Some Veeam customers we see using the "logical size" and some the "physical size" to bill their departments for backup costs. Therefore both values are important. A total amount per VM/Agent/... per repository per job would solve this task.
Current status of PowerShell Cmdlets is that you can query these value only if a repository is set to "PerVm" saving.
Best wishes
Stefan
thanks for your reply and moving the topic to the right forum. Regarding your question:
>You are talking about logical, physical size in your example.
>Is it about FastClone space savings with reFS/XFS?
From my point of view this is a general thing that has to be independet of the storage and file system.
I´ll try to explain in an example.
Example VM Backup
When backing up a VM Veeam reads an amount of data that has changed and needs to be backed up. I refer to this a logical size - of course you can use other wording finally. Then Veeam starts to work on this data uses dedup and compression. Some data is left and it is written to a repository. This is what I refer to as physical size.
Background: Some Veeam customers we see using the "logical size" and some the "physical size" to bill their departments for backup costs. Therefore both values are important. A total amount per VM/Agent/... per repository per job would solve this task.
Current status of PowerShell Cmdlets is that you can query these value only if a repository is set to "PerVm" saving.
Best wishes
Stefan
-
- Product Manager
- Posts: 10099
- Liked: 2693 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Feature Request: Cmdlet to query repository usage by VM/agent/share/...
Hi Stefan
I understand now. Thanks your your explanation.
You mean "data read" per VM from the job session details?
Per-VM is the new default in Veeam V12. And it's now available in all editions of Veeam Backup & Replication. For Backup copy jobs this format is mandatory.
I'll share your request with the team. From time to time we get similar requests for better gathering of workload information on our repositories.
Best,
Fabian
I understand now. Thanks your your explanation.
You mean "data read" per VM from the job session details?
If you have PowerShell Cmdlets for "Per-VM" chains, your request would be mainly to also cover "Per-Job" chains?Current status of PowerShell Cmdlets is that you can query these value only if a repository is set to "PerVm" saving.
Per-VM is the new default in Veeam V12. And it's now available in all editions of Veeam Backup & Replication. For Backup copy jobs this format is mandatory.
I'll share your request with the team. From time to time we get similar requests for better gathering of workload information on our repositories.
Best,
Fabian
Product Management Analyst @ Veeam Software
Who is online
Users browsing this forum: No registered users and 26 guests