SOBR Extent Evacuation believes Dedup Appliance to be full

[mengl]

I have an issue evacuating my Backups from a ReFS extent to a dedup appliance in my Scale Out Repository - VBR 10 RTM

The SOBR contains two extents.

• ReFS
  - multiple Jobs creating synthetic full backups using block cloning --> 10TB raw / 0.9 TB used
• HPE StoreOnce
  - 1 TB
  - Connected via catalyst
  - empty at the moment

When I start evacuation of the ReFS extent, Veeam starts moving the first 5 synthetic full vbk (each ~ 200 GB) and throws an error for all other files:

Code: Select all

Failed to dispatch pending task [..] No scale-out repository extents have sufficient disk space to store the backup file. 

For a "regular" (non-dedup) extent this makes sense. But in this use case everything will fit in the dedup appliance.
My current workaround is to start the evacuation job as many times as necessary until al files are moved.


I think this behavior should be changed.
When the target uses inline deduplication the move task should check after each batch of files if there is free space available and continue on the next files.

[Mgamerz]

Doesn't ReFS do a pseudo dedup by not storing duplicate blocks? Which is why if you were to just copy your VBK/VIB files to another drive it would actually take way more space? (I have a 35TB repo that currently has over 77TB of backup on it without refs dedup on).

It's an issue I've made a post about here before, but you cannot evacuate backups like veeam support will tell you sometimes because there is no way to do it without huge space requirements, even though veeam recommends refs.

[foggy]

In addition to rehydration from ReFS, space estimation is not dynamic and done at the start of the evacuation process. Considering this and since Veeam B&R is not able to predict how the data will be deduplicated, additional space is required for the process to complete successfully.

[soncscy]

Interesting thread.

Maybe sort of stupid idea, but would it work if it was done one by one?

I have an idea in my mind of locking 4 of the 5 fulls first (instantly I think of a file restore), then start the evacuate -- would Veeam queue and calculate all 5 points or would it only queue and calculate for the unlocked point in this scenario?

[foggy]

Interesting idea, but you must put the extent to the Maintenance mode before you evacuate backups from it, so restore operations will not be available.

[soncscy]

Hrm,fair point. What about using powershell with the File.Open Method?

Something like [System.IO.File]::Open('path to vbk','Open','Read','None')

Then just close it out when the evacuate is done?

[foggy]

Doesn't seem like a solid approach to me. I haven't tried that but it could fail the entire process upon not being able to access one of the files it tries to evacuate. You can try though.

[mengl]

In the end my workaround was to use Powershell and start the evacuation job in endles loop until every file moved:

Code: Select all

while ($true)
{
	$scaleoutrepository = Get-VBRBackupRepository -Name "SOBR2" -ScaleOut
	$extent = Get-VBRRepositoryExtent -Repository $scaleoutrepository | select -skip 1
	Start-VBRRepositoryExtentBackupEvacuation -Extent $extent; Start-Sleep 120
}

For ReFS the "real" capacity calculation could be quite easy. Just take the transferred size of all jobs. For a sysnthetic full everything else is just a pointer and therefore most likely to use no additional space in dedup appliance.