Tu je odpoved: http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2001-11/6464.html
alebo moze ist aj o nahodny reboot, ktoreho zablokovanie je tiez uzitocne. Tlacidlo reset mozno pravdaze zablokovat, ako sa pise v tom odkaze hore.
To neni, ze se musi reinstalovat, ale jen se musi do single user mode (jiny securelevel) a odblokovat flag na urcitem souboru (flags uz ma i Linux).
A ohledne tech podniku a jinych nemehel, kdyby to vubec umeli, tak pouzivaji pfsync + CARP a pak je jedno ze vypadne jeden, dva nebo kolik firewallu(dhcp serveru a jinych soucasti) at uz z duvodu udrzby, HW problemu nebo nejakeho utoku.
Spise vetsinou clovek vidi, ze poradne netusi co s tim a tak jsou po ruce image s instalaci pro Cisco (ktere se prubezne aktualizuji) a kdyz je nejaky problem nebo je nutna oprava, tak se to proste smaze a nainstaluje znova. Fakt profi pristup :-)
Restore image s aktualnou zalohou je castokrat profesionalny pristup. V podnikovom prostredi ide totiz hlavne o to, aby bol system funkcny co najskor. Ked som pracoval v produkcnom prostredi so stovkami AIX servrov, tak rozhodnutie, ci sa bude riesit komplikovanejsi problem (napriklad poskodena ODM - konfiguracna databaza, alebo poskodene struktury LVM) 2-3 hodinovym hladanim problemu a naslednym riesenim (s intenzivnym hladanim v dokumentacii, kedze neslo o problemy s ktorymi sa clovek stretaval kazdy den) alebo 15 minutovym restorom z aktualnej image, bolo vzdy jednoznacne v prospech restore.
Dulezite je to slovo castokrat. Nekdy je restore nejvhodnejsi reseni, ale neznamena to, ze to plati vzdy a za kazdou cenu. Od jistoty, ze sluzby budou pokracovat je tu cluster nebo jeste lepe SSI.
V produkci jsem taky videl krasnou vec. Misto par hodin badani a nasledneho vyreseni problemu se chytrolini z vedeni rozhodli ridit se prezentacema a neposlouchat nazory tech co tomu rozumi a hopla - restore (opravdu velkeho mnozstvi dat) trval pres mesic. To byl zakaznik fakt happy :D
Prece v mem hyper-giga-ultra managerskem telefonu je backup/restore z karty otazkou desitek sekund, na serverech zakaznika to prece nebude jinak no ne? To musim vedet, kdyz mam ty ekonomicke skoly :D
Ono se pokud jde o HA, tak se v podobnych pripadech vyplati bootovat ze SAN a mit pripraveny image pro nejaky takovyhle pripad. Pak se jen vytvori snapshot toho image, pripoji se a system jede skoro okamzite. Dal pak zustane zachovan i puvodni system pro analyzu chyby. Sice cluster ma byt navrzen tak, aby mohl jeden nebo i vice nodu najednou spadnou,ale v praxy to tak obcas neni a tak je potreba dodat chybejci vykon co nejdrive.
Boot ze san jsme zkouseli i produkcne a zamitli pro prilisnou komplexnost a single point of failure problemu.Servery s dedikovanymi vlastnimi systemovymi disky jsou spolehlivejsi. Nemusi se resit taky ruzna geometrie(napr.IBM vs HITACHI) v pripade migrace na jinou storage.
Navic nam pri bootu nefungoval multipathing na Qlogicech-coz je v produkci docela pruser. V pripade chcipnuti SAN pole je cele prostredi v haji. Po restoru pole a restartu clusteru dojde k velmi vysokemu trafficu, kdyz se vsechny servery snazi bootovat tak to halt SANka nerozdejcha(nekolik plne osazenych HITACHI UVP. Jedna se cca o 1500 serveru fyzickych a na kazdem je 5-10 serveru virtualnich.
Ze SANu jedou jen virtualy a bootuje se z mirrorovanych disku. V pripade kritickych systemovych operaci-patche,update se toto provadi jen na jednom disku. A pak se bude zesyncuji nebo v pripade pruseru nahodi z druheho disku. Pokud je nekde nejaky lepsi filesystem jako ZFS nebo LVM2 volume manager tak se udela snapshot.