Backup-task saves whole VM

[kapa-aw]

Hello,

i got a problem with a backup-task.
Veeam B&R 4.1 saves a whole VM although I exclude one vHDD.
This VM consists of three HDD. The third one should be excluded.
I created this task as a new one, with a new destination path.

I don't know where the problem is.
Hope you can help me.

Some Infos:

I use vcb with network mode, destination path is on a NAS.

best regards.

[Vitaliy S.]

Hello,

Yes, that's true, I've just confirmed it with our QA Team, it relates to VCB specific jobs only, in this case I would definitely recommend you to use vStorage API mode instead, it will not affect your current jobs and you will be able to leverage all the benefits of this mode such as CBT for example.

Thank you!

[kapa-aw]

Thank you for your answer.

I switched now the task to VMware vStorage API with Network mode.

What's the different between this modes?

Can I use "Network backup" also?

Another question: sorry about that, but what's CBT?

[Vitaliy S.]

vStorage API is the VCB successor. vStorage API "Network mode" is essentially the same as VCB Network mode.

For more detailed information about vStorage API please refer to the stickied FAQ topic. CBT is a change block track technology that was introduced with vSphere, which allows us to instantly determine VMDK changes during incremental backups.

Thank you!

[kapa-aw]

Hm, "vStorage API with Network" and "VCB with Network" are the same?
With vStorage API the backup works normally, the third HDD is now excluded. Curios.

Edit: I don't use a shared storage (SAN). The ESX-Host is a standalone host with local storage. The backup will be saved on a NAS.
In your FAQ I've readed that in case a SAN is used the backup speed is 3 - 4 times faster in vStorage API SAN mode than vStorage API network mode or VCB.
Can I use it with local storage, too?

(Sorry for my english )

Thx 4 h3lp

[Vitaliy S.]

Yes, it is almost the same. And as vStorage API is a VCB successor, you can use this mode to configure all your jobs without having any impact.

[kapa-aw]

Sorry, I've edited my post.

[kapa-aw]

I've got a notification from a backup task:

Enabling changed block tracking... Changed block tracking cannot be enabled: one or more snapshots present. Retrieving VM disks information... Disk "[Datastore_1] server1/server1_2-000002.vmdk" has been skipped

Is it possible that any problems will be occuring while we recover this backup based on the skipped vmdk?

[Vitaliy S.]

As a destination target you can use any storage device (local storage as well) for SAN mode, you just need to configure Veeam Backup Server to work in SAN mode.

For enabling CBT you should remove the snapshot for that disk, after that CBT will be enabled and you may create snapshots again if needed.

[kapa-aw]

Are there any known problems, when I remove the snapshots during the working time?

[Vitaliy S.]

Generally, it depends on the size of the snapshot, because if it is large enough there could be a little downtime as the final commits are made, I recommend you to do it in non-working time just to be safe.

[kapa-aw]

yes, I think so too. I'll be waiting until the customer(s) are @ home

[kapa-aw]

What's that?
I've deleted all snapshot with the esx snapshot manager and Veeam B&R saves my VMs with vStorage API in network mode with different speed.
4 VMs will be saved every day and 3 of them got a processing rate of 150 mb/s to 470 mb/s.
The main-vm backups with 35 mb/s. What's the reasen of that big different?
All VMs got the same backup mode.
Backup mode: NBD with changed block tracking

Total size of VMs to backup: 298,11 GB
Processed size: 298,11 GB
Processing rate: 148 MB/s
Start time: 05.02.2010 03:00:23
End time: 05.02.2010 03:34:52
Duration: 0:34:28

Total size of VMs to backup: 55,94 GB
Processed size: 55,94 GB
Processing rate: 426 MB/s
Start time: 04.02.2010 19:00:25
End time: 04.02.2010 19:02:40
Duration: 0:02:14

Total size of VMs to backup: 19,12 GB
Processed size: 19,12 GB
Processing rate: 259 MB/s
Start time: 04.02.2010 19:35:30
End time: 04.02.2010 19:36:45
Duration: 0:01:15

Total size of VMs to backup: 228,36 GB <-- main vm
Processed size: 228,36 GB
Processing rate: 35 MB/s
Start time: 04.02.2010 22:52:26
End time: 05.02.2010 00:42:24
Duration: 1:49:58

[withanh]

What runs on the main vm? If it's something database related i.e. SQL or Exchange, then these speeds are typical. The databases inherently write lots of changes, especially Exchange, which results in lots of blocks changing. Lots of changed blocks means slower backup because it has more stuff to do. The other machines either have few writes (which means fewer changed blocks) or lots of white space (empty disk) and skips that during incremental backups.

Hope you're enjoying Veeam Backup, it's a fantastic product!

h

[kapa-aw]

On the main VM are some sql databases.
This weekend a VM was saved with 2GB/s ...

You're right, Veeam B&R is very nice - easy to handle