Volgende keer een leverancier kiezen die ZFS ondersteunt en snapshots aan heeft staan. Probleem in seconden opgelost. Daarna zoeken waar het vandaan kwam. Maar ja, zo handig zijn de hosters over het algemeen niet.

Altijd weer een gelovige . Kun je lezen, buiten fanboy'en voor ZFS ?

Hier was , volgens TS, het hele platform van de hoster impacted - over zes datacenters - wat geeft je het idee dat ZFS en z'n snapshots immuun gebleven zouden zijn ?

Verder - ook datacenters kunnen in de fik vliegen - zoals bleek in Frankrijk . ZFS (of whatever lokaal FS met snapshots) heeft echt de data gewoon lokaal staan .
Met genoeg pech moet je kunnen terugvallen op off-site en off-line backups.

Waarom die sneer naar Minister Yessi? Trouwens je schrijft automatisch, niet otomatisch, dat weet elke spellchecker.

Misschien moet ik het nog even verduidelijken. Je kunt met je site, of met je server, of met een heel datacenter het mooiste kasteel van de wereld bouwen. Met op het dak kanonnen, musketten en pijl en bogen. Liefst op een heuvel. Als dan de ottomanen komen, of de russen of de barbaren, dan knal je die lachend de vallei uit.

Het wordt een stuk lastiger met andere gevaren. Mieren. Die wandelen vrolijk heuveltje op. Hoeven maar een een klein gangetje te graven. En aan al je kanonnen heb je niks. Maar je zit wel met een mierenplaag. Achter je mooie kasteelmuren.

Mijn provider heeft dat goed gedaan. Alle routers dicht. Zodat er niks meer naar binnen kon kruipen. Maar ook niet naar buiten. Daarna eerst analyseren, alles op een rijtje zetten. Dan alles terug op zijn plek zetten. Maar dan zonder mieren. Wat ze gelukkig konden. Zelf geen mier in mijn server gehad trouwens. Maar een paar buren in het datacenter wel. Misschien zelfs tot in hun handige snepsjots.

Mijn post gaat erover dat je het op zich niet kunt testen. Je kunt niet voor de gein zeggen, we gooien zes datacenters plat en dan gaan we even testen hoe lang het duurt tot we alles vanuit ons mooie redundant systeem van backups te restoren. Want dan ben je gelijk de helft van je klanten kwijt. Die daar maar weinig begrip voor hebben want alles hoort altijd te werken.

Het was meer een wetenschappelijke security vraag, dan een vraag om meningen. Backups terugzetten kost tijd. Al die moederbordjes zijn maar zo snel. Al die netwerken kunnen niet sneller dan ze kunnen. Security is niet enkel dat je redundancy in orde is. En al je interne en externe backups gemaakt zijn. Hoe lang het duurt om alles terug te zetten, en ook weten dat het dan daarna weer goed komt, daar denken we wellicht nog wat weinig over na. Ik had bijna hele domme dingen gedaan met mijn externe backup. Dan was de puinhoop nog veel groter geweest. Als het echt niet anders kan, je moet die USB sticks uit die schoenendoos halen die veilig onder het logeerbed staat, hoe lang duurt het dan voordat je weer operationaal bent. En wat moet je dan allemaal nog handmatig herstellen. Dat hoort denk ik deel van een goed securityplan te zijn. Het mijne is afgelopen week herschreven. Blij dat ik op mijn handjes ben blijven zitten. Met afgekloven nagels. Meer dan waard om ook even te delen hier.

Ik kan me voorstellen dat dit heel veel stress geeft. Zelfs als je je backups goed op orde hebt (complimenten daarvoor) dan is het nog altijd de vraag of alles te herstellen is. Vaak is dat in de praktijk nog weleens lastiger dan in de theorie. Zelf ook meegemaakt dat een backup juist als je die echt nodig hebt dan even net niet wil terug spoelen met een of andere onduidelijke foutmelding. Terwijl de airco in je nek staat te knallen en je met je 10% accu laptop op de datacenter vloer zit. Je kunt je als mens dan ineens heel klein voelen.

Overigens veel van die ransomware aanvallen onthullen ook het feit dat veel bedrijven dit totaal niet op orde hebben. Anders zouden ze immers kunnen restoren, daar hoor zelden iemand over maar ik heb sterk het vermoeden dat dit een van problemen is.

