Size needed for restoring a VM

[stack111]

Hi,

I have a VM with four fixed VHDX files configured and total size of 21.3 TB, the used space in these four VHDX files is around 165 GB, is a space of 200 GB enough for doing a restore for this VM for testing or we need to present a LUN of 22.3 TB which is same as VHDX files total size?

[Mike Resseler]

Hello Ahmad,

If I read correctly, I see that those four disks are fixed. Which means their actual size (also today) is 21.3 TB. So I am afraid you will need that size to be able to do the restore.

[stack111]

Hi Mike,

The problem is that our customer does not have a 21.5 TB available space to test restore for this VM,...

Isn't there any way to test the restore for the whole VM without having this needed space?

[Mike Resseler]

Ahmad,

Is it only for a test? In that case I suggest that you look into datalabs. https://helpcenter.veeam.com/docs/backu ... tml?ver=95

This is a much easier way of testing your backups, can be fully automated and tests can be performed inside. Did you already looked at this?

[stack111]

Mike,

This is for test only to verify and confirm success of restore in case of a disaster.

I did not check SureBackup before, I will check it and see how to use it.

Thanks

[Mike Resseler]

That is exactly what SureBackup does so please check it out and let us know!

[stack111]

Yeah I checked it but it failed, I logged a case with Veeam support, they informed the below

"The failure is due to the fact that the VM was not started in the allotted time. SureBackup is a technology that heavily depends on random Read/Write I/O, meaning that if a storage device can not provide that appropriate level of I/O the technology will have trouble performing as expected. There is no "fix" that veeam can provide to speed up the datadomain's random read/write I/O to make the SureBackup run faster."

They asked me to update Veeam to the latest version which is 9.5.0.1922 and try the surebackup job from the newest restore point, I am currently upgrading Veeam to the lates version then will check after that if anything changes.

[stack111]

I upgraded Veeam to the latest version 9.5.0.1922 and tried again but same error...

[csydas]

the datadomain's

Ouch Sorry man, but there's your problem right there. Dedupe + SureBackup is always a headache. The DataDomains are great for long-term retention, but only the high-ends are usable for a lot of the cooler functions of Veeam like SureBackup and Instant Recovery.

You can either try increasing the wait for boot timeout to an outrageously large number, or just try an instant recovery and wait until it shows.

Sorry to say, but it sounds like just an unfortunate architectural situation here. You don't want to hear this, I'm sure, but you might want to look into a dedicated local repository (ReFS or BTRFS) and use it as a short term backup for this server.

[stack111]

The problem is that we have two veeam servers, each one connected to an EMC datadomain with deduplication enabled, all VMs are stored on this backup repository, this is a big issue indeed...

If we try an instant recovery, do we need a space equal to the actual VM size or higher a little bit on a host or this is not needed?

[csydas]

No space on the actual datastore should be needed - it runs 100% off the backup repository since Veeam makes a VMware NFS datastore via the vPower NFS Datastore thing you set up during a Repository set up. So Instant Recovery should work without you needing additional space on production.

I see you're HyperV though, so I __think__ it's the same, but not entirely sure.

[stack111]

I tried instant VM recovery on the VM..it took around 17 minutes for the VM to boot (to the state it asks for username and password); the performance is bad...might be because it is being read from deduplicated EMC data domain.

But during the instant recovery wizard, it do ask for a place to store the restored VM files, so at the end it needs space (new LUN)..

[Regnor]

This is only meant for caching and storing changes; all other data is read from the backup files.

Performance of all types of restores decreases on dedup appliances. Because of that it's recommended to have a smaller and faster disk space where you store the most current backups and do all disaster restores. The dedup appliances are secondary targets for long term retention.

[Mike Resseler]

Regnor is correct.

You don't want to modify your backup file so we store the differences somewhere else. It won't be that much unless you decide to go testing updates and other stuff in that job (PS: that is actually a great use-case for SureBackup also ). After the job is finished, we remove the differences data