GitLab ondervindt problemen door gewiste productiedata

GitLab, dat begon als start-up in Utrecht, heeft momenteel een onbereikbare site. Het bedrijf heeft bekendgemaakt dat de problemen zijn ontstaan door gewiste productiedata en back-upmechanismen die niet werken of verkeerd waren ingesteld.

GitLab, waarmee ontwikkelaars samen kunnen werken aan projecten, heeft het incident gedetailleerd beschreven in een openbaar tekstbestand en geeft af en toe updates via Twitter. Daaruit blijkt dat de problemen de database troffen, waaronder de onderdelen issues en merge requests. De repositories en wiki's zouden echter niet zijn aangetast. Momenteel is het bedrijf bezig om de database te kopiëren, maar zegt dat het proces traag verloopt.

Rond middernacht liet GitLab weten dat de productiedatabase per ongeluk voor een deel is gewist en dat gegevens mogelijk via back-ups teruggezet zouden worden. Een medewerker probeerde een lege directory te wissen, maar deed dit met db1.cluster.gitlab.com in plaats van met db2.cluster.gitlab.com. Toen hij erachter kwam, was er nog maar 4,5GB van de in totaal 310GB aan data over. Daar kwam bij dat verschillende back-upmethodes niet werkten.

GitLab schrijft dat van de in totaal vijf back-upmethodes er geen enkele naar behoren werkte of op de juiste manier was geconfigureerd. Het is nog niet duidelijk wanneer de dienst weer volledig bereikbaar zal zijn.

Reacties (117)

[DennusB]

Oeps... dat is een harde les voor ze. Wel goed dat ze zo goed mensen blijven informeren en dat je zelfs live kan meekijken bij de restore van de database : http://monitor.gitlab.net...from=1485871271986&to=now

[Metis]

Ben geen gebruiker van GitLab maar de manier waarop ze communiceren mag geprezen worden. Er is op dit moment zelfs een livestream van de restore:
https://www.youtube.com/watch?v=nc0hPGerSd4

[Sando]

Waar restoren ze dat van? /dev/zero?

GitLab schrijft dat van de in totaal vijf back-upmethodes er geen enkele naar behoren werkte

[Metis]

Ze hebben de data uit de Staging database server geplukt. Overigens hebben ze wel enorm pech (misschien moet je het geen pech noemen?) gehad. 5 back-upmethodes die niet werken. Ze hadden netjes een replica server maar die was er mee gekapt (vandaar ook het onderhoud en de noodlottige sudo rm -rf )

[tszcheetah]

Ze communiceren goed en zijn ook duidelijk van plan om ervan te leren. Zie hun TODO lijstje op het openbare Google Docs document.

• Create issue to change terminal PS1 format/colours to make it clear whether you’re using production or staging (red production, yellow staging)
• Add alerting for backups: check S3 storage etc.
• Add server hostname to bash PS1 (avoid running commands on the wrong host)

Wat ik daaruit haal willen ze hun back-up-oplossing beter gaan monitoren en zorgen dat dit soort 'oepsjes' minder snel gaan voorkomen door het duidelijker te maken op welke server iemand werkt.

Fouten kunnen overal gemaakt worden - al is dit wel een heel ernstige opeenstapeling van fouten, waarschijnlijk in combinatie met vermoeidheid (het was na 23u bij de desbetreffende medewerker) - maar dat ze zo open communiceren en concrete verbeterplannen noemen siert ze wel in mijn ogen.

[Verwijderd]

Create issue to change terminal PS1 format/colours to make it clear whether you’re using production or staging (red production, yellow staging)

Add server hostname to bash PS1 (avoid running commands on the wrong host)

Dit is toch wel redelijk basic. Ik word iig kriegelig als het ergens NIET zo is, precies om deze reden.

[Tozz]

Het is zo basic, dat geen enkele Linux distributie dit standaard doet.

Kortom, het is niet zo basic.

[CurlyMo]

Ubuntu

curlymo@curlymo-PC:~$ uname -a
Linux curlymo-PC 4.8.0-34-generic #36-Ubuntu SMP Wed Dec 21 17:24:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
curlymo@curlymo-PC:~$ hostname
curlymo-PC
curlymo@curlymo-PC:~$

FreeBSD

[administrator@webdevelopment ~]$ hostname
webdevelopment
[administrator@webdevelopment ~]$ uname -a
FreeBSD webdevelopment 11.0-RELEASE FreeBSD 11.0-RELEASE #0 r306211: Thu Sep 22 21:43:30 UTC 2016 [e-mail]:/usr/obj/usr/src/sys/GENERIC amd64
[administrator@webdevelopment ~]$

