Google Cloud wist per ongeluk account van Australisch pensioenfonds

Google Cloud heeft vorige week enkele fouten gemaakt bij het account van UniSuper: een Australisch pensioenfonds voor academici. Hierdoor werd alle data van de organisatie bij Google Cloud gewist en verloren honderdduizenden klanten toegang tot hun financiële gegevens.

Thomas Kurian, de ceo van Google Cloud, schrijft in een gezamenlijk statement dat er zich een misconfiguratie bij het account van UniSuper heeft voorgedaan en dat heeft volgens de man tot de verwijdering van het profiel geleid. De klanten van het Australische pensioenfonds hadden daardoor geen toegang meer tot hun gegevens.

UniSuper kon bij Google Cloud op twee duplicaten van zijn gegevens rekenen, maar deze kopieën werden volgens Kurian allebei gewist. Het pensioenfonds had echter nog een back-up bij een andere clouddienst achter de hand en hiermee kon Google Cloud de gegevens van UniSuper alsnog herstellen. Er zou dan ook sprake zijn van minimaal dataverlies.

Kurian schrijft dat het een uniek voorval betreft en dat dergelijke problemen zich nog nooit hebben voorgedaan bij klanten van Google Cloud, waar ook ter wereld. Het bedrijf zou inmiddels enkele maatregelen hebben genomen om ervoor te zorgen dat dergelijke incidenten zich niet meer kunnen voordoen.

Reacties (196)

[RobbyTown]

Het pensioenfonds had echter nog een back-up bij een andere clouddienst achter de hand en hiermee kon Google Cloud de gegevens van UniSuper alsnog herstellen. Er zou dan ook sprake zijn van minimaal dataverlies.

Stel die backup was er niet. Dan was dus echt alles weg?

[wildhagen]

Dat klopt. De cloud is ook niet echt een backup op zichzelf.

Daar moet je dus ook gewoon een backup van je spullen maken, net zoals dat onpremise ook moet.

[Tweakert2020]

Als je een back-up dienst afneemt is het wel degelijk een backup.

[wildhagen]

Ja, maar die moet je dan specifiek afnemen, en dat is doorgaans een betaalde dienst. Want het maken van (goede!) backups kost best wel wat geld. em Google (of welke clouddienst dan ook) is geen liefdadigheidsinstelling, die gaan dat echt niet gratis voor je doen.

En nee, ook Google Drive (of OneDrive etc) zijn géén backup diensten. Dit zijn synchronisatie tools, die werken op een heel andere manier, en hebben een ander doel, dan backups.

De meeste mensen, en ik ken zelfs bedrijven, betalen niet voor zo'n aanvullende dienst en denken dat het "opslaan in de cloud" al een vorm van backup is. Nou, niet dus. Dan zul je het toch echt zelf moeten inregelen.

[Tweakert2020]

Je hebt gelijk. Probleem wat ik met de meeste reacties hier heb is dat iedereen er vanuit gaat dat UniSuper geen betaalde dienst heeft afgenomen maar iets van Google Drive heeft gebruikt. Daar lijkt het natuurlijk niet op.
Overigens ook al is Google Drive zelf geen backup dienst, je kan het zelf zo gebruiken door een reservekopie van je data daar neer te zetten.

[Aldy]

Ik had juist begrepen dat UniSuper in Google Cloud werkte en daarbovenop nog twee back-ups in dezelfde cloud hadden. Als je dit hebt, dan lijkt mij dit een (goed) betaalde dienst.

[Tweakert2020]

Zo heb ik het ook geïnterpreteerd. Dit zou afdoende moeten zijn.
Gelukkig voor hun hadden ze nog een backup elders.

[joenevd]

Daar ben ik het niet mee eens. Er is in de ICT wereld een dringend advies om een kopie van je backup buiten de infrastructuur te bewaren.

Als je een Cloud dienst gebruikt, kan je de Cloud leverancier dus zien als de betreffende infrastructuur.

Je wilt ten alle tijden eigenaar kunnen blijven van je eigen data, daar wil je echt niet voor afhankelijk zijn van een enkele partij.

In dit geval had Unisuper het dus goed geregeld, helaas zijn er een hoop bedrijven die daar niet voldoende over nadenken.

[Tweakert2020]

Daar mag je het niet mee eens zijn maar wanneer een (cloud) dienstverlener een totaalpakket aanbied waaronder backups mag je gewoon verwachten dat dit in orde is.

[GoBieN-Be]

Er is een gouden regel wat betreft back-ups.
De 3-2-1 regel, al is die ondertussen ook al wat achterhaald.
- 3 kopies van je data (origineel en tenminste 2 kopies)
- 2 verschillende types van opslag (als je origineel in Google Cloud, zit dan tenminste 1 back-up elders)
- 1 kopie die off-site is of zelfs disconnected

bron: https://www.veeam.com/blog/321-backup-rule.html

Dus gelukkig had UniSuper de regel gevolgd en hadden ze een back-up buitenom Google Cloud.
Ook al bied de Cloud Provider een back-up dienst aan, als deze in dezelfde account zit, ben je niet safe!

Wij werken voornamelijk met Microsoft 365 diensten voor onze klanten, maar wij raden hen ten sterkste aan om ook een cloud-to-cloud back-up dienst af te nemen.

[Reactie gewijzigd door GoBieN-Be op 22 juli 2024 16:16]

[Kees]

Ik vertrouw niemand. Ik wil het liefst niet afhankelijk zijn van 1 bedrijf. Hoe onwaarschijnlijk het ook is er kan altijd wat gebeuren zoals maar weer blijkt.

[Houtenklaas]

Daar mag je het niet mee eens zijn maar wanneer een (cloud) dienstverlener een totaalpakket aanbied waaronder backups mag je gewoon verwachten dat dit in orde is.

Als Unisuper dat had verwacht, waren ze waarschijnlijk nu failliet. Uitganspunt zou moeten zijn dat je zelfstandig de boel weer op de rit kunt krijgen als er elders iets misgaat. Ook de derde backup stond blijkbaar ergens in de cloud, dat blijft gewoon doodeng. Word je getroffen door ransomware, dan ben je gewoon ordinair de Sjaak. Unisuper is letterlijk door het oog van de naald gegaan ...

[d3burt]

Zeker! Maar er zijn twee uitdagingen met backup in de cloud.

Als je het contract opzegt, en dat doe je door één account te verwijderen, verdwijnt ook je backup (ik heb dit een keer in Azure zien gebeuren, jaren geleden: je hoopt dat ze nu aangepast hebben dat de backup nog een maand bewaard blijft).

De tweede uitdaging is dat een backup maken buiten de cloud, of naar een andere cloud, egress verkeer oplevert wat duur uit kan vallen.

[bons]

Persoonlijk zou ik never ten nimmer nooit mijn bedrijfsdata maar bij 1 Identiteit onderbrengen. Het is dan wedden op 1 paard, en dan mag het zijn dat die paard wellicht altijd de race wint (goed met je data omgaat)

Op een dag kan het gebeuren dat je paard het zal veriest en ben je alles kwijt. En de reden van verlies hoeft eens niet een technische fout te zijn het kan ook getriggerd worden door een menselijke invloed zoals een zakelijk conflict.

[Zynth]

Dat mag je verwachten.
Maar als het bedrijfskritisch is, huur je op zijn minst een extra partij die een onafhankelijke garantie daarop levert. Door bijvoorbeeld een offsite backup te maken.
Je bedrijfskritische data laat je nooit onder beheer van slechts 1 partij, hoe goed deze ook is.

[Reactie gewijzigd door Zynth op 22 juli 2024 16:16]

[Maxdehaas19]

Wat ik mij afvraag is deze zin

dat er zich een misconfiguratie bij het account van UniSuper heeft voorgedaan en dat heeft volgens de man tot de verwijdering van het profiel geleid.

De vraag die niet in het artikel wordt beantwoord is wie en hoe deze misconfiguratie heeft veroorzaakt en hoe een misconfiguratie tot het verwijderen van een account kan leiden. Ik zie het account verwijderen knopje niet als misconfiguratie.

[emn13]

