Safe Data Storage Ltd’s Post

So many lessons we can learn from this story. And no, "you should not use cloud services" is NOT one of them. Data resiliency, backup, 3-2-1, etc. It's always a great time to review your strategy. (They had backups, but that was also on Google Cloud). https://lnkd.in/dc72DE4Q

Google Cloud (GCP) accidentally deleted a customer's account and data including backups. Relying solely on one cloud provider can be risky. Embracing a cross-cloud or hybrid cloud approach is crucial. Never put all your eggs in one basket. #CloudStrategy #HybridCloud #DataSecurity

A Google Cloud glitch left 620k Unisuper members without account access for a week, wiping out their entire private cloud subscription! This incident shows just how crucial it is to have a good backup strategy. You never know when the cloud might rain on you! #Cloud #Google #backup https://lnkd.in/g_8TPRW4

So Google Cloud accidentally deleted a Multi Billion Dollar company's(Unisuper) entire cloud environment, then deleted the backup they had in another region too. Luckily they had the oversight to host another backup in another provider. Makes you think really how much of your data is really safe in cloud and how much control do they have over it. Because for all the cloud provider charge a lot when changing to another provider or on premise environment. #google #cloud #backup #on_premise https://lnkd.in/gX3vEr8J

Red Hat's products are a game-changer for those who've seen and experienced the risks associated with hosting everything in one cloud provider. With Red Hat, you can host in and across any cloud provider(s), on-prem, and edge, all with a common platform, both managed and unmanaged. #openshift #RHEL #ansible #redhat. Hey, you can even procure using your cloud providers' marketplaces. Hit me up if you'd like to know more. https://lnkd.in/gcg2y-vs

The lesson to be had, once you read the official Google update, is how having the right #architecture approach and #internal skills helped UniSuper recover quite rapidly with Google’s aid. Imagine the organizations who fully outsource their #cloud #operations #maintenance to a 3rd party with less than a handful of internal people certified in cloud #architects #engineers ? This ties in to the evolution of #systemanalyst #businessanalyst that exist in many organizations. If the direction is cloud then, at a minimum, everyone should be a minimal cloud #associate or #beginner If you can’t tell the difference between a region and zone, or how you can run #serverless applications, then you’re stuck in the past. And if your system breaks then don’t blame the 3rd party partner. Blame yourself because cloud capabilities is baseline knowledge EVERYONE should have in IT regardless of role and not just a handful of individuals. #organization #capability #design

This is one rare incident but surely reinforces the need to have your cloud back up in not just two regions but also with two different providers / platforms.

Of what value are all your contractual safeguards, SLA, KPI with your cloud-provider if this can happen? This is why having a robust cloud-STRATEGY incl. solid BCP is so important.

Google Cloud recently deleted an $80B investment company's entire cloud environment, including their cross-region backups. It's a terrifying thought, but it happened. Luckily, they had a backup on another cloud, which ultimately saved them. Could this happen to you? Unisuper likely thought it wouldn't happen to them, but it did. That's why having a multi-cloud backup strategy is crucial. It may have been a fluke, but it saved an $80B business from failing. Check out the full story here: https://lnkd.in/eDZk3CMZ.

All organization has to think about this. When we had onprem servers before cloud, there were 3-4 datacenters as backup. Below incident could be a learning to have backup cloud provider for your application? Read below. https://lnkd.in/e8dWFNBM