Dit zijn de systemen die ik op het werk beschikbaar heb. Ik weet dus ook niet beter dan dat dat wel gewoon standaard is.

Edit:
Voor alleen de hostname dus en niet de FQDN.

[Reactie gewijzigd door CurlyMo op 22 juli 2024 15:37]

[eborn]

Dat is de hostname, niet de FQDN. Als je omgeving geen onderdeel is van je hostname zie je dus geen verschil.

[Torgo]

maar deed dit met db1.cluster.gitlab.com in plaats van met db2.cluster.gitlab.com

In dit geval is de rest van de FQDN hetzelfde, dus de FQDN helpt hier niet. Het unieke gedeelte is de hostname en met de kleur codering wordt het nog iets duidelijker.

[Tozz]

Jij ziet "webdvelopment" als hostname of "curlylo-PC". Niet de rest van de hostname die er bij hoort.

Het probleem is hier dat ze een server hebben genaamd "db1.testing.gitlab.com" en "db1.production.gitlab.com".

In beide machines zie je alleen [user@db1 ~]$ als prompt.

Wat je zou moeten zien is:

[[e-mail] ~]$

Zodat het onderscheid tussen productie en test makkelijker te zien is, en de kans op deze fouten dus kleiner.

[Ibex]

Bizar, op Ubuntu 16.04 is dit voor zover ik weet wel het geval.

[!GN!T!ON]

Nope, alleen hostname, niet de FQDN. (net ter plekke gekeken op twee ubuntu VPSen die ik heb draaien).

[tszcheetah]

Misschien is een ander TODOtje uit de lijst iets duidelijker:

Show the full hostname in the bash prompt for all users by default (e.g., “db1.staging.gitlab.com” instead of just “db1”)

Kortom: ze bedoelen niet alleen de hostname, maar de FQDN ("hostname -f"). Daardoor valt het stukje 'staging' (vs bijv 'production') veel beter op. Ik begrijp dat ze nu alleen maar 'db1' of 'db2' zien maar dus niet de omgeving (zoals het standaard is ingesteld).

[djwice]

zal nog niet goed helpen...
mensen scannen het eerste deel voor de eerste punt vrees ik.

Is get db-nog iets? ok, dan...

Wellicht kunnen ze hun deploy straat automatiseren in acc en prod, en dat die alleen geteste dingen die ook als ok op de test omgeving gedeployed zijn accepteerd?

CloudFormation en verplichte automatische tests op data en flows die succesvol moeten zijn.
En geen mensen die handmatig iets mogen op prod?

[Reactie gewijzigd door djwice op 22 juli 2024 15:37]

[init6]

Mooi dat ze dit publiek bespreken, alleen de naam van de engineer had er niet bij gehoeven. Naar mijn idee werk je als 1 bedrijf en fouten onderga je als 1 bedrijf.

Ik vraag mij wel af waarom er nog niet in hun todo staat om data eens in de zoveel tijd te restoren.

[Yariva]

The page isn't working...

Whoops

[DennusB]

http://monitor.gitlab.net/ -> Deze doet het hier nu wel weer. Soms hapert ie een beetje, ik gok door een enorme berg bezoekers opeens!

[Xm0ur3r]

Problem!
Unexpected error

[Stoelpoot]

Wss wat last van een plotselinge doodsknuffel van het internet. Samen met dat opeens de database het ook erg druk heeft misschien.

[hackerhater]

Kans op ja, dit bericht staat ook op slashdot

[Remenic]

Heeft dat tegenwoordig nog steeds zo'n impact dan?

[hackerhater]

Nooit van het slashdot effect gehoord?
https://en.wikipedia.org/wiki/Slashdot_effect

Kort gezegd : ja.

[Remenic]

Ik bezoek slashdot nog steeds dagelijks maar volgens mij zijn zij tegenwoordig zelf nauwelijks nog verantwoordelijk voor het slashdot-effect. Tegenwoordig trekken sites als Twitter, Reddit en Facebook veel grotere aantallen bezoekers naar zulke sites. Ik denk dan ook dat het gros van de bezoekers een referral-by van twitter.com hebben en niet van slashdot.org ;-)

[Antrax]

