Hyper-v backup ( Backing up same volume twice )

[Zach123]

Hi All

We are backing up Windows 2012 Hyper-V cluster using Veeam 9.5 update 4b.VMs requiring protection configured with pass-through disks and hence Veeam agents are used.

We are backing up servers from the Hyper-V cluster. We have observed that the same volume is getting up twice, once from each cluster node.

Can someone verify if the configuration is correct?

Should we be using an individual computer in the backup selected instead of using the protection group? That way we can specify what to include/exclude from each computer.

We do not want to back up the same data twice consuming additional storage and bandwidth. Refer to the link below for screenshots

https://drive.google.com/file/d/18nGGHW ... sp=sharing

Pardon me for my limited knowledge of Hyper-V.

[Zach123]

Hi All

We are backing up Windows 2012 Hyper-V cluster using Veeam 9.5 update 4b. Cluster backup is configured with agent installed on both the nodes.

Looking it the backup job details, it's evident that it's backing up shared volumes only from one server ( active node). When checked in the restore window, it still shows the same volume attached to both the servers... Is that ok?

Also, looking at the copy job it tries to copy the same volume from both the servers. should that be the case?

https://drive.google.com/open?id=1vLIhZ ... a-S7mMvamO

We just had an active full copy backup and was not expecting the copy job to copy all those volumes in the next incremental copy jobs.

https://drive.google.com/open?id=1vLIhZ ... a-S7mMvamO

[Dima P.]

Hello Zach123,

Can you please clarify if the agent backup was configured with failover cluster job type or not?

Looking it the backup job details, it's evident that it's backing up shared volumes only from one server ( active node). When checked in the restore window, it still shows the same volume attached to both the servers... Is that ok?

Shared volume should be backed up only once from the active node. It's available for recovery to both nodes.

We just had an active full copy backup and was not expecting the copy job to copy all those volumes in the next incremental copy jobs.

Can you please clarify what repository is used as a target for backup copy job? Thank you in advance!

[Zach123]

Hi All

Sorry for the delayed reply

a) Yes, the agent backup job is configured using the Failover Cluster job type. ( Please refer to the link provided in the post for screenshots) . There are no issues with primary backups.
b) The primary backup goes to the local ReFS repository whereas copy job going to cloud connect repository.( Not sure but I guess cloud provider is using Linux repository)

When I checked the backup files created on cloud connect repository, I can see two backup files, one for each node of the cluster as the repository is configured with per-VM backup. Both the files are of the same size but with different names of course.

Here the screenshot of the backups available in cloud repository two nodes in the same cluster. The file size looks the same for both the servers and hence consuming additional space on the storage. In my understanding, but backup files present on the repository should be of different sizes as from one node on just couple of drive gets backed up.

https://i.imgur.com/q5vEmmi.png
https://i.imgur.com/JHbmfWc.png

Whereas the primary backup looks fine. From one node it backups up below volume

(C:) (29.3 GB) 6.6 GB read at 216 MB/s [CBT] 00:30
Data (D:) (104.5 GB) 177.0 MB read at 177 MB/s [CBT] 00:03
2008-SQL-RMS-LOGS (J:) (599.9 GB) 312.8 GB read at 542 MB/s [CBT] 09:52
Tier2-2008-SQL-RMS-BACKUP (O:) (299.9 GB) 13.7 GB read at 477 MB/s [CBT] 00:31
2008-SQL-EMS-LOGS (E:) (499.9 GB) 111.1 GB read at 816 MB/s [CBT] 02:20
2008-EMS-DTC-BKUP2 (I:) (199.9 GB) 104.0 MB read at 104 MB/s [CBT] 00:02
2008-SQL-RMS-TEMPDB (N:) (70.0 GB) 95.0 MB read at 95 MB/s [CBT] 00:02
2008-SQL-RMS-PROD-ROLL (M:) (299.9 GB) 10.2 GB read at 79 MB/s [CBT] 02:14
2008-SQL-RMS-BACKUP (L:) (399.9 GB) 126.3 GB read at 57 MB/s [CBT] 37:30
2008-SQL-EMS-TEMPDB (G:) (50.2 GB) 7.7 GB read at 182 MB/s [CBT] 00:45
2008-SQL-EMS-DATABASE (F:) (419.9 GB) 372.3 GB read at 819 MB/s [CBT] 07:46
2008-SQL-RMS-DATABASE (K:) (1001.8 GB) 419.9 GB read at 487 MB/s [CBT] 14:44
2008-SQL-EMS-BACKUP (H:) (749.9 GB) 646.1 GB read at 186 MB/s 59:15
SQL_2008_CLUSTER_QUORUM (Q:) (33.0 GB) 94.0 MB read at 94 MB/s [CBT] 00:02
Finalizing 00:56



and from the other node, it backups up only C and D which makes sense.

SYSTEM (C:) (29.3 GB) 7.4 GB read at 188 MB/s [CBT] 00:39
Data (D:) (104.5 GB) 203.0 MB read at 203 MB/s [CBT] 00:03
Finalizing 00:54

[Dima P.]

Hello Zach123,

The deal is that whenever per-VM chain is enabled on the repository where you land backup copy job, it will store the shared disk within every node. You can disable per-VM backup chain option to store all nodes within a single backup, in such case shared disk will be stored only once. Cheers!

[Zach123]

Hi Dima

Thanks for confirming that. We should have thought before enabling per-VM on the repository.

The reason we switched to per-VM for our copy operation was the merge operation was taking a few days to complete. The size of the incremental backups was around 1.5 TB and full-back around 10 TB. We are keeping 100 restore daily restore points and 12 monthly GFS restore points.

It was suggested by Veeam and Iland support to have per-VM backup enabled on the cloud repository for the faster merge operation.

But I guess with per-VM enabled , we have created more issues than solving them. Over the period of time, we'll have shared disk getting backed up twice and also losing the ability to do deduplication on job level.

[Zach123]

Hello Zach123,

The deal is that whenever per-VM chain is enabled on the repository where you land backup copy job, it will store the shared disk within every node. You can disable the per-VM backup chain option to store all nodes within a single backup, in such case shared disk will be stored only once. Cheers!

We checked with the cloud vendor and the repository is shared between multiple tenants and hence they can't disable the Per-VM backup option on the repository.

What I have done is that in the primary backup, I have changed the Job mode from "Failover Cluster" to "Server" and specified the cluster nodes separately.
After this change, backup and copy both are saving the shared disk only once, which is what we want.

What is the downside of doing this? What additional steps will be required in the case of a single node or complete cluster fails?