Het is lastig een scenario voor te stellen waarbij die misconfiguratie niet iig duid op een structureel probleem bij Google Cloud (en Google zelf zegt dat te gaan verhelpen, dus dat is ook consistent met die interpretatie). Zelfs al was het iemand van de afnemer die de "misconfiguratie" deed, dan noch is dat een menselijke fout die je nooit geheel zult voorkomen, en is het tevens goed denkbaar dat zo'n fout ook gerelateerd is aan de complexiteit en onoverzichtelijkheid van de geboden opties. Iedere klant van zo'n dienst weet hopelijk dat ze fouten kunnen maken, en als de consequenties van fouten zo dramatisch zijn, dan maakt dat de dienst zelf netto onbetrouwbaar. Oftewel, de juiste vraag is niet echt schuld hier, maar wie het beste kan voorkomen dat zoiets zich ooit weer voordoet - en dat zou toch haast wel de cloud provider moeten zijn. En laten we wel wezen, als het resultaat was geweest dat Google had gezegd "tja, eigen schuld", zou jij dan nog Google Cloud durven gebruiken voor bedrijfskritische data? Het klinkt voor mij aannemelijk dat de imago-schade hier wel heel aanzienlijk kan zijn voor Google Cloud, dus kun je verwachten dat ze daar proberen iets aan te doen.

Ik ben wel benieuwd wat voor maatregelen Google dus genomen n.a.v. hun statement "This is an isolated, ‘one-of-a-kind occurrence’ that has never before occurred with any of Google Cloud’s clients globally. This should not have happened. Google Cloud has identified the events that led to this disruption and taken measures to ensure this does not happen again." Wie weet komt er ooit meer van zo'n post mortem publiek? Laten we't hopen!

[flaskk]

Dat is te makkelijk, een klant wil gewoon een dienstverlener die dit regelt.

Ik denk dat 99% van de mkb in Nederland maar met 1 ict partij zaken doet, als die ict partij zegt je moet je backup ergens anders bewaren buiten ons om dan klinkt alsof de it partij zichzelf niet vertrouwd.

[joenevd]

Dat is de verkeerde redenering. Zeker voor MKB is Microsoft (als v.b.) geen ict partij. Dat neem je af via een tussenpartij. En de goede tussenpartij regelt een back-up buiten Microsoft/Google.

Tenzij de klant dit expliciet niet wil.

[Reactie gewijzigd door joenevd op 22 juli 2024 16:16]

[kabouter428]

Vind ik ook wel kort door de bocht, wij hebben de back up zowel via Microsoft als via Aws en dat volledig op aanraden van de IT partner. Overigens zat de oude IT partner te mikken op een eigen backup die we maar In de kast moesten plaatsen....

[Verwijderd]

En toch 3 versies verwijderen, ik zou weggaan bij google

[supersnathan94]

Ik ben het daar net als @joenevd niet mee eens.

Het is een heel goed advies om op zijn minst een maandelijkse archief backup ergens anders neer te zetten anders dan bij je productie provider. Het liefst op een heel ander type storage (long term archival). Maar dat is ook gewoon prijzig dus wordt vaak niet gedaan.

Ander ding is dat je dit ook actief moet testen met restore procedures op een uitwijk omgeving oid. Maar ook daar geldt weer voor dat het duur is.

Het dekt je wel beter in bij ransomware aanvallen in je productie omgeving die met privilege escalation ook je back ups kunnen verwijderen dus er is zeker een business case voor te maken.

[miitjohn]

Ze hebben vermoedelijk een cloud backup service gebruikt van Google, misschien zelfs binnen een ander datacenter.

Maar hoe ik het lees doet dat er niet toe want google het zelf het account verwijderd. Als je dat doet is het ergens logisch dat alles daaronder mee wordt verwijderd. Dan mag je nog tientallen services gebruiken over tientallen datacenters en regions, als alles gekoppeld is aan één account en je verwijderd deze, dan gaat alles ook mee weg met deze administratieve actie. Dat is toch iets helemaal anders.

Backups nog eens extra bewaren bij een andere provider is geen slecht idee, maar dat brengt ook de nodige complexiteit en kosten met zich mee. Had men een apparte account voorzien voor de backups, dan hadden deze er waarschijnlijk nog gestaan. Een aparte account verhoogd de complexiteit maar marginaal en je kan er zelf ook voordeel meedoen vermits het een financial en adminsitratieve boundary is. Zo kan je makkelijker toegangen scheiden.

[matthigast]

