Best way to restore to new drive?

[bhagen]

I have a windows server 2016 VMware VM that has a 2tb D: drive that's too small. Rather than change it from basic to GPT, I've simply created a new drive that's 2.5TB, made it (in the OS) a GPT drive, and formatted it as ReFS / 64k. For now, it's the Y drive.

I have a good set of backups w/forever forward incrementals of the D drive. What's the best way to restore the D drive backup to the Y drive?

1. Change the drive letters of the drives (in the OS) and do a volume restore?
2. Copy all the files to the Y: drive, and then change drive letters after?
3. Just change the d: drive to GPT, lose all the data, and restore the volume?
3. Other?

Thanks!

[HannesK]

Hello,
If I understood you correctly, then the machine is a Veeam Repository.

The main question is, whether you want to continue block cloning? Did you have REFS with block cloning on D:?

If yes, then you need a block copy tool (I used dd in the past) and copy the D volume to Y.

2. works if you don't care about block cloning
4. change the drive letters and run a new active full backup

Best regards,
Hannes

[bhagen]

no, the machine isn't a Veeam repository, and no the question isn't about block cloning; the question is about restoring.

esx1 - esxi host in a remote location. The datastore for this host is on-board; 6x 6TB drives in a raid6 array (at the bios level)
vm1 - a vm (windows server 2016) residing on esxi1
- hdd1 - c: drive - OS, 40Gb
- hdd2 - d: drive - data - 2tb - basic disk - NTFS
- hdd3 - y: drive - newdata - 2.5tb - GPT disk - ReFS
veeamproxy1 - a vm residing on esxi1
backup1 - a physical server residing in the same location as esxi1, configured as the backup repository for all the vms on esxi1
vbr - the main (only) veeam b&r server - a vm in our DR location
vbr console - the veeam console running from my PC in our HQ building, controlling vbr

vm1 - hdd2 is running out of room. I make regular backups of it to backup1

I want to "restore" everything that I've backed up from vm1-hdd2 to vm1-hdd3.

If this were a physical server, I'd shut it down, boot it into clonezilla or similar, and simply clone d: to y:

That's basically what I'm wanting to do.

I can't seem to find a way to do that in Veeam.

I eventually tried doing a file restore job to y:; I got "access denied" errors.
So I just tried one folder (about 400GB) and after 30 minutes the dialog was still just spinning at 0% complete. Seems that veeam is trying to suck 400GB of data from the remote location to the c: drive on vbr (in the DR site) just so it can then push it back to the remote site.

I'm currently simply doing a robocopy from d: to y: within vm1 (in Windows), and some night this weekend I will do a final robocopy and then change drive letters.

I am disappointed that Veeam can't seem to do this very simple task? And/Or, I'm disappointed that I can't figure out how to get Veeam to do this very simple task (without transferring data over the WAN).

Any help would be great!

[soncscy]

Hey bhagen,

You have an image level backup (vm backup) or an agent backup? Agent backups do volume restores like you're thinking about because they actually run inside the guest and get information on the volume layout -- image level backups don't have visibility into the volumes inside the guest since the hypervisor has no visibility into it either.

If you've got the data live still, you're over-thinking the situation I say -- just rsync the live data to the new disk or something.

If you don't want to interfere with users access, then use the instant disk recovery to attach a recovered version of the backup disk to the live VM and to the same thing, but rsync from the instant recovered disk instead.

[foggy]

Harvey is spot on. If you still want to use FLR, make sure the backup repository server is the mount server as well, otherwise, the backup would be mounted to the backup server or console which are remote in your case.

[bhagen]

Thanks for the responses. "backup1" is, indeed, the mount server. Something else seems to be going wrong, as I keep getting a permission error. I tried to do the same type of restore in our local site and got the same permission error.

So...looks like this topic turned out to be a red herring; I'll head to other parts of this forum to figure out my permission error...I bet that'll fix this issue!

[foggy]

Feel free to ask our engineers for assistance if nothing relevant pops up.

[bhagen]

Yeah; I'll be submitting a ticket, but...after Thanksgiving.