Migrating data to SOBR

[vertices]

I've been reading and searching and have found a few threads and articles on this but I want to be clear on what I need to do since it's about 50TB spread out over 3 sites with multiple copy jobs, etc. and I couldn't find anything that definitively covered what I want to do clearly enough to make me comfortable.

We are in the process of moving from non-SOBR Windows based repos, to SOBR immutable repos.

Right now, I have 50TB of backup data on a non-SOBR repo. These jobs are tied to copy job to remote sites so I need to keep the integrity of the jobs. I can't simply add a new SOBR, then add the old as an extent and evacuate it as it would take far too long and jobs wouldn't be rolling. I need to migrate jobs individually. I am not exactly sure what options are supported for migrating in/out of the SOBR. In my mind I have a couple of options but I am not sure what will work or is supported.


1. Turn original repo into an SOBR by itself with no other extents. Make a second SOBR on the new server. Migrate jobs one at time by disabling the job, moving the data, editing the job to point to new repo, enabling job again. This would be migrating jobs from one SOBR to another SOBR. Would this option work?
2. Leave original repo alone. Make new SOBR. Add original repo as a performance extent to the new SOBR. Disable jobs one at a time, moving data from one extent to the other, rescan the extents, re-enable the job. This would be migrating jobs from one extent to another extent in the same SOBR. Will this option work?


Thanks!

[HannesK]

Hello,
when you talk about SOBR immutable repositories... do you mean Hardened Repository with Linux machines? If yes, then you probably like to have block cloning, right? Did you think about seal mode which would allow that your new backup chain can leverage fastclone?

1. would work, but I would avoid it. If you really want to move manually and lose fast cloning, then I would do it within the same SOBR (stop job, move files, rescan, enable job)
2. sounds like my suggestion from above

Best regards,
Hannes

[vertices]

Yes the new repo is an SOBR with immutable linux machines. The old is (currently) non-SOBR on Windows with ReFS block clone. I'm aware that by migrating, everything will rehydrate. Not much I can do about that. This particular repo doesn't store backups older than 2-3 weeks so it's not that big of a deal. After rehydration, the jobs will eventually start using block cloning however correct? They do have weekly synthetics so that should just pick up? Or do I need to run new active fulls to get block cloning going again?

Ok so #2 would work. But honestly I didn't even think of seal mode. So if I simply turn the existing non-SOBR repo in an SOBR repo, and then join the new immutable linux repo to that as a performance extent, and then seal the first original repo, then all new backups will just rolling to the new one, starting with an active full, and then the old ones will age out evnetually (2-3 weeks) and then be removed via retention, eventually allowing me to retire the first. Is that correct? That actually sounds like the best idea! Thanks Hannes!

[veremin]

So if I simply turn the existing non-SOBR repo in an SOBR repo, and then join the new immutable linux repo to that as a performance extent, and then seal the first original repo, then all new backups will just rolling to the new one, starting with an active full, and then the old ones will age out evnetually (2-3 weeks) and then be removed via retention, eventually allowing me to retire the first. Is that correct?

Correct, and fast clone will be used on new extent (if the extent supports it, of course).

Thanks!