Google adverteert Drive toch wel als Backup dienst.
Als je naar de Drive download page gaat (https://www.google.com/drive/download/), krijg je deze beschrijving:

Choose folders on your computer to sync with Google Drive or backup to Google Photos, and access all of your content directly from your PC or Mac

[mr.paaJ]

Het is ook deels wel backup: als je je laptop of mobiel kwijt bent heb je wel nog je data.

[Tweakert2020]

In geval van defecte hardware (je telefoon of laptop) is het wel degelijk een backup.

[bons]

Klopt voor verlies van je hardware of fysiek stukgaan van je hardware wordt je gedekt. Maar echter zijn er nog veel meer taloze redenen om je data te verliezen (ransomeware bv) . Daarom vindt ik het ook een foute bedoeling dat bedrijven als Google een Synchronisatie dienst als vaak vervanging voor je echte backup oplossing promoten, dat is gewoon fout. Een Synchronisatie dienst is gewoonweg niet een echte backup, maar meer een >> actieve << kopie file dienst.

[mrjixies]

Ik heb onedrive en betaal hier voor.

Microsoft hanteerd overal de term backup.

https://support.microsoft...df-4d17-9ae0-6f00f6080adb

Dus dan mag ik er van uit gaan dat het zo is.

[Tjidde]

Je kunt onedrive of Google drive wel gebruiken als back up. Maar dan moet je die omgeving ook totaal beschouwen als backup omgeving.

Dat er betere opties zijn is iets anders.

Maar data staat bij Google, Microsoft of Amazon in de cloud betekent niet dat je data 100% veilig is. Maar dat blijkt al uit dit artikel.

Ik ben wel voorstander om een mirror van je cloud omgeving als je zoveel data en belangrijke informatie hebt te hebben. Of dat on prem is of bij de concurrent maakt niet uit. Zodat als er iets is dat je snel kan omschakelen.

[J_van_Ekris]

Ja, maar die moet je dan specifiek afnemen, en dat is doorgaans een betaalde dienst. Want het maken van (goede!) backups kost best wel wat geld. em Google (of welke clouddienst dan ook) is geen liefdadigheidsinstelling, die gaan dat echt niet gratis voor je doen.

Maar als ze de tennant eruit gooien, dan gaan volgens mij de backups van diezelfde tennant ook weg. Dus dit is niet zo onafhankelijk als je zou willen.

[sdk1985]

Onedrive wordt zo wel aangeprezen en heeft daar ook functionaliteit voor. Zo kun je 30 dagen revisies van bestanden terug halen en willekeurige mappen toevoegen onder de noemer backup.

[Christoxz]

Niet als dat je enige kopie daar bewaard. Dan is het gewoon een opslag dienst.

[Tweakert2020]

Ook 1 kopie ergens bewaren is een back-up.

[Christoxz]

Well.. 'enige kopie' wordt ook wel het origineel mee bedoeld.

Dus als je data alleen maar staat op een backup dienst, is dat geen back up.

[Tweakert2020]

Een kopie kan niet het origineel zijn, anders heet het geen kopie….

Als je data alleen in een back-up dienst staat is het nog steeds een back-up.
Hoe anders kan je data die per ongeluk is verwijderd herstellen?
Is het slim om maar 1 kopie te hebben? Nee absoluut niet.

En nee Google Drive is natuurlijk geen backup dienst. Dat neemt niet weg dat Google wel degelijk Backup en DR diensten aanbied.

[gertvdijk]

Een kopie kan niet het origineel zijn, anders heet het geen kopie….

Technisch gezien gelijk, maar dan kom je in een taaltechnische discussie zoals 'verdieping' waarbij je in het ene land zoals Nederland de extra laag bebouwing bovenop de begane grond bedoelt en in een ander(e) land/taal gewoon eender welke laag inclusief de begane grond. In de dataopslag zoals bijvoorbeeld ZFS wordt vaak dat laatste bedoeld; copies=1 betekent geen redundantie (alleen origineel), want 0 is geen geldige waarde. https://openzfs.github.io.../7/zfsprops.7.html#copies

[RuddyMysterious]

anders heet het geen kopie….

"a copy" in het Engels betekent in het Nederlands geen kopie maar een exemplaar, zoals in "Did you buy this month's copy of Vogue Magazine?"

Uiteindelijk is dit een nutteloze semantische discussie die naast de kwestie is.

[Tweakert2020]

Klopt maar we hadden hier een discussie in het Nederlands

[Dream_ON]

Ook beetje verkeer voorbeeld want die "copy" is wel degelijk een kopie in dit geval. Je koopt in de winkel niet het origineel.

[joenevd]

OneDrive en Google Drive zijn synchronisatie tools. Verwijder je de data lokaal, is het ook weg in de Cloud.

[Tweakert2020]

Ligt er aan hoe je de synchronisatie hebt ingesteld.
Maar je kan best een backup van je data op een Google of OneDrive hebben.

[sdk1985]

Bij onedrive kun je dit 30 dagen ongedaan maken. Dus die redenatie gaat niet op.

[joenevd]

Totdat je pas na 30 dagen erachter komt dat je het kwijt bent. En ja, dat gebeurd. Heb klanten waarbij we onlangs een jaar terug moesten gaan zoeken.

[sdk1985]

Je bent vrij om extra kopiën van je bestanden in diezelfde onedrive te zetten om het scenario waar jij op doelt op te lossen.

Los daarvan is het dus wel een backup. Het is een kopie in de cloud. Waar daarnaast ook nog 30 dagen bescherming op zit. Waardoor de realtime synchronisatie geen issue is (waar dat bij raid1 bijvoorbeeld wel het geval is).

De free space functionaliteit kun je wel vraagtekens bij plaatsen. Dat maakt dat het geen kopie meer is.

[bons]

Persoonlijk vindt ik Onedrive etc meer synchronisatie dienst en zie ik het meer als een actieve replicerende filesystem op punt A maak je een change en punt B gaat per direct mee. Of jij het bent of een malafide process dat de changes doet. Als je veel met echte enterprise backup systemen hebt gewerkt zoals Veeam Backup zie je duidelijk waar werkelijk een rolverdeling inzit tussen een echte dedicated backup oplossing en een synchronisatie tool, wat One-drive in base is.

Dat je een revisie tabel hebt om delta's terug te zetten maakt het niet echt een dedicated backup tool. Het is niet voor niks dat Op Cloud omgevingen boven je One-drive gewoon echte backup oplossingen hangen. Het zij bepaald aangeboden door Microsoft zelf of door een derden.

Je kunt aan elke tool een beetje buigen zodat het wat kan 'shaduwen' wat een andere Tool kan. Op een Thuiskomertje kan ik ook rijden, maar dit is geen vervanger voor een echte band. Op een dag gaat dat fout.

[sdk1985]

Of jij het bent of een malafide process dat de changes doetfout.

Ik snap niet waarom dit punt herhaalt wordt nadat ik er 2x op gewezen heb dat Onedrive hier een 30 dagen revisie systeem tegen heeft. Je krijgt tevens een waarschuwing en een sync stop wanneer er ineens veel bestanden tegelijk verwijderd worden.

Natuurlijk kun jij vinden dat er betere oplossingen zijn. Maar dat heeft geen invloed of je iets wel of geen backup kunt noemen. Een backup: 'a copy of a file or other item of data made in case the original is lost or damaged.' Dat is letterlijk wat je met Onedrive doet. Mits je de free up space functie niet gebruikt.

[bons]

Het probleem is dat een synchronisatie systeem vaak getroffen en uitgebuit wordt door o.a ransomware of andere geinfecteerde processen.

Een kleine voor beeld van een Black hat conferentie van afgelopen jaar: https://www.scmagazine.co...-onedrive-into-ransomware.

Omdat een synchronisatie een actieve dienst betreft waarbij zowel client als server met elkaar deelnemen in een actieve storage pool en dus kan bij een infectie gewoon de waarschuwingen van One-drive / Nextcloud het maakt niet uit worden afgevangen en de gebruiker heeft op dat moment niks door. Dit soort infecties spelen in op de processen van een synchronisatie systeem en de aanvaller weet hoe deze uitgebuild moet worden. Daarom is ook een van de reden bij een goede backup systeem zodra de backup sessie klaar is gelijk een unmount plaatsvind van de dataset en geen active feed openblijft van de filesystem tussen client en server.

Vandaar ook mijn opmerking als je Microsoft 365 omgevingen beheerd Microsoft altijd aanraad om een backup omgeving op je Tenant te gebruike om zo ook je sharepoint/One-drive etc data te backuppen naar in een goed voorbeeld 3 verschillende datasources. Daar zeggen ze niet backup One-drive van je medewerkers nooit, want de revisie vangt dit 100% af.

We hebben helaas enkele gevallen gehad waarbij een One-drive van een medewerker gewoon niet meer te herstellen was vanuit de client server optiek, er moest gewoon een backup uit de archive worden gehaald omdat de infectie huisgehouden heeft. en ja One-drive is gewoon in de onderwereld gewoon een populaire keuze om de misbruik op de focussen en dit is gewoon logisch aangezien dit de meeste gebruikte synchronisatie dienst ter wereld is. Er is gewoon erg veel geld te verdienen in de data van de eindgebruiker.

En ja 3 data sources zijn gewoon nodig, dit artikel op tweakers maakt dit al duidelijk (hoop ik). Deze pensioenfonds kon gelukkig de data herstellen op de 3e source, nadat de eerste 2 hebben gefaald.

[Cergorach]

Hoe is dat anders dan een backup maken op locatie. Verschillende type backups beschermen tegen verschillende dingen.

[Tweakert2020]

Mensen hier snappen de definitie van backup niet.
Waar je het opslaat maakt inderdaad niet uit.

[Reactie gewijzigd door Tweakert2020 op 22 juli 2024 16:16]

[Oon]

Dat wel, maar het telt als hetzelfde medium voor de 3-2-1 methode. Als je je data bij Google hebt staan en ook Google voor back-ups gebruikt is dat wel extra zekerheid, maar moet je er gewoon simpelweg op rekenen dat als Google stopt met bestaan je al je data kwijt bent.

Een tweede clouddienst en/of een fysieke back-up is dan wel echt een vereiste, en gelukkig hadden ze die in dit geval.

[Tweakert2020]

Wat voor soort backup je maakt is een andere discussie, maar inderdaad een offline back-up is verstandig

[willieverhoef]

Maar ook deze zit in het account

[Guru Evi]

Ja, maar als het op dezelfde cloud draait en Google sluit je account af, is het ook wel gewist. Google maakt uit zichzelf backups en replicaties maar als je account gewist wordt wissen ze gewoon de sleutels (ze gaan niet fysiek rm -rf /my_customer doen, gewoon je sleutels verwijderen).

Dit is hier het probleem, de slimste persoon in dit bedrijf is deze die gezegd heeft om een backup te maken op een andere cloud, anders was het ook weg. Dit is het probleem met cloud, alles is goed totdat er iemand een fout maakt en alles in een seconde is weg.

Het advies van mij is altijd een actief-actief tussen 2 clouds, net zoals je vroeger 2 of 3 datacenters had en dan een 3de cloud voor je backups en een tweede backup on-prem, net zoals vroeger, je had hot backups en cold backups en dan elke week ging je de tape manueel in een bureau zetten. Je mag een cloud als 1 datacenter bezien, niet meer.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 16:16]

[syl765]

Als je backup onder hetzelfde account staat dat word opgeheven dan zal alles in één keer verwijdert worden als de dienst denkt het account te moeten verwijderen. Zorg er dus voor dat je data backup bij een andere dienst staat of zoals je steeds vaker ziet weer onprem.

[Vogel666]

Ah, de aloude spraakverwarring over het begrip backup.

Ze namen een kopie van de omgeving af. (In IT-jargon: redundantie)
Het doel van die dienst is: wanneer er om technische reden uitval is van 1 server park (stroomstoring, brand, internetstoring), dan neemt het andere serverpark de dienst over. Deze omgevingen worden bij voorkeur op de miliseconde gelijk gehouden.Verwijder je informatie van de ene omgeving, dan is die ook weg van de andere omgeving.

In leken-taal wordt dat vaak een 'backup'-omgeving genoemd, maar in IT-taal is een backup totaal iets iets anders.

in IT taal is een backup een periodieke kopie van de informatie die voor langere tijd bewaard wordt (in een andere omgeving) zodat je wanneer er iets met de informatie gebeurt, je nog kunt reconstrueren wat de informatie op een bepaald moment tijd geweest geweest is. Handig als je gehackt wordt of je ontdekt dat iemand 3 maanden terug perongeluk ten onrechte info heeft verwijderd.

Gelukkig had deze organisatie beide....of wellicht beter gezegd: dat was geen geluk, maar wijsheid.

[RobbyTown]