Ik vind het anno 2017 nog steeds een hele foute methode om iemand schrijf rechten te geven tot een productie database. Alleen de applicatie zelf zou dit mogen doen, een ieder ander die toegang wilt hebben tot een productie database mag dat alleen met schrijfrechten om dit soort fouten te vermijden. ik blijf het toch maar zeggen.

[DennusB]

Hij heeft het op de server zelf verwijderd he, op het filesystem. Niet in de database zelf..

[ThaStealth]

Je kunt dit ook doortrekken naar hele productieserver. Alleen scripts die in QA gevalideerd zijn mogen op productie uitgevoerd worden.

Ik snap trouwens niet waarom een medewerker 's nachts een lege directory moet wissen op een productieserver. Meestal worden juist fouten gemaakt omdat je laat op de dag/avond nog 'even snel' een foutje wil corrigeren en vervolgens het hele systeem onderuit trekt.

[Yggdrasil]

Zoals je in het 'tekstbestand' kunt lezen is het het gevolg van een menselijke fout door een DBA na een uitgelopen migratie/upgrade van PostgreSQL. Replicatie werkte plots niet meer en de medewerker, die vermoeid en gefrustreerd was, voerde een commando op de verkeerde server uit.

Als ik het zo lees kan men nog heel wat leren en verbeteren qua procedures om dit soort fouten te voorkomen. Echter waardeer ik de openheid wel. Ik denk dat iedereen die in Operations werkt wel eens iets vergelijkbaars gedaan heeft en meestal is dat het moment waarop men besluit de procedures aan te scherpen.

[P-e-t-j-e]

Misschien werken ze in shifts qua onderhoud en wordt het bewust 's nachts gepland.

[Kees]

'nacht' op het internet voor een internationale site bestaat niet. En het is dan wel erg dom om onderhoud in te plannen op momenten dat mensen moe zijn en er uberhaubt minder mensen te bereiken zijn.

[Blokker_1999]

Wanneer een klus lang duurt ga je niet zomaar zeggen: mijn tijd is om, ik ga naar huis en probeer morgen de draad weer op te pikken. Dan verlies je enorm veel productiviteit en laat je systemen achter in een ongekende staat.

[Kees]

Daarom zeg ik ook dat dit niet bewust in de nacht geplanned was maar iets wat 'gewoon' opdook tijdens normale werkzaamheden

[P-e-t-j-e]

Het bedrijf is gestart in Utrecht en ik weet niet wat er bij het onderhoud allemaal offline gaat/herstart wordt maar dat het een internationaal bezochte site is wil niet zeggen dat ze er hier ook 24 uur per dag met volledige bezetting aan werken, dat kan prima alleen overdag zijn (bij ontwikkeling en netwerken) en 's avonds alleen maar onderhoud en ondersteuning.

Ik ken genoeg bedrijven die onderhoud 's avonds inplannen omdat er dan minder bezetting is, zeker als het om server reboots gaat of het offline brengen van essentiële bedrijfsprocessen. Die monteurs/technicians doen vaak niets anders en zijn gewend aan het werken in ploegen. Dus 'dom' is erg kort door de bocht mijns inziens, wellicht dat het wel met vermoeidheid te maken kan hebben gehad maar dat is niet persé voor de hand liggend.

[djwice]

Waarom gebruiken ze niet gewoon een Lambda die kijkt of een directory leeg is en hem dan van de S3 storage verwijderd? (AWS hosying immers).

[pumpidumpi]

Kijk naar het rapport wat ze geschreven hebben. Er waren al issues die ze probeerden te fixen.

En uiteindelijk zal er altijd iemand toch een keer bij moeten kunnen in bepaalde gevallen. En als die dan onder tijdsdruk een fout maakt...

[Martin Sturm]

Je bent duidelijk nooit on-call geweest voor een high-traffic platform. Good luck met het vinden van een oorzaak en oplossen van issues zonder schrijftoegang (en je wil ook niet je halve bedrijf wakker moeten bellen om dan iets te kunnen schrijven midden in de nacht als er shit de fan aan het hitten is).
Wat dat betreft is de voorafgaande timeline van het issue wel een leuke schets van hoe zoiets gaat... als je dan geen schrijfrechten hebt, zou je platform aanzienlijk vaker onbeschikbaar zijn. Met geen klanten meer als gevolg.

[H!GHGuY]

En een lege directory wissen doe je met rmdir, niet met "rm -Rfv".

[tympie]

Klinkt leuk, "alleen scripts die in QA gevalideerd zijn", maar:

• Dat voorkomt niet dat een script per ongeluk op de verkeerde server wordt uitgevoerd.
• Ga je bij een incident op de productieserver eerst het incident reproduceren op QA (voorzover überhaupt al mogelijk), vervolgens daar oplossen, de oplossing scripten, testen, en dan pas uitvoeren op productie? Wat betekent dat dan voor je doorlooptijd?

Tja, waarom iemand een lege directory wist: er is een issue, daar is iemand mee bezig, en diegene denkt op dat moment op basis van de symptomen die hij ziet, dat dat een mogelijke oplossing is. Valt van buitenaf weinig van te vinden. En tja, het was misschien laat op de dag, maar gitlab is een wereldwijd, 24/7 gebruikte dienst. Het probleem tot de volgende dag laten liggen was waarschijnlijk ook geen optie.

Zo even snel als "stuurman aan wal", dingen die bij mij als eerste opkomen hier:

• Meest belangrijke: backups controleren, restores testen.
• Replicatie opzet ook in QA (zodat daar ook getest kan worden, procedures gemaakt kunnen worden, en er dus minder kans is op het pas in productie aanlopen tegen fouten). Geen idee overigens of dat hier wel of niet gedaan is.
• 4-ogen principe bij acties in productie.

[Reactie gewijzigd door tympie op 22 juli 2024 15:37]

[REDSD]

Je hebt een goed punt, maar als er problemen ontstaan, dan heb je meestal niks aan dit soort procedures en heb je als nog rechten nodig om het probleem op te lossen.

Als software altijd naar behoren zou werken zou dit probleem goed af te vangen zijn, maar aangezien dit zelden het geval is moet je er vanuit gaan dat je mensen hebt die het kunnen oplossen met de genoeg rechten tot het systeem.

[Verwijderd]

Hij dacht dat hij werkte op een kopie van productie. Dan nog vind ik het niet echt netjes om standaard write access te hebben op een productieserver. Dit incident gaat hopelijk zorgen voor betere regels omtrent toegang.

[djwice]

Dat is toch het hele issue, waarom heeft iemand handmatige rechten in prod?

Met AWS is dat echt niet meer nodig, mits je het goed inricht.

[P-e-t-j-e]

Heeft hij dan bestanden verwijderd die vanuit de database worden gelinked of de bestanden van de database zelf? Ik neem aan het eerste en dat de databasefiles zelf gelocked worden door de databasesoftware en dus niet verwijderd kunnen worden...

[hackerhater]

Ooit gehoord van de uitdrukking "Root is god"?
Hierom dus. Root mag alles.

[mxcreep]

Ook daar zitten beperkingen aan, heb toch regelmatig met lsof moeten uitzoeken welk proces een bestand of folder in gebruik had voor ik bijvoorbeeld een umount kon uitvoeren.

[WhatsappHack]

Unmount kan je ook gewoon forceren. Of 't slim is is een tweede en afhankelijk van hoe belangrijk een clean unmount is, maar er is niets dat je qua rechten tegenhoudt om de unmount als root te forceren.

[hackerhater]

True, maar je hebt wel de rechten om dat specifieke process de nek om te draaien.

[Tozz]

umount is ook wel wat anders dan rm. rm werkt op een UNIX systeem (in tegenstelling tot Windows) altijd, en daarbij maken open files ook niet uit.

[DennusB]

Nee, hij heeft (zo ver ik het goed lees) de bestanden van de database zelf weggegooid..
Als je vervolgens je database restart dan doet ie niet zoveel meer

[Reactie gewijzigd door DennusB op 22 juli 2024 15:37]

[mxcreep]

Bij Postgres zijn standaard alle folders / bestanden eigendom van de postgres user, althans op een RHEL installatie. In dat geval moet je dus of jezelf postgres/root gemaakt hebben tijdens het klussen of met sudo aan de slag zijn geweest.

[RagingPenguin]

Hij was met sudo bezig geweest ja. En als je dam rm -rf doet is het gewoon weg.

[djwice]

Stonden deze hier niet op AWS?
Wellicht op S3?
Dan komt er wellicht nog een extra stukje roles&right management op de storage lasg bij kijken naast hoe je de EC2 met Linux OS inricht.

[Verwijderd]

Ik neem aan het eerste en dat de databasefiles zelf gelocked worden door de databasesoftware en dus niet verwijderd kunnen worden...

In linux heeft root totaalbeheer over het systeem. Een programma kan niet zomaar bestanden locken. Daarom wordt er ook dik gewaarschuwd bij het gebruikt van root dat je ook weet wat je aan het doen bent. Een van de redenen voor het bestaan van "sudo" komt hierdoor.

