I am currently running Veeam 11 on Server 2012. I would like to migrate to Server 2019. I’ve tested a couple boxes doing in place upgrades and it didn’t go smooth. So, I would like to spin up a new Server 2019 box and migrate Veeam. I’ve read the below article, and actually had to utilize it during my Veeam 11 upgrade to restore my config. My question is, how to I migrate since my repositories are on the Veeam 11 box? I have 3 disks on that machine with multiple repositories. When I go to perform the restore, those repositories are not yet on the new machine. What is the best technique for doing so? This is in VMWare, should i just add the old vmdks to the new machine? Is there a better method? I would love to shrink the vmdks in the process if possible. The backup database is much smaller than the vmdks.
Migrate Veeam to Server 2019
Best answer by MarkBoothman
If you upgrade to V12 you could create new repositories and use Veeamover to move the files to the new repos, especially if you have ReFS.
+17Hi,
are your repositories ReFS or NTFS formatted?
+7If you upgrade to V12 you could create new repositories and use Veeamover to move the files to the new repos, especially if you have ReFS.
NTFS. I have a vmdk with 2 NTFS mapped drives and one vmdk with a single mapped NTFS drive.
+21If they are NTFS, then you could attach them to the new VBR server within VMware. Then you will need to import the backups into the console so that Veeam can see them and then when creating your jobs map, them to the imported backups if you want to continue the chain. Otherwise, you could start a new chain and keep the other drives for restore only and allow them to age out. That would be my suggestion as you can set up new ReFS drives for the 2019 server and take advantage of the space savings.
+17NTFS. I have a vmdk with 2 NTFS mapped drives and one vmdk with a single mapped NTFS drive.
In this case you should probably mount your existing drives to you new VBR server and use them for restore only.
And create new drives and repositories at the new server and format them with ReFS. With this file system you will have a lot of space saving due to block cloning when creating synthetic fulls.
After the backups on the old repositories are outdated you can delete them and dismount the VMDKs.
Edit:
Chris was faster 😎
If you upgrade to V12 you could create new repositories and use Veeamover to move the files to the new repos, especially if you have ReFS.
Will that not work with NTFS?
+21If you upgrade to V12 you could create new repositories and use Veeamover to move the files to the new repos, especially if you have ReFS.
Will that not work with NTFS?
It will work with NTFS to ReFS yes, but this was in reference to already having ReFS to keep the block clone savings.
If you upgrade to V12 you could create new repositories and use Veeamover to move the files to the new repos, especially if you have ReFS.
Will that not work with NTFS?
It will work with NTFS to ReFS yes, but this was in reference to already having ReFS to keep the block clone savings.
Ok, i haven’t upgraded to V12 yet (it was actually part of this migration plan) i wasn’t sure if veeamover worked with NTFS. It seems that it just moves data from one repository to another. It will not allow me to move it to a new server unless i already had a new repository that was accessible by both servers.
NTFS. I have a vmdk with 2 NTFS mapped drives and one vmdk with a single mapped NTFS drive.
In this case you should probably mount your existing drives to you new VBR server and use them for restore only.
And create new drives and repositories at the new server and format them with ReFS. With this file system you will have a lot of space saving due to block cloning when creating synthetic fulls.
After the backups on the old repositories are outdated you can delete them and dismount the VMDKs.
Edit:
Chris was faster 😎
I may go this route. However, I may stick with NTFS. With my backend storage having block level dedupe, I don’t think i really have much to gain. It would reduce the size of my windows volumes, but the storage will probably not decrease. However, creating new repositories and starting new backup chains would eventually free up storage once i deleted the old vmdk. It would cause an initial uptick in storage usage.
If they are NTFS, then you could attach them to the new VBR server within VMware. Then you will need to import the backups into the console so that Veeam can see them and then when creating your jobs map, them to the imported backups if you want to continue the chain. Otherwise, you could start a new chain and keep the other drives for restore only and allow them to age out. That would be my suggestion as you can set up new ReFS drives for the 2019 server and take advantage of the space savings.
So, if I decide to keep them as restore only, would i restore my configuration using my backup from the old VBR server? Will it ask for a repository for each job when I do that? I only recently started administrating our Veeam solution. I’ve used it to create jobs and restore, but have done very little with administration.
+17You know that dedupe storage is not recommended by Veeam as storage for primary backups? The restore performance will be bad with this.
+17If they are NTFS, then you could attach them to the new VBR server within VMware. Then you will need to import the backups into the console so that Veeam can see them and then when creating your jobs map, them to the imported backups if you want to continue the chain. Otherwise, you could start a new chain and keep the other drives for restore only and allow them to age out. That would be my suggestion as you can set up new ReFS drives for the 2019 server and take advantage of the space savings.
So, if I decide to keep them as restore only, would i restore my configuration using my backup from the old VBR server? Will it ask for a repository for each job when I do that? I only recently started administrating our Veeam solution. I’ve used it to create jobs and restore, but have done very little with administration.
If the repositories are at the same place (same drive, same path) then all will be fine after the configuration restore. Ok, I would do a rescan of all repos anyway to be sure all is synchronized.
After this you can build some new repos and jobs for the new backups.
You know that dedupe storage is not recommended by Veeam as storage for primary backups? The restore performance will be bad with this.
We utilize Pure storage. As best practice according to their guide, you decompress the backup before storing it and let Pure handle the deduplication. This is with NTFS. I have not read into best practice with ReFS yet. This is what was recommended to us by PURE. We also use active fulls.
+21You know that dedupe storage is not recommended by Veeam as storage for primary backups? The restore performance will be bad with this.
We utilize Pure storage. As best practice according to their guide, you decompress the backup before storing it and let Pure handle the deduplication. This is with NTFS. I have not read into best practice with ReFS yet. This is what was recommended to us by PURE. We also use active fulls.
Then you should be good with Pure and following their recommendations. 👍🏼
+17You know that dedupe storage is not recommended by Veeam as storage for primary backups? The restore performance will be bad with this.
We utilize Pure storage. As best practice according to their guide, you decompress the backup before storing it and let Pure handle the deduplication. This is with NTFS. I have not read into best practice with ReFS yet. This is what was recommended to us by PURE. We also use active fulls.
If Pure recommends this… 😎
But then you should switch off deduplication in your Veeam Jobs.
If you upgrade to V12 you could create new repositories and use Veeamover to move the files to the new repos, especially if you have ReFS.
I have an issue with upgrading to V12 first. My Server2012 R2 box is running SQL 2008. It looks like this is not supported by V12.
+21If you upgrade to V12 you could create new repositories and use Veeamover to move the files to the new repos, especially if you have ReFS.
I have an issue with upgrading to V12 first. My Server2012 R2 box is running SQL 2008. It looks like this is not supported by V12.
No it is not supported so you will need to upgrade your SQL first before v12.
Comment
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.