Geen idee op wie ik moet reageren er zijn nogal wat reacties.

Dus met andere woorden. Alle bedrijven die Exchange Online hebben dienen dan zelf de mailboxen nog ergens te backuppen (dat deed je vroeger automatisch aangezien je de server ook beheerde) mocht MS de complete omgeving verwijderen.

Ben bang dat vele (kleine) bedrijven naast Exchange Online niet nog zelf een backup hebben van de mailboxen omdat het immers 'veilig' in de cloud staat.

[ro8in]

Zoals ik het begrijp hadden ze ook een backup bij Google afgenomen en zijn die ook verwijderd dus.

[Jorah_Newstone]

Maar google maakt zelf ook geen back ups van de schrijven dan? Als er brand uitbreekt hebben ze altijd nog een B lokatie lijkt mij. Dus er zal vast een manier zijn om data terug te halen.

[sebastienbo]

Dat klopt. De cloud is ook niet echt een backup op zichzelf.

Daar moet je dus ook gewoon een backup van je spullen maken, net zoals dat onpremise ook moet.

.
Straffer, veel mensen denken dat dat syncen een backup is...
Dus als de data gedelete word, dan word die delete gewoon mee gesynced en word alles gewist in je zogezegde backup site...
Hetzelfde gebeurd met een cryptoware/ransomeware, waar al je bestanden genecrypteerd worden, ook dat word gesyncd...

Een geluk dat ze bij deze pensioenfonds nog system engineers hadden die goede maatregelen namen.
Eigenlijk is een backup in een andere cloud eigenlijk ook geen oplossing. Je hoort het offline te hebben.
Ik heb al verhalen gelezen van bedrijven of particulieren dat gerechterlijk onderzocht worden en dan worden al je accounts overal geblokkeerd in afwachting dat de zaak verduidelijkt is... er is soms zelf maar één klacht nodig dat er zogezegd iets illegaal verstuurd is van je account en poef, je accounts worden overal cross-cloud geblokkeerd of gedelete.


In devops waar developers verplicht zijn om het hele system engineering gedeelte op zich te nemen, zie ik vaak dat developers niet het verschil kennen tussen backups en data synchronisatie, en dat kan enorm grote gevolgen hebben.

[Marve79]

Daarom moet je cloud ook backuppen. En liefst niet bij dezelfde provider.

[CPV]

Het liefst niet? Helemaal niet!

[Cergorach]

Dit! En als je een dienst afneemt van iemand, ga ook heel, heel duidelijk na waar ze zelf de dienst hosten. Het zal niet de eerste keer zijn dat men een backup voor bv. Office 365 bij een hele mooie oplossing backupped, maar dat alsnog in Azure gebeurt. Hetzelfde met AWS en GCS.

Note: En neem geen genoegen met wat woorden in een email gesprek of een telefoongesprek. Laat ze duidelijk zwart op wit zetten waar de backup wordt gehost in de 'cloud'.

[Remzi1993]

Maar wat ik niet snap is dat de profiel of account werd gewist maar dat ook tegelijkertijd ook backups werden gewist. En waarom heeft Google intern geen backups juist voor dit soort gevallen en/of andere gevallen zoals bijvoorbeeld stroomuitval of aardbeving. Snap niet dat Google geen backups maakt vooral omdat er fouten kunnen voorkomen.

[wildhagen]

En waarom heeft Google intern geen backups juist voor dit soort gevallen en/of andere gevallen zoals bijvoorbeeld stroomuitval of aardbeving.

Ten eerste zit je dan met wettelijke regels mbt vertrouwelijkheid van de data, privacy etc, waar ze zich aan moeten houden. Als het uberhaupt al mag. En die regels kunnen per land verschillen, dus dat maakt het nóg complexer.

Als tweede, het backuppen van vele petabytes aan data (als het niet nog meer is...) in de hele cloud-omgeving van Google Cloud is gewoonweg niet betaalbaar, en niet realistisch. Zeker niet als er geen geld tegenover staat. Google is geen liefdadigheidsinstelling, maar een commercieel bedrijf dat winst wil maken. Dat lukt niet als je vele petabytes gratis moet backuppen.

Daarom is de backup-functie van Google Cloud dus ook een aanvullende, betalende dienst, waar een klant expliciet voor moet kiezen (en betalen). Als men dat niet wil, zal men zelf een backup moeten inregelen, als klant zijnde.

[Remzi1993]

Ten eerste zit je dan met wettelijke regels mbt vertrouwelijkheid van de data, privacy etc, waar ze zich aan moeten houden. Als het uberhaupt al mag.

Dit mag omdat het valt onder het kunnen uitvoeren van je werkzaamheden en valt onder de dienst. Genoeg datacenters en hosting bedrijven die backups maken van de hele servers en shared hosting omgeving vooral omdat dingen kunnen gebeuren buiten klanten om die zelf fouten maken. In de ICT kan het bij elke plek en plaats in de ketting misgaan.

Zeker niet als er geen geld tegenover staat. Google is geen liefdadigheidsinstelling, maar een commercieel bedrijf dat winst wil maken. Dat lukt niet als je vele petabytes gratis moet backuppen.

Andere doen het dus wel en dit laat dus zien dat Google geen backups maakt. Ik zou ze dus niet met vertrouwen. Maar ik heb ergens gelezen dat je voor backups extra betaald en dat kan ook een van de redenen zijn. Maar bij elke hosting bedrijf waar je een website host bijna elk bedrijf maakt backups. Ik als web developer heb nog geen 1 bedrijf meegemaakt die dat niet doet. (In de web hosting wereld dan).

[Reactie gewijzigd door Remzi1993 op 22 juli 2024 16:16]

[djwice]

Andere doen het dus wel en dit laat dus zien dat Google geen backups maakt. Ik zou ze dus niet met vertrouwen.

Er was iets anders aan de hand. Er was een backup.
Alleen dacht het Google Cloud Platform dat alle account gerelateerde data en infrastructuur verwijderd moest worden. Dat is incl. backups.
Heel goed dus dat die instructie - permanente verwijdering van alles - exact is uitgevoerd conform afspraken.

Als jij een AWS S3 bucket gebruikt van 20TB, dan maakt Amazon daar ook niet nog eens een incremental backup van 20TB-200TB, dat kan, maar dan zal je apart voor moeten betalen.

Dat is een foute aanname, objecten opgeslagen op AWS S3 staan gerepliceerd in 3 data centra in de regio waar je de data onderbrengt. Vandaar dat s3 eventually complete is. Het kost niets extra, het is onderdeel van de basis dienst.

Each AWS EU Region consists of three, isolated, and physically separate Availability Zones (AZs) within a geographic area.

AZs are physically separated by a meaningful distance, many kilometers, from any other AZ, although all [AZs of one Region] are within 100 km of each other.

Your [S3] objects are automatically stored across multiple devices spanning all three AZs.

Vandaar ook dat ze een 99.999999999% durability garantie kunnen geven.

Met object lock kun je er voor zorgen dat er voor een door jou vastgestelde tijd geen wijzigingen of verwijdering gedaan kan worden aan de opgeslagen objecten.

Let wel, stel je zet het op 7 jaar bewaartermijn, dan zit je ook 7 jaar aan de kosten vast.

[Reactie gewijzigd door djwice op 22 juli 2024 16:16]

[ReLight]

Sry maar dit is incorrect. Ook s3 object locked items worden verwijderd bij een account deletion.

>§ Note( product page)
The only way to delete an object under the compliance mode before its retention date expires is to delete the associated AWS account
^

Het hele punt hier is dat er een account deletion process is uitgevoerd. Geen enkele infra/service high availability gaat hier van redden.

Bij aws overigens kan je een account laten herstellen tot 30 dagen na termination.

[djwice]

Oei, dat had dan inderdaad niet geholpen.

Oh, dat herstel wist ik nog niet.
Is dat naar de laatste state of alleen 'hij is er weer vul maar opnieuw'.

Als naar de laatste stage, dan is dat handig. En had in een vergelijkbaar geval bij AWS wellicht geholpen.
Hangt er een beetje vanaf. Ik denk dat als eerst de S3 bucket verwijderd zou zijn - wat alleen kan na het verwijderen van alle versies van de data - en daarna het account, dat de data wellicht ook echt verdwenen is, of niet?

Hmm... Interessant bij overnames. Als accounts worden verwijderd als onderdeel van de verkoop, kan het dus weer hersteld worden. Dat biedt opties 🤭

