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
TS "Ik heb na twee dagen regelmatig op het punt gestaan om de stomste dingen te doen met de backups die ik in elk geval zelf had. Wat het alleen maar erger had kunnen maken."
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