Seeding a per-vm copy after big change to one VM?

[pkelly_sts]

We have a Win 2008 fileserver that we're "upgrading" to Win 2012 simply by attaching its data disk to a newly built Win 2012 VM & de-commissioning the original once completed.

However, the data disk is 900Gb (used/consumed) so I'm trying to plan the impact on backups, both local & copy off-site (over 20Mb link, so not super-fast).

Is Veeam clever enough to "realise" that it's the same data & will de-duplicate it or should I expect a very large incremental backup of this VM?

If it isn't able to de-dupe it (not entirely unreasonable given the nature of teh change) then, as I'm doing per-vm on both local backup and backup copies, is there a way of seeding just a single VM these days to the remote site?

It needs careful planning as we only physically visit the remote site once/week (typically wednesdays) so ideally I'd like to do what I need to on the Tuesday, get it to tape overnight on Tuesday, then transport the tape with our visiting engineer on the Wednesday where I can do the necessary.

Basically I've seeded "monolithic" backups many times and am very familiar with the process, but this'll be my first seeding of an individual VM since moving to per-vm jobs.

Any advice/pointers welcomed...

[pkelly_sts]

Any thoughts?

[veremin]

What backup mode do both local backup and remote backup copy jobs leverage? For a backup job is it forward or reversed incremental one? For a backup copy job is forward forever incremental or the one with periodic full backups? Thanks.

[pkelly_sts]

Sorry, important information - everything is FF with no periodic fulls to disk as everything is copied to tape, both the local and the off-site copy, which is were we create our periodic fulls.

[veremin]

In this case there are not so many much options available for you. The initial run for a new VM will be full one, and there is no way to avoid that. Thanks.

[pkelly_sts]

OK, I understand, but is there a way of copying/seeding JUST that VMs first full backup to the destination for the copy job?
If not, then is my only option to re-seed the WHOLE job again? That's going to effectively trash any previous RPs is it not? in other words, I'd have to generate another local copy job to create a new copy, transport that over, then re-map it etc.

That would be a MAJOR pain as I have replicas generated from that, tape backups generated from it etc. etc.

[veremin]

OK, I understand, but is there a way of copying/seeding JUST that VMs first full backup to the destination for the copy job?

Nope, there is none. But I'm wondering whether the initial cycle of 450 GB (providing at least 2x data reduction ration) would affect desired backup duration that dramatically. If that's true, it might be worth temporarily increasing backup copy sync interval. Thanks.

[pkelly_sts]

Hmm, there's a feature request in there somewhere, I can just FEEL it!

Seriously though, there must be some way (with some work from your designers obviously) we should be able to leverage the per-vm chain to cope with this scenario some how?

As it stands, my backup plan will likely be to just create another job for this single VM locally, then a copy job locally, then seed that one to remote site & continue for now.

I'm due to go on leave next Thursday for 12 days, was hoping to get this seed done Wednesday, but I sense the fall-out of trying to do it with the original job I just won't have time to clean things up so will have to defer things somewhat unless I just run it as another job for now, which isn't ideal...

[veremin]

Seriously though, there must be some way (with some work from your designers obviously) we should be able to leverage the per-vm chain to cope with this scenario some how?

I've had a quick discussion with our QA team. According to the answer I got, it's not possible. Though, thank you for the feedback; your voice has been heard.

[JoshRountree]

I didn't read all the previous posts as closely as I should, so take my advice with a grain of salt. I'm thinking out loud here:

This might be your best compromise
-Get new VM up and running correctly
-Disable any copies to off-site location
-Add new VM to your local backup job
-On the day your transform is performed copy full backup and backup chain to removable storage
-Take to off-site location and copy/re-seed

I know this will leave you without some off-site backups, but during that period you could have a local backup job that copies the backups to removable storage and have someone take them home with them every day. It might be a good way to verify the local copy with removable storage will work.

[foggy]

With WAN acceleration, the amount of actually transferred data for the new VM shouldn't be that large, data should be taken from cache and existing backups.

Theoretically, provided per-VM chains are enabled on the target repository, you could create a full backup of this VM and put it into the remote repository, however it will not be picked up automatically without editing VBM file, which is not trivial/recommended.

Another option you might consider: vmware-vsphere-f24/re-seeding-on-copy-j ... ml#p110449

[pkelly_sts]

Because of the issues above I've delayed the upgrade of this server and, actually, thinking about it we're soon doing a datacentre migration to a new site with a new vSphere environment so chances are I'm going to have to start things from scratch then as well anyway, need to get my head around my options for migration first (link between current site & new site is never going to be great either but link from NEW site to existing DR site will be upgraded from around 10Mb to 100mb P2P so much more chance of a big copy working.

However, I've just thought of an alternative approach for this VM - do it "backwards"

If I were to create the new fileserver VM with just its O/S drive, then I could attach THAT drive to the original large VM (after detaching it from the VM I built it in), replacing its existing boot drive. That way the large 1Tb VMDK remains untouched, and the only change is actually the boot drive which is a) smaller & b) well de-duped anyway as I have other VMs already backed up from the same O/S template.

Only minor niggle is the VM name will initially differ from the actual hostname but that's not too hard to fix anyway.

Should work though eh?

[foggy]

Looks promising. You can check with some smaller test VM first.