Ik zie dat het zelfs 90 dagen is (dus bijna een kwartaal): https://repost.aws/knowledge-center/reopen-aws-account - en snapshots zijn na 30 dagen na heropening nog beschikbaar.

[Reactie gewijzigd door djwice op 22 juli 2024 16:16]

[Cergorach]

Andere doen het dus wel en dit laat dus zien dat Google geen backups maakt.

Nee, anderen doen dat ook niet tenzij je daar links of rechtsom voor betaald.

Daar gaan dan ook veel bedrijven de mist in met MS Office 365 en Exchange Online "Daar zal MS toch wel een backup van maken!?!?". Nee dus! En dat staat ook gewoon in het contract als je dat (goed) leest, wat de meeste die dergelijke conclusies trekken niet doen. Als jij een AWS S3 bucket gebruikt van 20TB, dan maakt Amazon daar ook niet nog eens een incremental backup van 20TB-200TB, dat kan, maar dan zal je apart voor moeten betalen.

Elk webhosting bedrijf... Ik weet zeker dat er zat webhosting bedrijven zijn die dat niet doen, dat heb ik immers de afgelopen 20+ jaar in contracten voorbij zien komen van webhosters. Als ze dat voor jou doen, dan betaal je daarvoor, apart of al in de prijs meeberekend. Het issue daarvan blijft natuurlijk dat jou backup verwijderd wordt als je niet langer klant bent. Als er dan door een fout van jou kant of van hun kant een account als 'opgezegd' wordt bestempeld in de backend, en na x periode geheel wordt verwijderd, dan is er natuurlijk geen backup meer. Vandaar, een andere locatie voor je backup.

Ik heb meerdere keren meegemaakt dat er opeens productie servers niet meer werkte omdat de administratie al maanden niet de rekeningen hadden betaald. Of tijdens het verhuizen van een server van de ene subscription naar een andere subscription er wat fout gaat en server foetsie en niemand die het objectID in een CMDB had genoteerd... Nooit die server meer boven water kunnen krijgen...

"Ik als web developer"... Ik wil niet lullig doen, ik ken jou niet of je kennis van zaken, maar web developer zegt niet zo heel veel. Net als systeembeheerder. De hoeveelheid web developers OF systeembeheerders die ik vertrouw met contractuele zaken checken/afsluiten en correct begrijpen is zeer, zeer beperkt. Op diezelfde manier dat ik web developers of systeembeheerders weinig vertrouw met security zaken, ook al zou dat deel van de professie moeten wezen, in de praktijk blijkt dat dit gewoon niet diens discipline is. Zelfs bij legal departments en security is het niet altijd even op orde als je zou verwachten. Maar dergelijke aannames dat elk bedrijf standaard backups maakt en zou moeten maken van jou data is geen juiste. En daarmee versterk je het imago van "Ik als web developer" en de reactie van vele "Uh-Oh!"...

[Remzi1993]

Intern maken hosting bedrijven wel degelijk backups van hun servers, want daar kunnen ook dingen misgaan. Anders kunnen klanten die hun website op hun shared hosting server(s) hebben ze wel aanklagen. Lijkt mij zeer sterk dat zulke bedrijven intern geen backups maken. Het voorbeeld van AWS en Google begrijp ik nog omdat ze eigenlijk iets aanbieden die niet bedoeld is voor een bakkerij om de hoek die zijn website ergens heeft staan (vaak shared webhosting omdat dat het goedkoopst mogelijke is).

Maar of webhosting bedrijven een backup van een hele server beschikbaar stellen is een andere, want vaak moet je inderdaad extra betalen voor een backup service daar of zit het in de prijs inbegrepen. Maar daar had ik het niet over. Ik had het over interne backups van bedrijven die cloud en/of hosting aanbieden.

[Reactie gewijzigd door Remzi1993 op 22 juli 2024 16:16]

[J_van_Ekris]

Maar wat ik niet snap is dat de profiel of account werd gewist maar dat ook tegelijkertijd ook backups werden gewist.

Dit is eigenlijk gewenst gedrag: de betalende klant is weg, dus dan moet vanuit privacywetgeving ook alle data die bij die klant horen vernietigd worden.

En waarom heeft Google intern geen backups juist voor dit soort gevallen en/of andere gevallen zoals bijvoorbeeld stroomuitval of aardbeving.

Die twee backups kunnen fysiek allebei op een ander continent staan dan het productiesysteem, en dan is met 3 continenten de geografische spreiding natuurlijk dik in orde.

Snap niet dat Google geen backups maakt vooral omdat er fouten kunnen voorkomen.

Google is geen liefdadigheidsinstelling, en is ook niet de systeemintegrator. De systeemintegrator moet daarover nadenken, en die moet beslissen of er backups gemaakt worden, of dat er een active-passive of zelfs een active-active oplossing wordt neergezet over meerdere providers (lees Google, AWS, Azure). Die rol kan Google gewoon niet pakken zonder kennis van de data (sommige systemen zijn bijvoorbeeld te dynamisch om normaal te backuppen).

[syl765]

Als de backup onder hetzelfde account valt en dat word opgeheven dan zal alles gewoon verwijdert worden. Je gewone data en je backup.

[Blokker_1999]

Het voordeel van een backup bij dezelfde provider is dat je veel sneller een restore gaat kunnen doen in geval van dataverlies omdat je niet afhankelijk bent van welke snelheden er gehaald kunnen worden over het internet. Wel is het raadzaam om niet alleen bij die provider een backup af te nemen net zoals je in on-prem omgevingen 2 locaties nodig hebt heb je in de cloud minstens 2 aanbieders nodig.

[ajbu]

Zelfs alleen een backup op een andere clouddienst is een risico om alles kwijt te raken. Als het pensioenfonds gehackt wordt (bv randsomware attack) en de credentials/encryptie sleutels van de cloud diensten verloren gaan is er alsnog een probleem. Natuurlijk zijn er veel manieren om dat risico weg te nemen maar je kan er niet naïf op vertrouwen.

Ook, als het hele account gewist is, is de vraag of alle meta-data ook in de backup zit en teruggezet wordt/kan worden. Audit-logs, permissions, histories etc. Zal niet de eerste keer zijn dat backup procedures goed op orde lijken maar bij een echte crisis restore niet gaat zoals verwacht en draaiboeken ontbreken of nooit geoefend zijn

[GMJansen]

Een reallife voorbeeld: een on-prem omgeving is gemirrored in 2 eigen geografisch gescheiden DC's, hebben uiteraard backups, incl historische, op (andere) discs en op tape, , ook weer historisch en ook offsite...
Dat gaat weg, je gaat naar de cloud. Want: goedkoper, alles eenvoudiger, kennis lokaal niet meer nodig en vooral geen lokale servers meer nodig.
Klinkt als een goede business case voor de meeste bedrijven.

Wat ik hier nergens lees: hoe test je in hemelsnaam fatsoenlijk een offsite backup van een cloud omgeving van bv. VM's geautomatiseerd door deze te restoren en te testen -dat gebeurde nl. eerst on-prem-.

Je hebt juist alles geoutsourced naar specialisten in de cloud, want die kunnen dat erg goed...😚

[Blokker_1999]

Ja, dan was alles wat enkel en alleen in die cloud omgeving stond verloren. Vandaar net het belang van backups.

Microsoft, Amazon en ik neem ook aan Google, bevelen ook ten sterkste aan dat je voor backups van je omgeving zorgt, want zij doen dat niet voor je, tenzij je er nog eens extra voor betaald.

Dit is ook waar het verschil tussen redundantie en backups zit. Met een cloud omgeving is het relatief eenvoudig om heel je omgeving redundant te maken. Zijn er problemen in 1 geografische regio, dan kunnen de taken perfect overgenomen worden door een andere regio. Maar dit vereist dat de data tussen regio's gelijk is. Duw je dus slechte data je systeem in, of verwijder je data dan zal de synchronisatie ervoor zorgen dat deze in alle redundante omgevingen wordt gewist.

[wiseger]

Ja dan was alles weg. Dit zijn de risico's van de Cloud.

[yoranpower]

Dat wil ik ook wel weten ja. Want dit is niet bepaald betrouwbaar voor de Google Cloud naam.

[Rolfie]

Waarom? Cloud infrastructuur is geen backup.
Meerdere DC's of locaties is geen backup.

[Tweakert2020]

Waarom? Cloud infrastructuur is geen backup.
Meerdere DC's of locaties is geen backup.

Ze bieden letterlijk deze dienst aan

https://cloud.google.com/backup-disaster-recovery?hl=nl

