Corrupted hdd after restore

[dter]

Hi,

my name is Dimitris,
pls let me introduce my infrastructure before publishing my issue

i have a VBR server and taking backups via proxies to an HPE StoreOnce dedup applance. let's named it Repo1.
i am using backup copy jobs to copy these backups to a windows 2019 server with ReFS, 64K, deduplication enabled. let's named it Repo2.
i am using backup copy jobs to copy these backups to a different HPE StoreOnce located at my DRS. let's named it Repo3.

i did a number of restores and instant recoveries using point of time from Repo2 and unfortunately the recovered vms were unable to read from hdd - boot.
They moved to PXE !

no issues wiht backup jobs stored to Repo1 and Repo3

i already opened a support ticket: Case # 05152018

any ideas ?
thanks in advance for your assistance

[Gostev]

Hi, I recommend you disable Windows deduplication as it does not work well with ReFS. There are plenty of existing discussion here about some of the issues with this combination...

[dter]

Hi Gostev

thank you for your prompt response

let me ask this one:
windows 2019 server with ReFS and Dedup is not a supported repository or it may lead to various issues like mine ?
is NTFS a better option ?

thank you in advance

[Gostev]

Naked ReFS is always the best option and is what vast majority of our customers are using.

While NTFS with deduplication is the proven combination from the early days, it does not make much sense these days because of much processing overhead for no good reason. With NTFS repositories, duplication is first created due to multiple full backups storing largely the same data, and then Windows deduplication removes this duplication. This is really sub-optimal. Our ReFS integration on the other hand prevents duplication from happening in the first place, thanks to block cloning allowing those full backups take no physical disk space to start with (instead, they just point to the existing blocks already present on the volume).

In general, at least with backups you always want to avoid any extra data processing like external deduplication as much as possible because every data transformation introduces a risk of data loss or corruption. But with backups being your last hope, you want them to be as reliable as possible. We don't do backups to save money or storage, we do them to be able to recover in the time of need (and do it fast).

[dter]

May i assume that you prefer/suggest Refs with fast clone and appropriate configuration on backup copy jobs ?

thank you

[Gostev]

That is correct.

[dter]

ok - got you

a last question:
is it possible to use the same backup job ?
i believe that i have to do a full for the first time. i may be wrong

pls can you assist what is the fastest/safest - may be different - to "convert my backup copy jobs" ?
i know that i have to click on storage and... next... next in order to find that this is a ReFS capable repository
or i have to recreate them ?

thank you for your patience and assistance

[Gostev]

That is correct. You should be able to continue with the existing job, but block cloning will only be active after the first full backup to the ReFS repository (for the following synthetic full backups).

[Gostev]

You can check to see if Veeam detected your repository as capable of block cloning by checking the Align backup file data blocks checkbox state in the advanced backup job asettings... it should be checked and disabled at the same time (this is done on purpose to prevent users from changing its state).

[dter]

it is already detected - nice

you wrote:
block cloning will only be active after the first full backup to the ReFS repository (for the following synthetic full backups).

pls, let me clarify to check if i correctly understand you, I am using Incremental with periodic synthetic full.
if i correctly i understood you, block cloning will be active after the first-next synthetic full

supplementary, it would be a good option to change the compression level for copy jobs to optimal - now is none

thank you

[Gostev]

Yes, your job settings are already correct for block cloning to be leveraged.

[dter]

thank you for your time