HyperV Cluster swap, but keep Veeam backups

[spgsit5upport]

I need to hardware swap Hyper-V Cluster A (iSCSI) with new hardware ClusterB (FC)
I have no final plan how to do it yet, but in the end I would like to know how to keep existing Veeam backups (incremental)

Options for move would be:
1) Downtime (VMs moved via LAN from old cluster storage to new) - in which case the VM IDs would change & I expect Veeam would no longer "consider" the existing backups for incremental

2) Add new 2019 hosts to existing cluster & configure at least one 2019 host to have iSCSI & then do LM? - that should keep Veeam backups, but requires messing with iSCSI on new hosts

3) Add new 2019 hosts to existing cluster & configure at least one old 2012 R2 host to have FC & then do LM? - probably easiest of all & would allow backups to be kept

Am I right/wrong?

Any better ideas anybody?

Seb

[DGrinev]

Hi Seb,

You should migrate VMs within a cluster to preserve their IDs, so Veeam can track them after LM.
Keep in mind that Windows server 2019 isn't supported yet in the current version of the product.
Please take a look on this discussion for additional information.

[spgsit5upport]

That is just plain awful. Not to support product that everybody knew was coming & it is eventually here in a revision that makes it a workable backend!

[DGrinev]

You're right, everybody knew what was coming, but nobody has had it before the GA date, that's why all 3rd party companies outside of Microsoft like Veeam start working towards support implementation right on the release date. Thanks!

[spgsit5upport]

So what is the exact status. Veeam 9.5 U3 works but not supported (to backup VM from 2019 Cluster) or Veam does not work at all?

[DGrinev]

It means that we cannot guarantee you that Veeam will work out of the box without issues, it can just work, but in case of failure we will not able to resolve it. Thanks!

[spgsit5upport]

Time to swap backup solution...

[DGrinev]

I think you've seen the information about Windows 2019 support in the upcoming update which is just around the corner. Thanks!

[spgsit5upport]

So getting back to the original post.

Is there a way to move ClusterA (iSCSI) Server 2012R2 to new separate ClusterB (FC) Server 2016/2016 and keep Veeam jobs.

I am NOT upgrading existing cluster, just move VM data between clusters and then ditch Server 2012R2 hardware

Seb

[foggy]

If both clusters are managed by SCVMM, then VM IDs shouldn't change during migration between them.

[spgsit5upport]

No, they are not managed by SCVMM.
SCVMM is great, but requires two hosts (server & sql server)

It is totally pointless IMO to maintain 2 additional hosts to manage two hosts cluster!

Any option in that situation? Also "shouldn't change" is not very convincing

Seb

[foggy]

In all other cases VM IDs will change, you would need to re-add VMs to the jobs and full data will be read during the next job run.

[nmdange]

If you do a rolling cluster upgrade then the VM IDs won't change, that's the only option without SCVMM unfortunately. SCVMM does not necessarily require two hosts, you can run it within a single VM with a local SQL DB if you want to. Though I'd agree it is still a bit overkill for a small environment.

If you are moving VMs in piecemeal, then the impact to one new the full backup won't be that big.

[spgsit5upport]

I am not doing any upgrade, because as soon as VM are moved., original cluster hardware goes to WEEE

And I certainly do NOT WANT full read on next backup (that is the WHOLE point of it)

[nmdange]

A rolling cluster upgrade doesn't require you to keep your old hardware. You can just take your new 2016 Hyper-V hosts, add them to your existing cluster, live migrate VMs, and then evict the old hosts from the cluster. Once they're evicted, you update the cluster functional level.

Although actually I realized that regardless of how you do the upgrade, there will have to be a full backup on each VM, because the VMs need to be upgraded to the new configuration version for Hyper-V 2016 so Veeam can use the new Resilient Change Tracking feature. Since the change tracking is using a different technology, Veeam has to do a full backup the first time.
https://helpcenter.veeam.com/docs/backu ... ver=95#rct

[spgsit5upport]

And what happens with all the existing backup chains?
Especially to the VMs that are defined to be kept (via backup copy job) for x number of months?

That is 2016 added to 2012R2 cluster. It seems (with info difficult to find) that 2019 cannot be added to 2012R2 cluster in same way, but 2019 CAN be added to 2016 cluster.

What about making 2016 host, adding it to 2012R2 cluster, moving all VMs to it (running or not), evict 2012R2 hosts, upgrade cluster functional level to 2016 & add another host but it being 2019. Move VMs to it, evict 2016 host, upgrade cluster functional level to 2019, add another 2019 host.

Long(er) way, but should work

[spgsit5upport]

If you are moving VMs in piecemeal, then the impact to one new the full backup won't be that big.

I am not worried about backup impact (apart of course needing all the Tbs of free space).
But I need to know what happens to existing backup chains (that are kept for xx months)

[nmdange]

A new full will still be required when you upgrade the VM configuration version from 5.0 to 8.0. However by keeping it in the same cluster, it will be added to the same backup chain. Though even if it wasn't because it was a new cluster, the existing chain would still be there until the retention period expires.

[spgsit5upport]

But if it was a different cluster (hence different VM ID), how would the chain be kept?
It is like apples & pears

[DGrinev]

You're right, even if you map a VM with a new ID to the existing backup chain it preserves the chain, but only as files that has been left by "another" VM.
Retention policy won't remove expired restore points since it tracks VMs retention.
However, previously created RPs will be removed by Retention Policy for Deleted Items. Thanks!