[wildhagen]

Ja, maar dat is een aanvullende, betaalde dienst, die heb je niet by default, daar moet je dus specifiek voor kiezen en betalen. Stanfaard heb je die dienst niet.

Het staat nota bene ook op je eigen link:

Google Cloud Backup and DR Service is billed monthly, based on usage.

Als je die dienst dus niet afneemt, en veel mensen doen dat niet, heb je dus ook niet de beschikking over die dienst. Wat logisch is.

Cloud in zijn algemeenheid is géén backup, tenzij je daar een betaalde extra dienst voor aanschaft. Doe je dat niet, moet je toch echt zélf je backups regelen.

[Reactie gewijzigd door wildhagen op 22 juli 2024 16:16]

[Tweakert2020]

Maar we weten niet wat ze hebben gebruikt dus snap niet dat men hier er vanuit gaan dat er geen betaalde dienst wordt gebruikt omdat men het woordje Cloud ergens lezen.

Als je een reservekopie van je data in de cloud zet is het per definitie WEL een backup.

[Reactie gewijzigd door Tweakert2020 op 22 juli 2024 16:16]

[Rolfie]

En is nog steeds, account driven. Opzeggen (verwijderen) van je account....

[dasiro]

het account zelf kan gebruikt worden als backup en daarin kunnen ook nog eens backups gemaakt worden, maar het account zélf met alles er in moet ook gebackupped worden.

Kort door de bocht maakt google cloud dus géén backups van accounts en dat is zorgelijk voor zo'n techgiant.

[Rolfie]

Of dit is geen onderdeel van de SLA/afspraken?

Dit is hetzelfde als je backups en servers op 1 locatie hebben staan, en dan gaan "hopen" als er brand uit breekt.

[dasiro]

dat zou kunnen, maar gezien de omvang en andere maatregelen lijkt me dat dit toch een fonds is dat z'n zaken op orde wil hebben, anders ga je niet de moeite doen om nog eens een third-party in te zetten.

[Rolfie]

Wil je in DC's je backup echt goed regelen, draait deze in een 3DCs volledig gescheiden van je huidige netwerk.

[dasiro]

waar ik op doel is dat het account op zich blijkbaar het single point of failure was, aangezien de backups IN het account daaraan gelinkt waren en samen met het account zijn verwijderd, dan mag je die nog in 10 geografisch gescheiden DC's opslaan, als je SPOC failt, dan is alles weg, gelukkig waren ze daar zelf vooruitzienend in, dus hoedje af voor de klant om met de failure van zijn cloudprovider in zijn geheel rekening te hebben gehouden in hun plannen.

[CPV]

Meerdere DC's of locaties is geen backup.

bedoel je echt: "geen"?

[Rolfie]

Ja. Want als je data gesynct wordt, ben je direct alles kwijt.

Meerdere DC's is een hoogbeschikbaarheid, cloud is meestal hoog beschikbaar (of gemakkelijk te realiseren), maar geen backup.

Je kunt natuurlijk in een extra DC wel een backup inregelen.
Of bij een andere cloud leverancier, of in een andere tenant, in een andere locatie.

[CPV]

Ok, je bedoelt: syncen is geen backup, dat klopt.
Backups op 1 locatie is uiteraard ook geen backup.

[Cergorach]

Dat ligt er aan.

Wordt dat gesynced of daadwerkelijk gebackupped op diezelfde infra. Als het daadwerkelijk gebackupped wordt op diezelfde infra is het weldegelijk een backup en geen sync. Maar je heb altijd het risico dat als hetzelfde datacenter omvalt, het bedrijf wordt gehacked of er wat four gaat met facturering en alles wordt gedelete...

DCs over meerdere locaties kan een backup zijn, mits er niet wordt gesynct.

[Rolfie]

Meerdere DC's betekend dat je Applicaties meestal over meerdere DC's draaien.

Offsite backupen, is eigenlijk een 3de DC, andere cloud provider die je backup doet.
Liefst met een gescheiden account / beheer structuur.

[latka]

Alle cloud providers zijn in dit opzicht onbetrouwbaar. Nooit al je eieren ineen mandje stoppen. Niet alles in Azure, Google of AWS tenzij je data niks waard is.

[chime]

Niet noodzakelijk - als een klant zijn gegevens echt weg wilt, dan moeten die weg en mag het dus niet in een backup blijven staan.

Dus ik vrees dat de misconfiguratie zich eerder in die hoek heeft voorgedaan.

Geen zekerheid dat dat het is, maar kan me eigenlijk niet direct iets anders voorstellen.

[ZiSE]

Schijnbaar niet alles maar wel delen als ik deze comment lees in de blog.

These backups have minimised data loss, and significantly improved the ability of UniSuper and Google Cloud to complete the restoration.

[wildhagen]

Dat kwam dus alleen omdat ze nog een derde backup bij een andere cloudprovider hadden staan. Die konden ze terugzetten, waardoor er weinig dataverlies was.

Hadden ze die extra externe backup niet, dan waren ze dus wel alles kwijtgeraakt.

Immers, de twee backups bij Google Cloud waren door Google ook verwijderd door dat foutje.

[moonlander]

Dan nog, regel je niet 1 backup voor zoiets belangrijks.

[wildhagen]

Klopt, je maakt nooit maar één backup. Altijd minimaal twee, waarvan je er dan één offsite bewaard, in dit geval gebeurde dus bij die andere cloudprovider.

Drie backups is altijd nog beter, maar twee is in principe ook voldoende, maar één is dat niet.

Zoals het IT-gezegde luidt: één is géén.

En toch zal je versteld staan hoe laks veel mensen met hun data omgaan. Die denken het staat op OneDrive, Google Drive etc, dus het is veilig en maken vervolgens zelf geen backup meer.

Nou, niet dus. Dat zijn geen backups, maar synchronisatie tools, die een heel ander doel hebben

[bons]

Ik deel je menig hierin.
(normale) gebruikers zijn OneDrive, Google Drive enz, als een backup dienst zijn gaan zien.
Wat mij opvalt is dat deze bedrijven vaak dit ook zo lijken te "verkopen" aan de gebruikers en dus de gebruikers ook verkeerd opvoeden. Hoe vaak ik de popup in Windows niet heb gezien, "sla je bestanden op One-drive op want dan zijn ze veiling". Mensen krijgen dan de impressie, prima dan doe ik dat en dan ben ik klaar. Er wordt verder door de bedrijven niks gerept als opvoeding of transparante uitleg, dat dit een synchronisatie dienst betreft en helemaal geen totale vervanging is van je backups.

Sterker nog sommige mensen verwijzen naar de OneDrive prullenbak als fallback als er een "oepsie" is gemaakt.

[Firestorm666]

We kunnen het er wel over eens zijn, dat het beter is dan helemaal niks zoals "vroeger"
Ook al is je computer vernield door een bom, je kan je data nog terughalen uit "de cloud"

Mensen maken geen back-ups, dus in die context klopt het wel van Onedrive.

[bons]

Maakt het wel in mijn ogen geloven in een illusie. Mensen krijgen een interpretatie van Backup's dat helemaal geen Backups is. Het geeft je iets meer bescherming dan vroeger dan je niks deed ben ik het mee eens. Maar als je een malafide process op je PC hebt aangetrokken en die neemt ook even je One-drive mee (wat niet zo heel gek meer is in deze tijden) ben je net zo goed af als geen backups maken.

Mensen leren het foute type gedrag aan dat een synchronisatie dienst een backup dienst is. Net als "vroeger" geen backups maken ook aan de orde was. Je houd niet alleen nu een oude probleem instant, maar mensen denken nu dat het oude probleem hiermee opgelost lijkt te zijn. Dat is meer het punt hierbij.

[xxs]

En niet alleen offsite maar ook offline of tenminste read-only en beheerd door verschillende beheerders die geen toegang hebben tot elkaars data.

Offline omdat eventuele ransomware absoluut geen toegang mag hebben.
Door verschillende beheerders omdat chantabele of kwaadwillende beheerders geen toegang mogen hebben tot alle data.

[Reactie gewijzigd door xxs op 22 juli 2024 16:16]

[Remzi1993]

Zoals het IT-gezegde luidt: één is géén.

Inderdaad, maar daar wordt ook een kosten baten analyse gedaan. Privé personen of mijzelf ga niet meerdere backups maken want ik ga financieel niet failliet en het heeft geen grote consequenties als mijn data in Google Drive weggaat.

