SOBR evacuation one job at a time

[jamesharper-bsol]

Hi,

I'm currently evacuating 140TB over 6 jobs off an extent.

Is there a way to ensure it does 1 job at a time sequentially instead of grabbing files from different jobs?

The reason is so I can minimise the amount of downtime for a job as it can't run when there's still files on the old 'offline' extent.

At the moment it's shifting files from Jobs 1, 3 & 5 - I'd rather it completed 1 first so I can get it running again instead of waiting until the whole lot has shifted.

Thanks,
James

[ejenner]

This is the thing I don't like about SOBRs. If you have to evacuate it's painful.

What you may be able to do instead of evacuating is manually move the files using Windows explorer and import them on another repository. I believe there is a 'correct' way of doing that so the jobs are correctly re-associated with the backup files and continue to run properly. It is most likely documented somewhere.

[jamesharper-bsol]

Hey,

Yeah I see the instructions in kb2236. But it's a time sink and Veeam does a much better job of maximising throughput when moving the files!

Thanks,
James

[ejenner]

I've found the fastest way to transfer files these days is using Windows Explorer. It used not to be the case. But having had to shuffle lots of data round our network I've tried a few different routes. i.e. robocopy, ect... I've also found copying from one place to another can take a lot longer when 'pulling' rather than 'pushing' or vice-versa. If you've got a lot of data to copy it's worth trying a few different things to see what works best for that particular situation. What could be done in hours might take a week if you're not using the fastest option.

[jamesharper-bsol]

Thanks, at the moment I've found Veeam evacuation about 40% faster than an Explorer copy (push or pull), plus I don't have to babysit it and remap anything.

I've got just shy of 1PB to move about as I rebuild our repos with ReFS, so I'm keen not to babysit it!

If it would process each job sequentially then I wouldn't have to resort to any manual steps - hopefully this post could be picked up as a product enhancement!

Thanks,
James

[veremin]

Is there a way to ensure it does 1 job at a time sequentially instead of grabbing files from different jobs?

May I ask you what max concurrent task limit is specified on extents you're evacuating to and from? Thanks!

[jamesharper-bsol]

Hi,

Why has this been merged? I'm talking about something different to multiple streams.

I have 10 concurrent tasks allowed on each extent - which works well, it's maxing out the network bandwidth which is great.

I'm looking for it to do 1 backup job sequentially, not one backup file sequentially.

I need maximum network bandwidth (which the multiple streams provides) but for one job at a time so that I can tell the customer only one job won't run overnight while it's being moved, not that all jobs won't run for 6 nights because they all have partial data in flight.

Thanks,
James

[foggy]

Hi James, currently there's no prioritization logic in evacuation functionality. Instead, Veeam B&R moves all the full backups first and then distributes increments in accordance with the specified policy.

[veremin]

Why has this been merged? I'm talking about something different to multiple streams.

Sorry, my bad, I've accidentally moved these posts to the thread I found (mistakenly) similar to yours - apologize for that.

As to your question, then, Foggy is correct here - currently you cannot prioritize files in evacuation process.

Thanks!

[jamesharper-bsol]

Thanks foggy,

I'm seeing both vbk files and vib files being moved at the same time while there are still other vbk's at the source - what policy is this?

Is this something that can be enhanced in future? I have backup jobs that can't be run for days where if it did them sequentially I could have them back up and running in 1 day.

Thanks,
James

[foggy]

Yes, we can take it as a feature request. Thanks for the feedback!

[jamesharper-bsol]

Thanks foggy,

Just for more info - I notice that it is leaving the latest vib files and moving on to other files, then once they have transferred it comes back and moves the latest restore point, so there is some logic going on here - hopefully an easy tweak.

Thanks,
James

[Vek17]

You can probably do some tweaks to get this sort of behavior, albeit with a bit of manual involvement.

• Create a new SoBR with repos on different folders than your current extents

• Move the job you want to move into those folder to put it on the NEW SoBR

• Set up maintenance and evac

• When complete move back to the ordinal repo folder and rescan and remap