Replacing Repository hard drives question

[Rascii]

Hello,
I have a Windows server acting as our primary Veeam Repository storage for all our backup jobs, then we do backup copies to NAS storage, etc. I'm running out of space and we are going to replace the four 8TB drives with four 16TB drives. Unfortunately this server only has four slots and so it's one big Raid 10 which means the C: drive for the OS is on the same storage as the D partition. I know best practice is to have seperate disks for the OS and if I did this would be easy to just replace the D storage disks one at a time. My B & R server is a VM and this is just the physical storage repository. I use B & R to make a Windows Agent Backup of only the C: drive of the repository.

My plan is to simply pull all the drives (and retain their data), insert the new drives and create a new raid 10. Use Windows disk to create the same size C: partition and then boot from a Veeam Recovery USB stick and restore the OS onto the C: drive. My plan is NOT to try and backup the D and restore it because of size restraints, but rather just start fresh with an empty D: to run our backups to (while saving the old disks in case a major restore is needed that the backup copies cannot handle).

So, how will Veeam handle not having the backup file chains in the new D drive? Do I need to do anything prior to removing the D drive?

Thanks much for any advice on ANY of this.

[Mildur]

Hi Rascii

If you want to delete all backups for this migration, I would follow this steps:
1) Remove all backups from the configuration:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

2) Create a configuration backup and copy it to an external location:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

3) Install Windows again on your backup server, format all disks

4) Install Veeam from scratch

5) Restore your configuration backup:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

If you are on Veeam V11, you must install Veeam V11 again for the config restore in step 5.


Best,
Fabian

[Rascii]

I'm confused. This is not my main B&R server. This is only a repository so I would not install Veeam from scratch and restore any config, correct?

Wouldn't restoring the C: drive with OS and all Veeam agents be the simple way to go? We also have our tape drive connected to this physical server with all drivers.

My question is if I don't delete the backup information in my main B&R VM server on another host, what will happen when the backup job runs and doesn't see any files on the new destination storage D: drive of the repository server? No chained jobs or files, but completely empty. Will the jobs run full backups and not fail? Or do they need to see the older backup job files?

Thanks much!

[Mildur]

Ah yes. If it‘s not your backup server, then you can go that way with the agent.

You can use step 1 from my previous comment to let veeam forget about all existing backups from that repository. Next run of the job will be an active full.
If you don‘t remove them from the configuration database, the backup job will complain about missing files.

Best,
Fabian

[Rascii]

Thanks!

Last question hopefully. So if I delete the backup information and a restore situation would to come up, theoretically, could I re-insert the old drives and boot to the old repository and inventory the backup files back into Veeam some way in order to do a restore from that old data?

[Rascii]

My plan was to boot from Server 2019 media to create the C: partition and then boot from the Veeam Recovery media to restore. Or does Veeam have the ability to create partitions from the recovery media? Thanks again.

[Mildur]

Hi Rascii

could I re-insert the old drives and boot to the old repository and inventory the backup files back into Veeam some way in order to do a restore from that old data?

While it can work, I wouldn‘t do it. You have migrated your repository server to new disk. Those disks should stay connected.
But you can connect those disks to any other server if that server allows to import a foreign raid configuration.
But TPM could be an issue.

Or does Veeam have the ability to create partitions from the recovery media?

Yes, you create and change those partitions:
https://helpcenter.veeam.com/docs/agent ... tml?ver=60

Best,
Fabian

[Rascii]

Thanks very much. Everything went very well. The Veeam Recovery process was so smooth with creating the custom size partition by selecting the manual recovery. Talk about slick. 19 minutes total time and I was back up and running on the new drives like it was never down. It's nice to show proof of concept to those in charge that our backup and recovery is working as promised.

Now my old repository server has double the capacity and refreshed HD's. I didn't remove the backups BEFORE removing the drives so that option was not available. But, "Delete From Disk" worked great, no complaints from the software. I'm already making backups as everything is going to take much longer being these will all be full for the first run as you mentioned.

[YouGotServered]

One cool thing I have utilized for repository server migrations is the SOBR S3 offload functionality. We made sure all of our backups were uploaded to Wasabi (worked for us because we have 500mbit/s upload and about 10TB of backup chains we cared about), then blew away the old repository, set up the new one, and just told Veeam to re-download the wasabi contents.

It always makes me nervous not having an on-site copy of backups, but the risk was acceptable in this case due to various other factors that I won't describe here.

It does remind me of an IT horror story from a co-worker that is no longer here - they were backing up a mission critical SQL server. Backups had been failing for a few days due to failed disks on the source side. No offsite backups. They decided to delete all backups to make space for a last ditch effort to get an up-to-date backups, then the SQL server disks completely died. Five days, $250,000 in lost revenue and a $40,000 forensic data recovery bill later, the business was up and running (with one fewer employee). Moral of the story - NEVER do anything that could potentially hose your only copy of backups. If you decide to do that, you might as well have your resignation letter handy.