Heb je inmiddels kunnen bepalen hoe het heeft kunnen gebeuren?
Zou toch wel vervelend zijn als het volgende week weer voorkomt.

Het gebeurde , zo te lezen, op het platform van zijn hostingprovider .
Die hebben alle virtuele server omgevingen weer hersteld - maar leeg. De inhoud van die servers was voor de klanten (de TS dus) om te restoren.

Hoe het bij die hostingprovider misging - misschien communiceren ze dat, misschien niet - maar TS zit daar niet aan de knoppen.

Daar heb ik overheen gelezen, my bad.

Goed, je was een paar dagen offline. De wereld is niet vergaan. Part of the deal. Niet te vaak doen.

Fanboy’en? Jij snapt niet hoe _groot_ de oplossingen met ZFS zijn in de praktijk. Ik mag toch echt aannemen dat een provider van enige omvang gebruik maakt van SAN’s. En die kunnen fantastisch repliceren, juist inclusief snapshots, zeker met ZFS. Verdiep je eens in de technologie, die al heel lang beschikbaar is en op heel grote schaal en in heel grote datacenters wordt gebruikt voordat je reageert. Deze provider had blijkbaar een heel beroerde architectuur in elkaar gedraaid. Was er wel sprake van architectuur of is het organisch gegroeide meuk… In ieder geval geen professionele inrichting.

Je snapt het niet . (en ja, ik heb ook een tijdje gewerkt op een plek met een paar PB data op ZFS) .

Als je host/bare metal platform ge-ransomwared (de laag waarvan de kernel ZFS draait en de storage aanhangt als LUNs) dan kan de ransomware je data helemaal stuk maken . Botweg de snapshots deleten is één optie, en live versie encrypten is één optie .
Een echt verkeerde actie repliceert natuurlijk gewoon mee - hetzelfde probleem heb je met DB's . Resilience tegen een 'storing' is niet altijd voldoende tegen een 'operator fout' cq malicious actie.

De redding van snapshots is handig zolang het betreffende OS platform van de storage omgeving nog betrouwbaar is.
Dan kun je simpelweg de "oeps verkeerde delete" van een gebruiker of een applicatie prima herstellen .

Als malware een tijdje ongemerkt z'n gang kan gaan op een voldoende laag niveau heb je in heel veel setups een groot probleem.
En is alleen maar een mooi filesystem echt niet vanzelf de redding.

(FWIW , vmware belooft natuurlijk ook dit soort dingen , en kan ook best erg robuust zijn tegen gewone storingen, of tegen problemen _binnen een VM_ , als het goed ingericht is . Ook een SAN, ook snapshots van VMs etc . En ook grote problemen als het probleem niet beperkt blijft tot iets binnen een VM maar op de hypervisor laag zit).

Goed verhaal voor awareness en risicomanagement: wees je bewust van je risico's, ook al heb je je zaken uitbesteedt aan een betrouwbare leverancier (of je eigen betrouwbare IT organisatie).
Business Continuity (door kunnen tijdens "ellende") en Disaster Recovery (herstellen na "grote ellende") zijn primair verantwoordelijkheden van de directie/de business en niet van de leverancier of eigen IT afdeling.
Wel moet de directie kaders stellen aan de IT leverancier (of eigen IT afdeling), en middelen (geld) hiervoor beschikbaar stellen. Daarmee kan de juiste IT (producten en/of diensten) geselecteerd worden om te voldoen aan wat de business nodig heeft.

Grootste uitdagingen:
- het vastleggen van business vereisten door de directie, plus realiseren welke kosten hieraan verbonden zijn!
- het vertalen van business vereisten naar IT architectuur of diensten door de IT leverancier

Ik heb zelf een leuke sessie meegemaakt van het CCRC (Cyber Chain Resilience Consortium), een stichting die oefeningen in cyber incidenten binnen een keten (bedrijf, (cloud)leverancier, andere leveranciers) organiseert. Juist aan bedrijfsleiding geeft dit heel veel inzicht in waar het binnen hun eigen bedrijf fout kan gaan.
De casus zoals TS die weergeeft zou perfect passen: pas NA een incident realiseert men de eigen blinde vlekken...

Q

