Rapid Recovery VM in Azure - To seed or not to seed!

Evening,

I'm in the planning phase of migrating my off site replication cores to Azure from our data center and I'm curious if anybody has any real world experience with seeding they would like to share.

Whether we add new cores with initial base images or replicate existing cores with base images and lots of incremental's there will be a lot of data to send to Azure so we are wondering about replication speeds/time of replicating versus shipping drives.

There is obviously a ton of variables and I know our experience will not exactly match anybody else but I'm curious what speeds people are seeing when replicating base images. For example, 3tb's of data behind a 100mbs fiber link. Are we talking hours or days or weeks for that to replicate to Azure.

And how has the experience been with sending drives? What type of turn around are you seeing once Microsoft receives the drive? I have one client in particular that can't seem to figure out their UPS and there server shuts down dirty every couple of months. New base images are generated so seed drives could be moving back and forth a lot if we can't let those replicate on their own.

As I said I know that no two experiences are the same but would really appreciate any experiences anybody might share.

Thank you

Parents
  • Before I give my feedback, look into increasing your dedup cache on the core. If sized properly, its entire function is to stop cores from replicating huge backups (bases) when they happen. So even if the core is forced to take a base (you cant stop that) the core can still only replicate an INC (not exactly correct but you get the idea)

    I would guess seed drives are going to be faster. But there are so many variables, maybe run a few small tests prior. Compare 200GB seed to a 200GB replication. Do this 3-5 times

    We have sent seed drives to Azure several times and never had an issue that I am aware of

Reply
  • Before I give my feedback, look into increasing your dedup cache on the core. If sized properly, its entire function is to stop cores from replicating huge backups (bases) when they happen. So even if the core is forced to take a base (you cant stop that) the core can still only replicate an INC (not exactly correct but you get the idea)

    I would guess seed drives are going to be faster. But there are so many variables, maybe run a few small tests prior. Compare 200GB seed to a 200GB replication. Do this 3-5 times

    We have sent seed drives to Azure several times and never had an issue that I am aware of

Children
No Data