SureBackup change file

[cffit]

I have a SureBackup lab up and running. I'm actually testing enabling and running the data deduplication feature of Windows 2012. But I just happened to see my C: drive on the VEEAM backup server is losing space now. Does the C:\ProgramData\Veeam\Backup\NfsDatastore\"vm_name_randomnumbers" folder hold all the "changes" like a delta file for VMs in a SB lab? If that's the case I won't be able to test this as the data deduplication will run over 1TB of data through it.

I was just hoping to understand better how SureBackup worked and where it stores things.

[veremin]

You are on Update 2b, aren't you? A VDDK bug introduced in vSphere 6 forced us to change the way we store changes for SB jobs. Now we store all changes in cache files on the NFSDatastore folder configured in the repository, similar to Instant VM Recovery. That's what you're probably seeing. Thanks.

[cffit]

That's kind of dangerous beings we have that on our C: drive, and doing anything that makes a lot of changes will then fill up the system drive. Thanks for confirming. I will adjust accordingly.

[cffit]

This change has really damaged my SureBackup jobs since it came about. Since now these change files are located on the same disk as the server OS and VEEAM application and it's only a mirrored drive. Is there any way to point these files somewhere else? Should I install a SSD drive in the server and have it use that somehow?

The disk latency is so bad that I literally can't get into my VM's that boot up in SureBackup.

[veremin]

Is there any way to point these files somewhere else?

Select different folder for NFSDatastore in the repository settings.

Should I install a SSD drive in the server and have it use that somehow?

I believe it's likely to increase the performance.

Thanks.

[cffit]

I'm really struggling with this. SureBackup used to work so well two years ago, but now it's so slow I can't use it and it seems to correlate with this change to put the cache files on the NFSDatastore.

When I look in VEEAM ONE at the write latency on this datastore it can get to be up to 600ms while a SB job is running. When I look on the VEEAM server itself it doesn't show that the disk queues are piled up. Am I the only person noticing this problem?

[cffit]

I changed my NFSDatastore to our SAN and that helped some, but it's still almost too slow to use. What is my optimal configuration to make my SureBackup labs run faster?

[nefes]

Are you still on v8? I believe in v9 this should be fixed.

[cffit]

We are on v8 still, planning to move to v9 here before too long.

When you say it is fixed, what do you mean exactly?

[nefes]

I mean right after registration of VM snaphot is being created, thus redirecting delta to the datastore where VLab created.

[cffit]

So here's where I'm at:

SureBackup used to work great in the past. Now in the last 2 years it has been super slow.

I'm trying to resolve this. I'm also deciding to purchase new hardware for our VEEAM server and backup storage, and I want to make sure I spend the money wisely.

I'm confused how this all works and what disk is used for what. I'm not sure how to resolve this. I'm not sure whether I need to spend money on faster backup disk? Or if I need to use SSD drives for the location I point the change files to? Or where the change files go and if that changes between v8 and v9? And if it does change in v9, can you specify the location on local disk or does it have to go to a datastore where the vLab is?

I've called support multiple times and I feel like the support persons don't know any more about this than I do.

[Vitaliy S.]

Hi Christensen,

I'm not sure how to resolve this. I'm not sure whether I need to spend money on faster backup disk? Or if I need to use SSD drives for the location I point the change files to?

Let me try to clarify this for you. If you want to get decent performance for your SureBackup job, then you still need to invest into destination storage (backup repository), cause backups are "opened" on the fly. Now, the change Nikita is referring to also affects SureBackup job performance, as in v9 delta (changed data) is now written to the production datastore where vLab is registered on.

That said, if you want to have max performance, I would suggest looking into these components configuration.

Or where the change files go and if that changes between v8 and v9?

Between v8 and v9 it was changed, and now all the changed are written to a disk where vLab resides.

And if it does change in v9, can you specify the location on local disk or does it have to go to a datastore where the vLab is?

The second.

Hope this helps!