[the_shadow]

Je doet niet zo veel tegen iemand met sudo rechten op een productieserver.

[YopY]

Daarom moet je niemand sudo rechten op een productieserver geven. Zeker tegenwoordig is het bijna triviaal om een nieuwe server de lucht in te trekken, waarbij alle eventuele stappen in code staan - en daarmee door een reviewproces en OTAP-straat kunnen gaan.

D'r was een discussie elders over dat je een draaiboek moet hebben, four-eyes, etc, maar da's allemaal maar behelpen en je voorkomt human error daar niet helemaal mee. Beste is om de menselijke factor gewoon eruit te halen.

[Kees]

Ook dan kunnen er nog vreemde problemen optreden die je niet in de code kan verhelpen en die je niet of heel erg lastig kan reproduceren op een testomgeving en waarbij je dan op de server zelf moet gaan kijken wat er aan de hand is. Zeker de problemen die ze in dit document beschrijven ga je niet in code oplossen.

[david-v]

Dat is een utopie, de voordelen van bijvoorbeeld een DB admin wegen op tegen de nadelen van de rechten die een dergelijke persoon heeft. Als je een prio 1 hebt op een high performance systeem waar er een probleem is opgetreden in de database dan heb ik liever een dat een DB admin het probleem tijdelijk kan fixen en dat je daarna in de code het probleem oplost, als het aan de code lag. Dat laatste is niet altijd het geval. Praat mar eens met een DB Admin...

[Durandal]

Misschien probleem oplossen in een productieomgeving dan maar met zijn 2en achter een scherm?

Sowieso is het gek 4 backup methodes te hebben en op geen van allen te controleren of de data ook daadwerkelijk terug te halen is.

[hackerhater]

En hoe wil je dan nieuwe systemen opzetten, mensen rechten geven, etc?
Uiteindelijk zullen er altijd mensen zijn die god-powers op een machine hebben.
Dit was niet zomaar een medewerker, dit was de DBA.

[Reactie gewijzigd door hackerhater op 22 juli 2024 15:37]

[Raventhorn]

En dan komt die noodlottige productieverstoring, waarbij door foutieve data je applicatie niet meer werkt maar niemand schrijfrechten heeft op de productiedatabase om het euvel met een paar simpele queries te verhelpen...
Nu is dat in een klein bedrijf vaak wel te ondervangen en snel verholpen, maar in een groter bedrijf kan zo'n procedure langere tijd duren (tot hele dagen storing).

Natuurlijk moet lang niet iedereen zomaar toegang hebben tot de productiedatabase, maar beheer (bijv. door een DBA) en noodtoegang zijn ook zeker noodzakelijk.

Een medewerker probeerde een lege directory te wissen, maar deed dit met db1.cluster.gitlab.com in plaats van met db2.cluster.gitlab.com.

In dit geval lijkt het er echter op dat het ging om toegang op het file-systeem. Dan kan je iemand wel toegang tot de database ontzeggen, maar als de files weg zijn kan de database ook niet veel meer... In ieder geval zodra de huidige caches in het geheugen geleegd zijn.

[Kees]

Hij had root toegang tot de databaseserver-vm dus dat gaat volledig buiten de database zelf om. Daarnaast, niet alles kan door een applicatie gedaan worden (en ook dan kunnen er fouten in voorkomen). Het is echt niet uitzonderlijk dat een one-of query even met de hand uitgevoert word en daar heb je soms schrijfrechten voor nodig.

En op servernivo is het ook vrij lastig om root toegang tot een een directory te verbieden en het is niet iets wat standaard gedaan word.

That said, als je met rm dingen weggooit en de applicatie draait nog, dan is er een hele grote kans dat de filedescriptors nog open staan en die kun je dan gewoon terugzetten, het is pas een probleem als je gaat paniekeren en de database restart (of als de database crashed) Dat hadden ze al gechecked, maar blijkbaar houd postgres de files niet open.

[Reactie gewijzigd door Kees op 22 juli 2024 15:37]

[david-v]

Hoe je het ook inregelt, er is altijd wel iemand die direct of indirect rechten heeft of kan verkrijgen in de database. Een DB admin zonder die rechten is als een ontwikkelaar met alleen leesrechten op een GIT. Onwerkbaar.

Fouten worden nou eenmaal gemaakt. Wat wel kwalijk/nalatigheid is: "van de in totaal vijf back-upmethodes er geen enkele naar behoren werkte of op de juiste manier was geconfigureerd"

