Cloud Storage Gateway and Scale-Out Repository

[fredpelaez]

Hello,

Has anyone used scale-out backup repository using a combination of standard storage (NAS, SAN, etc.) and a cloud storage gateway (NetApp AltaVault, MS StorSimple)? Looks good in paper but not sure if this is a good architecture in the field. Challenges? Problems? Gotchas?

Regards,

Fred

[dellock6]

Hi Fred,
what would be the use case? I see a lot of issues for example during a merge operation in performance mode, if blocks are not cached locally but some have to be retrieved again from the cloud provider. We usually suggest to have a uniform connection to the different extents of a SOBR array, in your idea the cache is local, but the bulk of data hold by the gateway is remote. This is the reason why for example you cannot add Cloud Connect repositories to a SOBR array.

[fredpelaez]

Hi Luca,

Because Veeam doesn't connect directly to Azure Blobs and the limitation to Azure Page sizing, MS StorSimple is a tool that I can use to store data to Azure Blobs. The concern I have with MS StorSimple is RTO (too slow to recover due to storage-based inline deduplication) and the lack of local capacity. To mitigate these "concerns", I am looking at deploying a non-dedup storage or JBOD. This storage will be used for short-term backup (up to 10 copies) and StorSimple will be used for long-term backup. Scale-out repository will pool these storage array and manage movement of data between them.

What would be your take on this approach?

Regards,

Fred

[Mike Resseler]

Hi Fred,

In that case I would not use SOBR but build two different repositories. Take backups to your short-term repository and then backup copy jobs to the Storsimple. In your scenario, that gives you fast recovery for 10 copies and if necessary also gives you the possibility to restore from that long-term repository (if you agree on an SLA for longer term recoveries that will be slower with the business of course )

My 2 cents

Mike

[dellock6]

I totally support the idea of Mike, I would have suggested the same. SOBR is about grouping together multiple storage that receive the same backup job, but here we are talking about a two-stage design, so having one storage per stage is perfectly fine. Also, with this design you avoid to have two copies of the same backup inside the same SOBR, which may be a single failure domain.

[fredpelaez]

Thanks for the feedback