Reporting on restore points and size used on disk

[mschouren]

Hi,

For reporting and billing I need to know how much disk space each VM takes up in the backup repository.

We are using:
- VBR 6.5
- Reverse incremental, no regular active fulls

I am trying to get the information through the PowerShell API. I managed to get most of the information I needed through the Get-VBRJob and Get-VBRJobObject cmdlets, but I am missing some information:

- Actual restore points on disk for a particular VM (figured this out: this can be done by using Get-VBRBackup and Get-VBRRestorePoint.IsCanBeRestored()).
- Size of each individual restore point and its type (Full or Incremental). I managed to get a part of this information by directly accessing dbo.ReportSessionInfoView view in the database (this got me the size of each session) but I have no idea how to find out what the resulting size of the most recent backup is (since it has become the new full). Also I cannot reliably determine whether this is an incremental or a full/initial.
- Total size of all the available restore points for the VM on disk.

Can anyone please give me a direction?

[veremin]

For reporting and billing I need to know how much disk space each VM takes up in the backup repository.

In fact, it’s not possible to determine how much space is consumed by a particular VM in a given .vbk/vib file.

Actual restore points on disk for a particular VM

Code: Select all

asnp VeeamPSSnapin
$Backup = Get-VBRBackup -name "Name of your Job"
$Backup | Get-VBRRestorePoint | ?{$_.VMName -eq "Name of your VM"} | Sort-Object creationtime –Descending

the resulting size of the most recent backup

Code: Select all

asnp VeeamPSSnapin
$Backup = Get-VBRBackup -name "Name of your Job"
$Backup.GetStorages() | Sort-Object creationtime | Select-Object -last 1 | select id, creationtime, {$_.stats.backupsize} 

Also I cannot reliably determine whether this is an incremental or a full/initial.

If you’re not adding VMs to an existing job regularly, you can, probably, rely on the following script. It will get the latest backup file and also VM restore points associated with it, then, the script will output the type of these restore points (full, incremental).

Code: Select all

asnp VeeamPSSnapin
$Backup = Get-VBRBackup -name "Name of your Job"
$RestorePoint = $Backup.GetStorages() | Sort-Object creationtime | Select-Object -last 1 
$RestorePoint.GetOibs().Type 

Hope this helps.
Thanks.

[mschouren]

Thanks. I will take a look at this and see how much information I can get from this.

[veremin]

Should any additional questions arise, don’t hesitate let me know. Thanks.

[AdrianHinton]

Actual restore points on disk for a particular VM

Code: Select all

asnp VeeamPSSnapin
$Backup = Get-VBRBackup -name "Name of your Job"
$Backup | Get-VBRRestorePoint | ?{$_.VMName -eq "Name of your VM"} | Sort-Object creationtime –Descending

Good Sunday morning to you.

I have run the above for some servers and have found that the most recent restore point is not actually available because it is still copying. The latest RP in the VBR UI is 2/08/2014 but Powershell is reporting 8/08/2014 (the one that is currently copying).

[tsightler]

When you say "currently copying" you mean the job is currently running and processing that VM? In that case the restore point technically exist, just in an incomplete state. You can filter out incomplete/inconsistent restore points by using either the IsConsistent or IsCorrupt properties (I'm not really sure the difference). Here's some code that uses the IsConsistent flag to list only restore points that are complete:

Code: Select all

asnp VeeamPSSnapin
$Backup = Get-VBRBackup -name "<Job_Name>"
$Backup | Get-VBRRestorePoint | ?{$_.VMName -eq "VM_Name" -and $_.IsConsistent -eq $true} | Sort-Object creationtime –Descending

Of course, this only means that the restore point for that specific VM is complete, if the job is long running the backup file containing that point might still be busy and this get's a little more complex to detect, but should be possible with a few more lines.