Al snel worden technische oplossingen als bv. ZFS aangedragen waarmee alle problemen opgelost zouden kunnen worden. Natuurlijk bestaan er geen allesomvattende oplossingen. Anoniem van maandag 23:24 beschrijft het goed: je hebt bescherming op alle niveau's nodig: op applicatie, op host systeem (bv AV, redundancy), op opslag (journalling, mirrorring, raid), maar ook op de hele hypervisor laag eronder (servers, SAN, RAID, netwerk, management), én op locatie (uitwijk, load-balancing etc.). Heel veel technieken zijn Business Continuity maatregelen (hoe houd ik de boel draaiend bij een verstoring).
Voor Disaster Recovery (hoe herstel ik als het echt mis is gegaan) is vaak minder aandacht.
Hoe vaak heb ik niet gehoord: ik heb geen tape backup (lees: Disaster Recovery) nodig want ik heb een gemirrored SAN met RAID over twee locaties (lees: super goede Business Continuity)!
Het beste antwoord wat ik hoorde van van een SAN leverancier daarop was: "Wij garanderen dat wanneer Uw software een fout maakt en data op het primaire SAN corrumpeerd, wij die corrumpering 100% nauwkeurig binnen enkele milliseconden ook naar het andere SAN kopieren!" :-). Kortom: ook dan moet je (offline) backups hebben.

In de jaren 90 (de tijd van veel mini's) hadden we een "Backup reliability service": een klant kon ons hun tapes sturen, en wij gingen kijken
- óf hiermee het systeem volledig hersteld kon worden qua compleetheid van backup (vaak in eerste instantie niet...)
- óf hiermee het systeem consistent hersteld kon worden (denk bv. aan open databases en redo-logfiles)
- hoe lang het duurde om het systeem volledig te herstellen (RTO)
- hoeveel data/transacties er misten (RPO)

De conclusie was vaak dat in eerste instantie de backup niet volledig was. In tweede instantie dat de backup niet intern consistent was omdat of open bestanden niet gekopieerd werden, of dat ze niet intern consistent waren (bv. halverwege transacties)
In derde instantie dat de backup getuned was op snelheid van maken van de backup ipv. snelheid van restiren van een backup: als je steeds incrementele backups maakt (lekker snel bij maken) moet je heel veel tapes teruglezen (langzaam bij herstel, terwijl je dan snelheid nodig hebt. In vierde instantie dat er wijzigingen waren doorgevoerd sinds de laatste backup die niemand meer wist.
Natuurlijk helpen een aantal middelen (journalling file systems, snapshots, backup API's etc.) om die backups tegenwoordig beter te maken maar de eisen zijn ook veel hoger: denk bv. aan 24/7 web shops: heel korte RTO zonder verlies van data (RPO).

En dan nog blijft de noodzaak van oefenen van uitwijk: binnen de mainframe omgeving een standaard, binnen de uitbestede cloud oplossingen wordt het als "te duur" gezien. Of dat werkelijk zo is weet je pas nadat je het geprobeerd hebt... Ervaringen met sloepenrol (uitwijk van één DC naar een hot standby) was dat je altijd wat vergat, en pas na een aantal weken iedere week één avond oefenen ging dat in een half uur ipv. helemaal niet of de hele nacht...

En dan lees ik en moet denken aan de meest toepasselijke uitspraak mbt. BC/DR: "failing to plan is planning to fail"

TS: dank voor het delen van je ervaringen! Ik hoop dat er wat mensen hun eigen omgeving weer eens kritisch tegen het licht houden

Q

Zoals hierboven wordt aangegeven is Backup en Disaster Recovery een vrij complex verhaal. Daarom is het in een professionele organisatie normaal dat je daar een heel plan voor maakt op basis van je RTO en RPO tijden. Dit is ook niet 'een zweterige nerd' in de hoek van een datacenter, dit plan is voor een heel team en de gehele organisatie moet hierbij worden betrokken.

Deze procedures worden verder minimaal 1x per jaar volledig getest zodat ook getoetst wordt dat het plan uitvoerbaar is (ander heb je er niets aan).

Het verhaal dat je hierboven schets geeft enkel een beeld dat je provider niet professioneel met backup om is gegaan of doelbewust een RTO van 5 dagen heeft gehad. Dat kan je wel terugvinden in je SLA neem ik aan. Laten we maar helemaal niet ingaan op het feit dat security bij de provider enorm gefaald heeft.

Daar had je natuurlijk van te voren over na moeten denken. Genoeg literatuur. Onder windows blijft het trouwens altijd een feest. Je hebt geluk gehad dat je backup niet is versleuteld.