Recovery as a service

Recovery as a service (RaaS),[1] sometimes referred to as disaster recovery as a service (DRaaS), is a category of cloud computing used for protecting an application or data from a natural or human disaster or service disruption at one location by enabling a full recovery in the cloud. RaaS differs from cloud-based backup services by protecting data and providing standby computing capacity on demand to facilitate more rapid application recovery. RaaS capacity is delivered in a cloud-computing model so recovery resources are only paid for when they are used, making it more efficient than a traditional disaster recovery warm site or hot site where the recovery resources must be running at all times.

The term "recovery as a service" (RaaS) is considered to be part of the nomenclature of cloud computing, along with infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).[2]

RaaS architectural models

RaaS architectural models vary depending on the location of the primary or source production application or data.

  • To-cloud RaaS : To-cloud recovery is when the source application is in the users primary private datacenter and the cloud is being used as a backup or recovery target.[3]
  • In-cloud RaaS : In-cloud recovery is when both the source and recovery sites are in the cloud.[4]
  • From-cloud RaaS : From-cloud recovery is when the primary or production application or data is in the cloud and the backup or recovery target site is a private datacenter.[5]

Recovery testing with RaaS

Sandboxes are a common feature of RaaS solutions. A RaaS sandbox[6] is a pool of infrastructure resources in which a test copy of the RaaS protected application can be deployed and tested. The sandbox copy is restricted from accessing the network and is only accessible to the system administrator. It is used to test the RaaS recovery process without disrupting the running application. Because the sandbox is in the cloud, the resources are created on demand, paid for while used, and discarded when the recovery testing is completed.

In the marketplace

Because more corporations are moving their technical infrastructure to cloud services, the need for backup continues to grow. Companies which rely on large cloud service providers such as Microsoft are often unaware that they are responsible for backing up and recovering their own data.[7]

As this awareness grows, the market for disaster recovery as a service is expected to grow rapidly. The world wide market for disaster recovery as a service approached 2 billion dollars in 2017, and some experts predict will reach 13 billion dollars by 2023.[8]

gollark: > 5. .net platform is cracker / hacker friendly Any program running on the client can INEVITABLY be reverse-engineered. Do not rely on it not experiencing that, because you will fail.
gollark: > 4. XAML - the incredibly messy UI technologyPerhaps, but this is not a *language* thing.
gollark: > 3. Garbage collector and memory leak detection tools?Again, not sure if anyone actually runs into this sort of issue in practice.
gollark: > 1. Performance penalties.> [some rambling about C++].NET is generally pretty much *fast enough*. If your application somehow hits performance bottlenecks, rewrite the slow bits in native code, don't just immediately take a development speed hit.> 2. Need to interoperate with C++ / Native (Windows) API’sI don't know how often you actually need to bind to a native API not wrapped by .NET or a third-party library, but you can do it, it's just annoying - but probably less than using C++ for everything!
gollark: This is outrageous pro-C++ anti-C# propaganda.

See also

References

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.