Skip to main content

Morning all. 

Hoping someone can help identify the best method available to us for migrating to new hardware. 

Overview of current setup:

  • All in one VBR server (physical) 
  • Currently on v11
  • Local storage (ReFS volume) 
  • SOBR using Wasabi S3 for the capacity extent. Backups are copied to capacity. 
  • 1 job (agent managed) backing up 7 physical servers at remote sites

Overview of new setup:

  • All in one VBR server (physical) 
  • Fresh install of v12
  • Local storage (ReFS volume)

How would we best approach moving the data/job from the current setup to the new setup? The approach needs to consider the following: 

  • Ideally, we want to use VeeaMover in v12 to move the data between current and new setup so that we maintain the ReFS block cloning savings. 
  • The storage from the new system cannot be directly attached to the current system, but the servers are on the same LAN. 
  • We want to use a SOBR on the new system that utilises the same Wasabi S3 bucket so that we don’t have to re-seed wasabi (if this is possible!).
  • We want to continue the existing backup chains on the new system, rather than starting new ones. 

Thanks in advance! 😁

The other thing you can do is take a configuration backup of your current system and then restore that to the new Veeam v12 system to keep passwords, jobs, etc.  Then once you do the data move you can remap the jobs again to continue the chains.

Here are some thoughts around this -

  • Ideally, we want to use VeeaMover in v12 to move the data between current and new setup so that we maintain the ReFS block cloning savings.  ---- This would require the old server be attached to the new Veeam v12 server as just a repository so that you can take advantage of VeeaMover, otherwise it is a network copy/paste option that could take a long time depending on amount of data.
  • The storage from the new system cannot be directly attached to the current system, but the servers are on the same LAN.  ---- See point #1 above 👆🏻
  • We want to use a SOBR on the new system that utilises the same Wasabi S3 bucket so that we don’t have to re-seed wasabi (if this is possible!). ---- Add the Wasabi bucket to the new Veeam v12 system and then you will have an option to scan and import backups.  You can then use this in SOBR again for tiering.
  • We want to continue the existing backup chains on the new system, rather than starting new ones.  ---- All dependent on the above points and how data is moved or can be moved.

Hope this helps.


@Chris.Childerhose thanks for the reply Chris, very helpful so far! 

 

… This would require the old server be attached to the new Veeam v12 server as just a repository so that you can take advantage of VeeaMover, otherwise it is a network copy/paste option that could take a long time depending on amount of data.

 

Apologies if this is a stupid follow up question; What would be the be best way to attach the old server as a repository? It is as simple as adding a new repository and pointing it at the old server with the ‘add new’ option e.g.: 

Would adding it in this way allow us to then move the jobs using VeeaMover, keeping the ReFS savings? 


@Chris.Childerhose thanks for the reply Chris, very helpful so far! 

 

… This would require the old server be attached to the new Veeam v12 server as just a repository so that you can take advantage of VeeaMover, otherwise it is a network copy/paste option that could take a long time depending on amount of data.

 

Apologies if this is a stupid follow up question; What would be the be best way to attach the old server as a repository? It is as simple as adding a new repository and pointing it at the old server with the ‘add new’ option e.g.: 

Would adding it in this way allow us to then move the jobs using VeeaMover, keeping the ReFS savings? 

Yes, that is exactly how you would do it.  After adding the server as a repo, it will rescan and import backups.  You should then be able to create new jobs, map them to the backups on old server and then use VeeaMover to move them to new repo.


@Chris.Childerhose thanks for the reply Chris, very helpful so far! 

 

… This would require the old server be attached to the new Veeam v12 server as just a repository so that you can take advantage of VeeaMover, otherwise it is a network copy/paste option that could take a long time depending on amount of data.

 

Apologies if this is a stupid follow up question; What would be the be best way to attach the old server as a repository? It is as simple as adding a new repository and pointing it at the old server with the ‘add new’ option e.g.: 

Would adding it in this way allow us to then move the jobs using VeeaMover, keeping the ReFS savings? 

Yes, that is exactly how you would do it.  After adding the server as a repo, it will rescan and import backups.  You should then be able to create new jobs, map them to the backups on old server and then use VeeaMover to move them to new repo.

 

@Chris.Childerhose perfect - thanks for confirming Chris. We’ll give this a go and will let you know how we get on! 😀


@Chris.Childerhose thanks for the reply Chris, very helpful so far! 

 

… This would require the old server be attached to the new Veeam v12 server as just a repository so that you can take advantage of VeeaMover, otherwise it is a network copy/paste option that could take a long time depending on amount of data.

 

Apologies if this is a stupid follow up question; What would be the be best way to attach the old server as a repository? It is as simple as adding a new repository and pointing it at the old server with the ‘add new’ option e.g.: 

Would adding it in this way allow us to then move the jobs using VeeaMover, keeping the ReFS savings? 

Yes, that is exactly how you would do it.  After adding the server as a repo, it will rescan and import backups.  You should then be able to create new jobs, map them to the backups on old server and then use VeeaMover to move them to new repo.

 

@Chris.Childerhose perfect - thanks for confirming Chris. We’ll give this a go and will let you know how we get on! 😀

Not a problem hope it all works out.


Hi @Chris.Childerhose Would adding both the repository to SOBR and then evacuating backup from old repository to the new repository would be an option to explore.

 


Hi @Chris.Childerhose Would adding both the repository to SOBR and then evacuating backup from old repository to the new repository would be an option to explore.

 

Yes that is another option also to put the old in maintenance mode and evacuate to the new.  Then you can remove the old one.  You can also do this without a SOBR as well.


@Chris.Childerhose Thank you :-)


@Chris.Childerhose Thank you :-)

Not a problem let us know how it goes.  Also once solved be sure to mark the best answer for the thread for others to see.


Hi @EMcS -

I am just following up on your migration question post here to see if any of Chris’s comments helped you out? If so, we ask you mark which one best helped you as ‘Best Answer’ so others who come across your post with a similar question may benefit.

If you do have further questions though, don’t hesitate to ask.

Thank you.


Comment