Maar bedrijven moeten dit echt wel doen, maar een kleine bakkerij om de hoek die alleen een website heeft en misschien een beetje klantgegevens en contactgegevens van leveranciers (die je online kan opzoeken) weet ik niet of een dure backup strategie rendabel is. Als een handige neefje bepaalde gegevens op een usb stick kan zetten als backup.

[joost00719]

Er staat nergens dat de backup bij de andere cloud provider, de enige backup was die er bestaat.
Best kans dat ze nog een backup on prem hebben.

[Ludewig]

De database backups zijn bij Google vreemd genoeg gekoppeld aan de DB, dus als de DB wordt weggehaald, dan zijn alle backups ook meteen weg. Daarom is een backup op een andere dienst van groot belang, niet alleen voor als Google een fout maakt, maar ook als je als klant van Google zelf op het verkeerde knopje klikt.

[kimborntobewild]

Eigenlijk was er maar één backup: die bij de andere provider. Zelfs het 3-2-1 backupsysteem is eigenlijk niet eens voldoende voor zulke cruciale data.

[CPV]

Twee backups en je originele data bij Google is nog steeds alles op 1 locatie.
Je moet een backup hebben voor het geval er iets met die locatie mis gaat.

[jaapzb]

Ja

[dr86]

Een backup is toch altijd een kopie, dus als de backup gewist is dan zou je het origineel nog moeten hebben lijkt mij?

[jesse!]

Een backup op hetzelfde account opslaan is niet echt een fatsoenlijke backup.
Dus daar is ook nog wel wat te blame voor bij UniSuper

[Dark Angel 58]

Waarschijnlijk wel, als ze niets voor Archief hebben geprint of op schijven hebben opgeslagen.

Maar ik ruik wel onraad... want het kan zijn dat ze iets willen verbergen... als ze geld hebben witgewassen of weggesluisd, belastingdienst komt dichterbij... bewijzen wegraken... data wissen.
Het wordt echt voor belastingdienst moeilijk als ze helemaal geen data krijgen.

[Tweakert2020]

Had toch gehoopt dat Google zelf ook een back-up had. Teleurstellend dit.

/edit
Bedankt voor het minnen en de reacties.

Ik weet dat jezelf verantwoordelijk bent voor backups.
Zakelijk gezien heb je mogelijkheid om een SLA aan te gaan, wat overigens absoluut geen garantie is.
Ons bedrijf had met AWS een overeenkomst voor wat betreft redundant backups.
Door een configuratie fout van AWS zijn onze containers verwijderd. Ja je krijgt compensatie, nee daar heb je geen drol aan.

Door dit soort zaken gebruik ik zelf geen cloud backup.

[Reactie gewijzigd door Tweakert2020 op 22 juli 2024 16:16]

[fastedje]

Meestal kan je disks en storage nog tot 7 dagen herstellen. Blijkbaar hebben ze bij GCP een forcefull remove gedaan, vreemd.

[coolkil]

Je hebt het hier niet over het verwijderen van een aantal vms of disks. Maar de complete tenant. daar is geen undo button voor (of tenminste niet ingebouwd)

[Tweakert2020]

Je hebt het hier niet over het verwijderen van een aantal vms of disks. Maar de complete tenant. daar is geen undo button voor (of tenminste niet ingebouwd)

Bij een “eindgebruiker” niet nee, bij een admin van Google toch wel had ik verwacht.

[Blokker_1999]

Geen enkele grote cloud aanbieder houdt standaard backups bij van klantendata, dat mogen ze niet eens wegens bescherming van de privacy en vertrouwelijkheid van die data.

[SkyStreaker]

"Sorry, maar er brak bij ons enorme waterschade/brandschade/whateverschade uit, dus al je gegevens ben je kwijt. Oepsie." Lijkt mij niet helemaal de bedoeling, toch? Hoop ik?
Er staat ook dat UniSuper normaal gesproken op twee back-ups kon rekenen en als wij louter op die uitspraak afgaan, ga je al krom.

[Reactie gewijzigd door SkyStreaker op 22 juli 2024 16:16]

[Tweakert2020]

We weten niet wat UniSuper heeft afgenomen, maar wat jij stelt is onzin.

Neem hier een kijkje en je snapt waar mijn verwachtingen vandaan komen Google Cloud Backup and DR

https://cloud.google.com/backup-disaster-recovery?hl=nl

[Reactie gewijzigd door Tweakert2020 op 22 juli 2024 16:16]

[Blokker_1999]

En dat toont exact wat ik bedoel: jij moet zelf de keuze maken om backups en DR in te bouwen in het cloudplatform, jij gaat daar ook voor betalen.

Ik heb het over wat er standaard, out of the box wordt aangeboden. En dat is niets. Verlies je je data, is dat je eigen schuld. Jij bent verantwoordelijk voor het opzetten van een backup strategie. Google, Amazon, Microsoft, ... gaan dat niet voor jouw doen.

[SkyStreaker]

Ik verwacht wel backups (bij gebrek aan een beter woord door gebrek aan inzicht) of een vorm daarvan via parity-drives, uitval kan je zo goed als mogelijk uitsluiten maar nooit absoluut vermijden.

[Yalopa]

Je moet gewoon de service discription lezen ipv hopen.

[Tweakert2020]

Ik gebruik het zelf niet, maar kan toch gewoon verwachtingen hebben?
Daarbij weten wij niet wat voor overeenkomst UniSuper had. Google weet dat ze fout zijn anders komt er geen statement naar buiten.
En ze hebben ook niet voor niks maatregelen getroffen.

[Reactie gewijzigd door Tweakert2020 op 22 juli 2024 16:16]

[Tweakert2020]

Als aanvulling, neem hier een kijkje en je snapt waar mijn verwachtingen vandaan komen Google Cloud Backup and DR

https://cloud.google.com/backup-disaster-recovery?hl=nl

[Reactie gewijzigd door Tweakert2020 op 22 juli 2024 16:16]

[foobar79]

Natuurlijk is dit niet het geval voor de daadwerkelijke data.
Geen van de cloud providers gaat dit voor je doen aangezien het enorme kosten met zich mee brengt.
Vaak hebben ze wel een manier om backups voor je te maken van bijvoorbeeld wat in S3 zit MAAR als je account weg is zal die data waarschijnlijk ook mee verdwijnen.

Logischer wijs zouden de cloud providers een grace-period van de data kunnen moeten aanhouden bij het verwijderen van accounts voordat data daadwerkelijk weggegooid wordt.
Maar dit helpt nog steeds niet als iemand een oopsie doet (of een account wordt door kwaadwillende overgenomen) en bv een bucket per ongeluk weggooit.

Eigenlijk wil je altijd een account bij een andere provider met een backup. Dezelfde dienst vertrouwen met je backups is, zoals hier maar weer blijkt, niet zonder risico's.

[Felicia]

UniSuper kon bij Google Cloud op twee duplicaten van zijn gegevens rekenen, maar deze kopieën werden volgens Kurian allebei gewist. Het pensioenfonds had echter nog een back-up bij een andere clouddienst achter de hand en hiermee kon Google Cloud de gegevens van UniSuper alsnog herstellen. Er zou dan ook sprake zijn van minimaal dataverlies.

Super goed voorbeeld van het 3-2-1 backup principe! 3 kopieën van data op minimaal 2 verschillende media waarvan 1 off-site.

Dat gezegd hebbende, alles waar mensen betrokken zijn worden fouten gemaakt. Daar kunnen we niet omheen en daarom dat er ook controles ingebouwd worden bij bijvoorbeeld het verwijderen van een Azure object. Het is alleen in de vlug-heid dat dat soort dingen gewoon misgaan. Ik heb ook wel eens een productie ERP systeem uitgezet omdat ik dacht op ACC te zitten, oeps

[The Zep Man]

Dat gezegd hebbende, alles waar mensen betrokken zijn worden fouten gemaakt. Daar kunnen we niet omheen

Maar je kan het wel compenseren. Bijvoorbeeld: data wordt in werkelijkheid pas na een paar dagen/een week verwijderd door Google, om zo ruimte te hebben om fouten ongedaan te maken.

[Triblade_8472]

Ja, maar het hangt van je interpretatie af.

Wat is verschillende media? Velen roepen tegenwoordig 'live' en 'immutable'.
Is een ander datacenter bij hetzelfde bedrijf ook een andere locatie?

Hoe ga je gigantische hoeveelheden data uit de cloud halen op een andere media dan 'cloud'? En dat kost ook nog eens gigantisch door de bedragen van uit de cloud halen van data. Laat staan on-prem storage, waar we juist van af willen met z'n allen.

