Met het "backup maken omdat het moet" mis je de doelstellingen. Het is meervoud omdat er meerdere zijn. Zoals:
a/ een Dr-plan waarbij een gehele omgeving verloren gaat (b.v. een datacenter, netwerk, alle endpoints) .
b/ herstel van kleine vergissingen fouten in een draaiende omgeving
c/ (nieuw) herstel van extern aangebrachte schade (ransom of andere hack).
Je zult bij elke doel een plan van aanpak (draaiboek) moeten hebben.

De 0 waarde bij a,b en c is: we doen er niets aan, zien wel als het gebeurt.

ad a/ Voor een DR kun je iets op papier zetten. Je weet pas als het werkt als zonder ook maar iets opnieuw te doen in 1 keer goed gaat. Zoiets heb ik nog nooit meegemaakt. het klinkt raar maar er was altijd wat zodat het pas de 3-e of 4-e keer als geslaagd gemeld werd. Iemand een andere ervaring (omgeving groot en hybride)?

ad b/ Het moet zo goedkoop mogelijk dat zet de volledigheid en consistentie onder druk. Als voorbeeld: Een foute DBMS backup is technisch correct zo gemaakt maar praktisch totaal onbruikbaar. Dit komt vaker voor dan men denkt. Ervaringen?
Dit lijkt in de situatie van het artikel te spelen. Met een terugval op a/

ad c/ Je moet zien te voorkomen dat externe schade aangebracht kan worden in vitale delen. Segmentatie isolatie zijn verdedigingen met een aparte aanpak in het geval van .. in minder kritische zones. Zo'n strategie begint bij een DMZ met een verder scheiding. Er zal best nog meer te doen zijn. Ik mis de aandacht hiervoor.

Dat je midden in een systeemupgrade is iets waarbij de aandacht kan verslappen.
Het is geen excuus voor ontwerpfouten.

@karma4
Wat een warrig verhaal.
Backup werkte niet goed, dus dat was hier het probleem.
Kan ook gebeuren, als er geen ontwerpfouten zijn.....

Voor een thuis zolderhobbyist mag het warrig zijn omdat hij de situatie niet herkend. Kijk eens naar een Enterprise met hybride systemen vele machines en systemen met koppelingen in een datacenter naast alle apparatuur op werkplekken.

Voor een DR (disaster recovery) plan is het incident uitval van het hele datacenter. Echter een compleet DR uitvoeren betekent een tweede datacenter volledig beschikbaar hebben en dan de operatie met uitwijk testen. Zoiets is veel te duur dus worden er beperkte kleine deeltestjes gedaan met alle problemen van dien. De ontwerpfouten sluipen er in.

Voor de dagelijkse backup van de operatie heb je alle genoemde deelsystemen met eigen backups. Die worden zelden gevalideerd dan wel op onderlinge afhankelijk met gaten in de tijd. Dat zijn gewoon ontwerpfouten.

Wat is daar warrig aan? Het is de gangbare praktijk..

Een backup die niet goed werkte door falende hardware, zoiets is een dusdanig kleine kans. Niet zoiets gebeurt niet.
Je kent de verhalen vast wel van goedkope backup hardware en software omdat het toch nooit nodig is. Dat is een ontwerp denkfout.

DR moet je oefenen, niet meer niet minder. Het moet duidelijk zijn wat de procedures zijn, wie welke rol pakt. Uiteindelijk is het ook vaak niet te doen om alles uit in één keer uit te wijken, maar zul je keuzes maken welke applicaties wel en niet. Zoiets zou moeten voortkomen uit een overkoepelend BCM beleid.

De organisaties waarvoor ik werkte die vaak onder druk van compliance zo'n DR test moesten doen, heb ik dan ook eigenlijk nooit zien falen daarmee. Uiteraard was de infra en programmatuur ook dusdanig aangepast dat het in die omstandigheden moest kunnen werken. Denk bijvoorbeeld aan gevirtualiseerd platforms op synchrone SAN in twee verschillende DC's, en goede middleware om gare data transfers in kapotte sessies te kunnen herstellen.

Maar je doet allemaal aannames over feiten, die niet in het bericht staan. Dan zou ik zo kunnen reageren:
Misschien had dit ziekenhuis wel een DR naar een tweede datacenter en was dat vorige maand nog getest.
Misschien liep er de vorige avond een systeembeheerder in de MER en heeft per ongeluk een netwerk of glasvezel stuk gemaakt bij het plaatsen van nieuwe apparatuur. Misschien betrof de systeemupdate wel een nieuwe versie van het backup systeem.
En als iemand jouw warrige verhaal warrig vindt, dan is dat gelijk een zolderhobbyist?

Kan iemand mij vertellen hoe dit word geencrypt door een ransomware.. Gegevens als dit sla je toch niet op in losse bestanden maar in een database op een losse server?

Anoniem, natuurlijk slaagt zo'n DR altijd op papier. Je noemt al de infra en programmatuur aanpassingen welke nodig zijn. Zodra die enkele voor die DR test gedaan worden en daarna teruggedraaid worden wordt het al heel discutabel.
In een apart gescheiden netwerk met een eigen niet gelijk lopende werkplekinfra en meer van dat soort zaken kom je uit op iets als: ja we kunnen een andere machine inrichten die opstart en de data is zo te zien zichtbaar. De benodigde andere servers om de applicatie echt te gebruiken zijn er niet, maar dat valt buiten de test.
Het ergste was dat door het gebruik van gevirtualiseerde machines voor het gemak alle instances op een doos werden aangepast in netwerkadressering. Je gelooft het niet, maar daar zaten productie-systemen bij.
Dat is onder het kleed gegaan en alles werd afgevinkt als fantastisch geslaagde test.

Of wat schat je van het volgende: Central computerruimte vol gezet met verzamelde apparaten (servers) die her en der onder bureaus gezet waren. Wat zou er gebeuren als de stroom weggevallen is en alles in de herstart moet. Lukt niet meer wegens de piekstromen van opstarten.... dat is jammer eerst iemand op zaal overal met de hand de stekker er in dan met de hand per machine opstarten.

Van deze https://forum.synology.com/enu/viewtopic.php?t=88716 een NAS met ransom (Linux 2014) . Antwoorden vragen gezien dat het te duur was om meerdere van dat soort apparaten te hebben. Het is in BCM strategie juist belangrijk om dat in beeld te hebben of je een week maand of langer zonder die data kan, zo nee hoe je dat mitigeert.
Met een dure SAN invoering heb ik meegemaakt dat het verkocht werd met het argument dat de systeembackup (alle applicatiedata als consistent geheel) niet meer nodig is omdat het via de geautomatiseerde duplicatie in twee locaties afgedekt zou zijn. Natuurlijk onzin omdat het foute aangetaste deel (de menselijke fout dan wel de ransom-versie) net zo snel aan de andere kant is.

SAN NAS ze zijn in de techniek wezenlijk anders.

Troost je, na 30 jaar ICT bij grote bedrijven, ondermeer bij IBM, vind ik het ook een warrig verhaal, dus je staat niet alleen ;-)

Is natuurlijk wel onhandig, maar kan inderdaad overal gebeuren.....

He, gelukkig, dacht dat het aan mij lag....
Ik ben inderdaad een zolderhobyist, maar op het werk 1000+ servers onderhouden......