De vraag is waarom is die data corrupt geraakt. Stel dat het een hardware issue is dan had een fail-over kunnen werken, hoewel het heel lastig is om een fail-over systeem een dergelijke fout te laten detecteren. (vaak moet je dan manueel een fail-over triggeren)

Als een input verantwoordelijk is voor het corrupteren van je database dan mag je inderdaad nog zo redunant mogelijk draaien, diezelfde input had al je databases om zeep geholpen.

Op je vraag waarom duurde de hersteldienst zo lang, een vraag die ik hier nog zie passeren.

Als ik morgen geconfronteerd word met een safety systeem welke volledig tilt is geslagen waarbij ik zie dat een of andere config corrupt is geraakt;

Dan ga ik niet even die config file herstellen om vervolgens te zeggen, start het systeem erachter maar weer op want dan ben je aan het spelen met levens.

Die config file herstellen is 1 ding, de root cause achterhalen is iets anders, de volledige werking van je safety systeem controleren zodat je absoluut zeker bent dat hij terug volledig correct werkt, dat is nog een geheel andere koek.

Immers mogelijk is niet enkel die ene config file of dat ene datafile corrupt, mogelijks zijn er ook andere incorrect. Je wilt er niet achter komen dat je safety systeem wel terug online is maar eigenlijk zijn werk niet meer correct doet omdat jij snel snel dat systeem terug hebt vrijgegeven als klaar voor gebruik want kijk, het draait terug en van wat ik hier 1-2-3 zie lijkt het wel ok te zijn.

[Reactie gewijzigd door sprankel op 12 januari 2023 23:32]