[wiseger]

Hoezo willen we af van on prem storage? Het gaat hier om een pensioenfonds. De gevolgen van alles weg zijn dan catastrofaal.
Juist een pensioenfonds moet goed nadenken over wat stop ik in de cloud en wat hou ik in eigen beheer.

[Triblade_8472]

Dat is de tendens, neem niet alles nou zo letterlijk. Deels wordt ook steeds meer afgedwongen op techniek, abbo of kosten.

Ik ben het met je eens, maar het wordt bedrijven steeds lastiger gemaakt. Zie ook het laatste nieuwsartikel over de Exchange subscription.

Edit:
Waarom "met z'n allen" is omdat niemand er iets tegen onderneemt. Er is gewoon geen (goed) alternatief en degene die er wel zijn gebruiken we massaal niet. Kiezen of delen. En blijkbaar gaan we toch naar cloud dan. Tja.

[Reactie gewijzigd door Triblade_8472 op 22 juli 2024 16:16]

[kimborntobewild]

Super goed voorbeeld van het 3-2-1 backup principe! 3 kopieën van data op minimaal 2 verschillende media waarvan 1 off-site.

Voor zulke cruciale data is 1 off-site backup helemaal niet voldoende.

[Kerfuffle]

Dit is een soort Black Swan event, waar je in je architectuur toch wel rekening mee moet houden. Want ongeacht welke cloud provider je verkiest: Ondanks alle negens achter de komma om aan te geven hoe dicht bij de 100% de durability van een cloud service zit, is het nooit 100%.

Ik heb bij een klant meegemaakt dat door een storing van AWS S3 alle images foetsie waren. Gelukkig hadden ze een multi-cloud setup, en was er een (regelmatig geverifieerde) backup bij Azure waar snel op overgestapt kon worden (en ook de overstap was al eens getest).

[kodak]

Zo te lezen had men er juist vooraf rekening mee gehouden dat ze niet volledog op een dienstverlener kunnen vertrouwen en hebben ze er vooraf voor gezorgd dat als dat zou gebeuren toch nog verder konden. Dat is dus juist geen black swan gebeurtenis.

[Kerfuffle]

Dat een service met 99,999999999% durability toch kan falen, doet velen denken dat dit verwaarloosbaar klein is. Velen verwaarlozen daarmee vervolgens echter ook de impact, terwijl die juist enorm groot is, indien je geen fallback hebt. Dat is een black swan event.

In dit voorbeeld heeft men dit inderdaad correct onderkend. Mijn bedoeling was dan ook daar het belang van te benadrukken.

[david-v]

Dit is wel heel bijzonder. De subscription is verwijderd door een misconfiguratie waardoor data direct? verwijderd werd.

Ik snap niet hoe je het voor elkaar kan krijgen om een subscription te verwijderen door een misconfiguratie. Ik heb geen ervaring met Google Cloud maar dit lijkt op een probleem die ergens gearomatiseerd is uitgevoerd. Als ik handmatig een subscription verwijder bij een andere cloud provider dan krijg je echt tig warnings te zien. Daar kan je echt niet zomaar even doorheen klikken. Bovendien blijft data 30 tot 90 dagen staan voordat het definitief wordt verwijderd.

Ik heb ooit een subscription verwijderd en na een paar weken kwamen we er achter dat er iemand nog gebruik van maakte. De subscription werd hersteld en alles stond er nog.

Hoe is dat bij Google Cloud? Als je een subscription verwijderd is dan alles ook meteen weg?

[Tweakert2020]

Wellicht dat dit door een Google Admin is gebeurt die dit soort waarschuwingen niet ziet.

Bij ons bedrijf heeft AWS ook eens een fout gemaakt waar een maintenance script al onze data heeft verwijderd.

[Vullisbak]

Voor een ieder die de cloud als nimmer falende dienst verwachtte, waar je data altijd veilig staat: zoek eens naar het cloud shared responsibility model.

De cloud provider levert de dienst die jij afneemt (en in welke vorm dan ook voor betaald), onder de doorgaans goed gespecificeerde voorwaarden en garanties (SLA). Er is echter ALTIJD een verantwoordelijkheid voor de klant rondom informatie en data, identities en ook device security.

Een oepsie als deze blijft uiteraard gewoon slordig van Google.

Edit: typo

[Reactie gewijzigd door Vullisbak op 22 juli 2024 16:16]

[nst6ldr]

Dat is echter niet de Nederlandse manier van zakendoen. Het klinkt wat generaliserend, maar van meerdere nationaliteiten heb ik dit al gehoord: in Nederland is de eerste aanbieder die "ontzorgen" roept degene die de zak met geld krijgt, meer criteria hebben ze niet. Bij ons (een ministerie) ligt dit gelukkig (nu nog) anders, maar van veel collega's in de branche hoor ik deze geluiden wel, uitbesteden met de verwachting dat verantwoordelijkheid dan ook uitbesteed is.

[Saven]

Kurian schrijft dat het een uniek voorval betreft en dat dergelijke problemen zich nog nooit hebben voorgedaan bij klanten van Google Cloud, waar ook ter wereld

Misschien niet direct Google Cloud, maar het is niet de eerste keer dat Google per abuis data verwijdert: nieuws: Google: probleem met verdwenen Drive-bestanden ligt aan desktopapp

Goede wake up call weer om je backups op orde te hebben.

[CAPSLOCK2000]

Ach, kleine probleempjes blijf je houden.

Dat Google de macht heeft om met 1 druk op de knop een account te verwijderen met grote gevolgen voor de eigenaar is ontnuchterend maar ook niet nieuw. Iedere IT'er weet hoe destructief de delete knop moet zijn. Toch denk ik dat het voor velen even schrikken is dat het ook kan bij Google kan gebeuren en dat zelfs Google dan geen oplossing heeft.

Hoe het precies fout is gegaan is eigenlijk niet zo interessant. Of het nu een programmeerfout is, iemand op de verkeerde knop heeft gedrukt of een pestkop die het met opzet deed is niet zo belangrijk. Overal kan iets mis gaan. Je moet dus altijd backups hebben. Ook dat weet iedere IT'er. Waar het moeilijker wordt is het derde punt dat iedere IT"er weet, dat je niet al je eieren in één mandje moet stoppen maar dat je backups en reserversystemen buiten de deur moet hebben. Liefst alles in drievoud.

Daar wordt het wat lastiger want tegenwoordig wordt het vaak uitgelegd als drie datacenters van dezelfde cloud. Dat werkt bijna altijd, maar niet als je hele account er uit ligt. Om het echt goed te doen moet je dus ook verschillende clouds gebruiken. Dat kan op zich maar kost je veel van kracht van de cloud, zeker als je de services van de cloudleverancier wil gebruiken.

Backups zou je in ieder geval altijd op een onafhankelijke locatie moeten zodat nooit betrokken zijn bij een ramp op je primaire locatie, of dat nu fysiek is of virtueel.

[bons]

Ze hebben hier gelukkig een backup op een andere bron staan dan de cloud provider dan Google zelf.
Ik ken namelijk veel bedrijven waar dit anders is, want bedrijf x repliceert toch mijn data over 2/3 regio's dus dat is afgedekt. Geen andere backups voorziening nodig.

Het is huilen dat veel bedrijven dit zien net als vroeger; RAID = backup.
Dus waarom geld uitgeven aan een backup oplossing dat voegt dan volgens managers "extra" kosten overhead toe. "want een cloud... daar werken professionals, daar kunnen nooit fouten worden gemaakt, die er wel on-prem waren"

[FrostyPeet]

Ook Google diensten kunnen een single-point-of-failure zijn blijkt maar. Goede wake up call. Komt wel vaker voor dat een "eigenwijze manager" zijn zaak red omdat hij alles ook nog geprint heeft opgeslagen. Of die ene eigenwijze medewerker een kopie van een belangrijk project op zijn flash drive heeft staan. "Black Swans" gebeuren altijd op het ongelukkigste moment, zijn vaak onvoorstelbaar, en gebeuren gewoon.

Ik hoop dat die "extra maatregelen" niet nog een "Are you sure? Y/N" prompt betreft. Die de operator net zo gedachteloos beantwoord als er honderden acties per dag zijn.

De olieindustrie heeft dit probleem opgelost met het "Permission To Work" systeem. Je mag alleen "kritische taken" uitvoeren met een schriftelijke toestemming.