アカウント名:
パスワード:
ビット化け、特にカーネル管理領域のメモリビットが化ければWindowsもUNIXも関係なく、再起動行き。化けたデータでシステムの一部が上書きされた可能性があるならOSが何であれ再構築も視野に入れる。一過性の問題をピンポイントで復旧するか再起動で一括処理するかは、復旧までの時間的猶予と情報収集の必要性で決まることで、やはりOSは無関係。再起動で一括処理した場合でも再発防止の必要性に応じて原因追及すべきだし、再発防止の必要性が原因追究に必要な労力を上回る見込みなら原因追及を放棄するのも、やはりOSに関係しない話。
重要度の低いクライアント用途でWindowsが使われることが多いからって、それをOS自体の特性に含めちゃダメ
# さすがに宇宙用途レベルの対障害性OSは考慮してませんが
>メモリビットが化ければWindowsもUNIXも関係なく、再起動行き。
しかし、それで動いて、ダメダメになっちゃうのもある。そういった例を知らないあなたは所詮はど素人?
>一過性の問題をピンポイントで復旧するか..
以下、ど素人が何かいっているな?レベルで次にいくよ...www
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:0)
ビット化け、特にカーネル管理領域のメモリビットが化ければWindowsもUNIXも関係なく、再起動行き。
化けたデータでシステムの一部が上書きされた可能性があるならOSが何であれ再構築も視野に入れる。
一過性の問題をピンポイントで復旧するか再起動で一括処理するかは、復旧までの時間的猶予と情報収集の必要性で決まることで、やはりOSは無関係。
再起動で一括処理した場合でも再発防止の必要性に応じて原因追及すべきだし、再発防止の必要性が原因追究に必要な労力を上回る見込みなら原因追及を放棄するのも、やはりOSに関係しない話。
重要度の低いクライアント用途でWindowsが使われることが多いからって、それをOS自体の特性に含めちゃダメ
# さすがに宇宙用途レベルの対障害性OSは考慮してませんが
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある! (スコア:1)
>メモリビットが化ければWindowsもUNIXも関係なく、再起動行き。
しかし、それで動いて、ダメダメになっちゃうのもある。そういった例を知らないあなたは所詮はど素人?
>一過性の問題をピンポイントで復旧するか..
以下、ど素人が何かいっているな?レベルで次にいくよ...www