Dat vindt ik anno 2017 nogal amateuristisch overkomen.Nog nooit een restore test uitgevoerd blijkbaar.

[Yoshi]

ik veronderstel niet dat je al vaak met een dba gesproken hebt hierover? :-).

[Mathieu_Hinder]

Er is een Google Docs waarin je hun notes kan volgen: https://docs.google.com/d...CxIABGiryG7_z_6jHdVik/pub

Er zijn ook een aantal jammerlijke dingen in te vinden als:
- Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored. According to JN these don’t appear to be working, producing files only a few bytes in size.
- Our backups to S3 apparently don’t work either: the bucket is empty

Zo'n dingen check je toch eens me dunkt

Al bij al is er 6 uur aan data verloren als de meest recente beschikbare backup lukt. Geen enorm drama, maar wel enorm slecht voor hun reputatie en professionaliteit.

[kmf]

set&forget zijn dat sort dingen.

Wanneer was de laatste keer dat je je backups gecheckt had? Dus niet alleen dat ze daar staan, maar ook te restoren zijn?

[TagForce]

Doen wij maandelijks of elk kwartaal.
Wij doen dagelijks checks of de backups lukken.
Maandelijks checken we of de backup sets nog wel de juiste data bevatten (nieuwe servers toevoegen, verwijderde data uit de set halen, etc.
Afhankelijk van de wensen van de klant doen we ook elke maand of elke 3 maanden een restore test.

[kmf]

Afhankelijk van de wensen van de klant

dus de klant zal daar dan ook voor betalen.
Als het voor een eigen bedrijf is, hoe vaak zal dat in de praktijk gebeuren.

En doe je die checks manueel of met scripts die zelf ook fout kunnen gaan?

[TagForce]

Met het handje... Kost ongeveer 0,2 FTE aan tijd.
Maar inderdaad, die checks zitten in de contract prijs bijgevoegd, dus uiteindelijk wordt daar gewoon voor betaald.

En zelfs dan gaat het nog wel eens fout. Maar dat heeft voornamelijk te maken met de hoeveelheid aan verschillende backup systemen die we as-is overgenomen hebben van vorige partijen en de onduidelijkheid die dat soms meebrengt.

[rhk22463]

Uitgebreide restore+leestest doen we maandelijks, dagelijkse check op verloop van backups en evt restores. Verplichte routine en ja... het is altijd veel werk maar inmiddels weten we niet beter en plannen voldoende tijd en mensen in op dag x iedere maand.
De business doet de controle dan op maandag op de set die is gerestored voor hen, zij werken niet in het weekend...
Als je dit een paar keer hebt gedaan zijn ook de onhandigheidjes eruit en loopt alles soepel maar wachten op de offsite restore is nog steeds koffie+pizza-tijd

[Reactie gewijzigd door rhk22463 op 22 juli 2024 15:37]

[Power2All]

Ik gebruik ook S3 voor backups, duply is zo lekker.
Apart dat Gitlab niet checkt om de zoveel tijd of alles werkt... beetje nalatig..

[Firefly III]

Ik vind het leukste van dit soort nieuwsberichten nog wel alle stuurlui die hier vanaf de wal goedbedoelde tips en trucs delen. Van die "captain hindsight"-verhalen. Ze hadden geen schrijfrechten mogen hebben, ze hadden dit niet moeten doen, of juist wel, bla-bla-bla.

Het is allemaal ongelofelijk waar wat jullie zeggen maar niet erg zinvol voor de discussie. Hoe het had moeten gaan is zelden interessant. Want dat is niet gebeurd.

Wat ik veel interessanter zou vinden, maar dat durft wellicht niemand te delen, is hoe ze ooit zelf van zo'n fout hersteld zijn.

Want niemand hier maakt me wijs, ook niet de beste stuurlui aan de wal, dat zij nog nooit per ongeluk iets in productie gesloopt hebben.

[CurlyMo]

Wat ik veel interessanter zou vinden, maar dat durft wellicht niemand te delen, is hoe ze ooit zelf van zo'n fout hersteld zijn.

Voordat ik mijn offsite backup goed en wel had draaien (in mijn privé situatie) draaide ik een backup alleen op een externe harde schijf. De rest wat ik in een eerdere post "hindsight" beschrijf was wel geregeld, zoals notificaties. Toen werd er ingebroken en was alles qua computer apparatuur weg, behalve die ene externe backup harde schijf.

Ik had overigens wel een offsite backup geregeld voor mijn online projecten, omdat de omvang van die data veel overzichtelijker was (paar 100MB). De reden dat ik privé nog geen offsite backup had is omdat ik 1TB aan belangrijke data in de backup wil hebben staan en nu dus ook staat.

Mijn backup strategie was privé dus niet op orde, maar zakelijk zeker wel, vanaf het begin al en voordat ik mijn privé situatie op orde had gebracht. Je persoonlijke data kwijt zijn is nog iets anders dan je zakelijke reputatie kwijt zijn en dus geen inkomsten meer te hebben.

[Reactie gewijzigd door CurlyMo op 22 juli 2024 15:37]

[eborn]

Met veel pijn en moeite kan ik je vertellen. Nu was de productie in mijn geval de lokale kantooromgeving. Maar door een fatale RAID-set crash (4 van de 12 disks dood) was mijn complete VM omgeving naar zijn grootje.

Van de 30 VM's werden er zo'n 5 volledig gebackupped (elke nacht, full backups), maar van de rest niet. Van alle data werd wel netjes een incrementele backup gemaakt, dus dat was allemaal niet verloren. Maar het meeste tijd ging zitten in het terugbrengen van alle VM's in hun oorspronkelijke staat. Uiteindelijk kun je nog alle data en /etc bestanden in de backup hebben staan, maar het correct terugzetten van de volledige machine blijft een rotklus.

Het vervelendste om op te lossen was nog een simpel Hadoop data cluster met 3 losse datanodes en een namenode, welke op diezelfde VM meedraaide. Doordat de namenode weg was, en er geen (goede) backup van de metadata was, moesten we met de hand alle bestanden op de datanodes doorlopen en terugzetten. Gelukkig was alle brondata nog beschikbaar, net als alle tabel specificaties. Maar dan nog is het een klusje wat je maar één in je leven wilt doen.

Inmiddels hebben we er van geleerd en wordt er nu van (bijna) alles elke nacht een volledige VM backup getrokken. De data wordt ook nog eens los incrementeel gebackupped (zowel lokaal als offsite). En alle machines worden nu gedeployed via Puppet, waardoor de configuratie altijd weer 'snel' terug te zetten is, mocht er toch iets misgaan met de VM backups.

[hackerhater]

Ik heb eens een keer de verkeerde VM gewhiped. ww dacht dat ie niet gebruikt werd, dus wel
OOPS. Direct goede backup test

En mijn eerste ww hielp een keer met testen door de database op test te resetten.
Tenminste dat dacht ie. Dat was dus productie.
Was ook direct een mooi voorbeeld waarom je met de creds van de DB moet inloggen en niet met root.
Productie en test hadden expres aparte creds

[Reactie gewijzigd door hackerhater op 22 juli 2024 15:37]

[MrMonkE]

Sneu voor ze.
Hopelijk is het niet de doodsteek en kunnen ze er lering uit trekken.

Ik heb ook wel eens wat op productie gesloopt, toen ons bedrijf nog klein was.
Ik had er ook voor gewaarschuwd dat het een keer mis zou gaan in die opstelling die we toen hadden. Niet super ernstig en zeker niet zo catastrofaal als dit, maar wel mijn eer gekrenkt.
Hoe hersteld? Nou niet, gewoon 13 records pleite. Voor altijd.

Nu is het bedrijf veel groter en zijn er veel meer regels en procedures voor live systemen, iets wat voor startups denk ik moeilijk op te brengen is omdat het veel geld kost en je door klein personeel bestand veel overlap hebt op functies die bij grote bedrijven bij specifieke mensen zijn belegt. Ook is het veel burocratischer, iets wat in een startup volgens mij ook remmend werkt. We hebben veel regels en procedures die dit moeten afdwingen maar dat kost best wel wat tijd, moeite en geld.

[wouter0100]

Jammer, jammer. Platform is erg mooi, maar Gitlab.com is nog verre van betrouwbaar. Maak er sinds ~2-3 maanden actief gebruik van, maar toch toevallig elke keer als ik GitLab nodig heb, is er iets met de runners of de site.

Hopelijk kunnen ze een (redelijke) recovery maken en z.s.m. wat procedures aanscherpen en scripts versimpelen (want die zijn blijkbaar ook allemaal ongestructureerd en een mess).

[Coffee2Code]

Je kan hem ook zelf hosten

[wouter0100]

Yes, maar dan krijg je de gratis Shared Runners niet en heb zelf geen zin/tijd deze omgeving op te zetten en onderhouden. GitLab.com is (althans, zou) een mooier alternatief zijn.

Daarnaast draait GitLab.com ook de EE versie (Enterprise Edition), niet de CE versie (Community Edition). De EE versie geeft wat leuke features die je gratis kan gebruiken op de GitLab.com omgeving, met oneindig private repositories.

[Reactie gewijzigd door wouter0100 op 22 juli 2024 15:37]

[Coffee2Code]

CE heeft ook oneindig repos en een gratis runner, enige wat je niet kan is ldap auth en "pages"

[WK100]

Zoals Anthraxium-64 zegt, kun je deze gratis lokaal draaien. Dan spreek ik over de Gitlab Community Edition. Ik heb ook zo'n servertje en je zou deze kunnen spiegelen met de Gitlab.com-omgeving zodat je nooit last hebt van downtime als deze.
Je hebt dan een bijna identieke service in beheer dat zowel voordelen als nadelen kent; voordeel is natuurlijk dat jij de baas bent, en de nadelen zijn bijvoorbeeld dat jij 'm zo nu en dan moet updaten en bijhouden.

Zeker als je private repos gebruikt is dit interessant, gezien je dan geen abonnementen hoeft af te sluiten; het enige wat je dan (zonder abonnement) niet kan doen is spiegelen - hetgeen ik hierboven noemde.

Kortom: genoeg mogelijkheden om toch redundant te werken

[Reactie gewijzigd door WK100 op 22 juli 2024 15:37]

[Sharkoon]

Mooi om te zien dat de rust bewaard wordt en geen vingers wijzen maar naar oplossingen zoeken en er van leren. En mooi om te zien hoe transparant het is en live stream problem solving.

[tistjendop]

Vind ik ook Sharkoon. Ik heb gitlab steeds een voorbeeld van openheid gevonden en zelfs in deze moeilijke momenten laten ze iedereen meeleren van hun ervaringen. Mijn hoed af.

[Mraedis]

Dit is ook een prima voorbeeld van hoe je niet alleen backups moet nemen, maar ook regelmatig moet verifiëren of die backups überhaupt werken.

Een aantal jaar terug zijn we er zo achter gekomen dat de backup voor een forum dat ik mede beheerde (~5k actieve gebruikers) foutief werd weggeschreven, dolle pret dat allemaal terug te zetten.

[Lordfox73]

Au. Vijf backup methodes die niet bleken te werken. Dat betekent te weinig controles op het proces, en geen DR plan met een gedegen test. Au.

[CurlyMo]

GitLab schrijft dat van de in totaal vijf back-upmethodes er geen enkele naar behoren werkte of op de juiste manier was geconfigureerd.

Naar mijn mening kan kan je iets niet als backup beschouwen als je de validiteit en betrouwbaarheid niet ook actief test. Oftewel:

No SQL dumps were made as a result. Fog gem may have cleaned out older backups.

1. Er had met periodiek iemand handmatig de backups moeten testen door ze terug te zetten in een test omgeving (wat een replicatie is van productie).

Dit had je dus al heel snel moeten zien bij een wekelijkse (handmatige) controle, laat staan dat dit nou niet bepaald complex om via een test script te testen of een SQL dump wel is gemaakt en wanneer nodig je te notificeren.

We don’t have solid alerting/paging for when backups fails, we are seeing this in the dev host too now.

2. Men had op de hoogte moeten zijn via een notificatie dat de backup werkt en wanneer hij faalt.

Zelfs in mijn thuisomgeving krijg ik dagelijks een melding dat de backup heeft gedraaid. Daarmee zie ik al direct wanneer een backup faalt (of wat ooit is gebeurt is ingebroken). Ook van mijn offsite backup locatie krijg je dagelijks een mail als de backup heeft gedraaid.

Ik noem dat dus geen backup strategie.

[Reactie gewijzigd door CurlyMo op 22 juli 2024 15:37]

[xzaz]

Ze hadden een strategie alleen niet zo'n goede.

[MsG]

Toen hij erachter kwam, was er nog maar 4,5GB van de in totaal 310GB aan data gewist.

Tweakers schrijft het precies andersom. Op hun tekstpagina staat juist dat er van 310 nog maar 4,5 GB over was, een stuk erger dus.

Ergens wel goed dat ze zo open en transparant communiceren maar ergens verlies je ook het vertrouwen als ze open en eerlijk communiceren dat alle 5 backup-vormen niet afdoende blijken te werken. Bedrijfstechnisch minder handig denk ik.