Comprehensive data protection for all workloads
Post Reply
CatMDV
Novice
Posts: 3
Liked: never
Joined: Nov 25, 2023 9:12 am
Contact:

How to migrate to upgrade existing repo storage

Post by CatMDV »

I am in an interesting situation for which I could not find applicable documentation for. Here's the situation:

- Veeam 11, vSphere environment.
- Two SOBRs, each with local performance and S3 capacity extents. No archival extents
- Each SOBR has more than one local repo extends
- Behind the scenes, all local repos reside in a single SAN storage.
- Due to how I partitioned the SAN storage initially, it can no longer scale and things are a mess to say the least.
- Only way to fix it all is destroy the SAN setup and rebuild everything, but that also means all my data will be lost.

Now the problem:
- I have standby storage to move important backups for the duration of the migration. But,
- The storage is not big enough to move all the backups. However,
- What I want is to move only few backups belonging to specific VMs and not everything. Especially the GFS archives of those VMs. The rest of the data will be destroyed and I am fine with it.

Question is, how do I achieve this.
- I have tried looking into exporting backup option under "Disks" but it only allows me to export one restore point at a time per VM and not everything at once.
- The Backup Copy job seems like it is for all restore points (or every new point created after I activate the job, I am not sure), and not just selected GFS points. And the temporary storage will not have the capacity to cater for that much.
- The Copy Job seems like its is limited to live files / VMs only and cannot process existing GFS points easily (maybe possible with file copy option but not sure how effective it will be).

So, is there a way to move specific GFS points from specific VMs without have to repeat the process for each VM per each GFS point?

Thanks,
Sam
Mildur
Product Manager
Posts: 8735
Liked: 2296 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: How to migrate to upgrade existing repo storage

Post by Mildur »

Hi Sam
So, is there a way to move specific GFS points from specific VMs without have to repeat the process for each VM per each GFS point?
Unfortunately not. Export is the only option which allows you to copy a single backup. You could script it.

Maybe a better option if your spare storage allows it. Veeam V12 provides a new option to copy/move backups FastClone aware. Your GFS backups will be synthesized if your spare storage has a reFS or XFS filesystem. This will allow you to store fullbackup files without using the entire space of a fullbackup.
The first GFS backup will use the entire space, additional fullbackup files will require much less storage. Would that solve the limited storage situation?

Best,
Fabian
Product Management Analyst @ Veeam Software
CatMDV
Novice
Posts: 3
Liked: never
Joined: Nov 25, 2023 9:12 am
Contact:

Re: How to migrate to upgrade existing repo storage

Post by CatMDV »

Hi Fabian,

Thanks for the reply. Just wanted to update the thread to note that upgrading to V12 was the only option that was viable. But it also left big security holes since the new version required identical immutability requirements in all repos in a SOBR which was a bummer.

Anyway, for future reference, if you want to backup specific points from multiple VMs using the new v12 copy option, it seems that you can chain multiple VMs together as a single job. i.e., add multiple VMs to a job, and for each VM, pick a single restore point. You cannot add more than one restore point of the same VM to the same job, which is still a bummer. But this way, while i will still need to run multiple jobs, it will be only a fraction of what i'd have needed to run on V11.
Mildur
Product Manager
Posts: 8735
Liked: 2296 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: How to migrate to upgrade existing repo storage

Post by Mildur »

Hi CatMDV

Thank you for coming back with a feedback.
But it also left big security holes since the new version required identical immutability requirements in all repos in a SOBR which was a bummer.
May I ask why your see this as a security hole?

Best,
Fabian
Product Management Analyst @ Veeam Software
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 136 guests