Moving client SAN data from physical to virtual rdm and backups. Will this be a new 'full'?

[RecoveryOne]

So been giving this one some thought and for the life of me, can't see a way around this.
Situation:
50Tb of data presented as multiple volumes from san to physical Win2k8 server. Volumes will be removed from the 2k8 and presented as rdm to 2016 server inside of VMWare. Not concerned about using TDP to back this up, plan on excluding the disks if they are vrdm, or setting the flag to ignore prdm volumes.

What I'm concerned about is, even if we did the same drive letter and mappings, with the same dsm.opt file copied over and node name from the retired box, this will be in effect a full fresh backup won't it?

Normally I'd not be worried as data reduction would level things out. In this case, no data reduction is being performed. Hits a non deduplicated file pool and migrates off to tape for primary storage. So, I will end up burning a lot of tapes for a new fresh ingest. So much so that I may not have enough scratch. I have a workaround to address that, but would like to avoid if possible.

Thought I'd ask here and see if anyone has any tricks up their sleeves to prevent this from becoming a new 'full'.

Thanks and stay safe out there.

 

[marclant]

What I'm concerned about is, even if we did the same drive letter and mappings, with the same dsm.opt file copied over and node name from the retired box, this will be in effect a full fresh backup won't it?

New a few more things to avoid a backup:
- hostname would need to be the same, the filespace name is \\hostname\driveletter
- it's also possible you may need to change the machine SID on the new machine to match the old one. I remember having to do that when I migrated a server from NT4 to W2K using Robocopy, but I think that was more related to file permissions, not to avoid backup


My recommendation would be to test. The physical to virtual is not an issue. So you could create a test VM, add a small volume, put files, back them up. Then move that volume, nodename and hostname to another test VM (need to power off the 1st test VM), and see what it does.

 

[RecoveryOne]

Marclant,
Kinda what I was afraid of. New hostname and the box isn't getting a new SID either. Was hoping for one of those hidden gems of TSM.
Yeah, looking at trying to test out some other ideas. Abusing asnodename has came to my mind for example.

Oh this is going to be painful! Time to play the data shuffle.

Thanks!

 

[marclant]

Oh wait. It's possible to rename a filespace.

I'd test the @#%$&^ out that with a couple of test systems though.

 

[RecoveryOne]

Ohh...yes...That may work.
Thanks! Don't think I've ever ran a rename filespace before.
Well, time to poke about and see what I can break.

Thanks!

 

[reesema]

I've done the rename filespace trick several times when moving to new servers. It works great and avoids the full backup.

 

[RecoveryOne]

reesema,
That is good to know! Still working on standing up a test system. Time flies but also moves slowly at times.

Thank you.