アカウント名:
パスワード:
実際ありがちなんだよな、restoreできないバックアップ処理系になってるパターン長く運用されてデータ量増えたりスケールアウト|アップされたのにバックアップ側変更無しで実はトラブっててJCLだの死活監視だのからはsuccessに見えてるけどいざそのとき使えないゴミデータがバックアップされてるやつ。
私も引継ぎマニュアルをみて、ミラーリングとバックアップサーバありね、ふんふん…と見ただけで流しちゃってその翌月、年次点検で電源落とした時に見事にクラッシュミラーリングのはずのHDDは１つしか刺さっておらず、バックアップは数年前月額制のブラウザゲーなので壊れちゃいましたゴメンナサイは出来れば避けたいというかヤバイメンテの為停止しますとなってから復旧しないため、２chにデータとんだんじゃね？って書かれるしまつ！結局復旧業者で何とか直ったけど一週間止まったよ
手順あっても実際に確認はほんと大事バックアップ終了メールきててもメール文面をみないとか
確認も大切だが復元テストも大事
あるある・・・
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
バックアップの正常動作のチェック (スコア:4, 参考になる)
かく言う私自身も、今のように複数系統のバックアップもストレージ多重化もハードウェアの制約と高価なために中小企業では導入が難しかった頃、小規模システムながら更新前バックアップ処理を失敗した状態で年次更新手順を失敗、取りあえず当年度データは無事で次年度データは作成した物の前年度の月次データを丸々紛失、担当者に帳票から再入力で再現してもらい約半年で復旧してもらったという最悪な状況をつくったことがあったから、複数系統のバックアップとその正常性にはいつも気を使うようになったのですが・・・。
Re: (スコア:5, 興味深い)
実際ありがちなんだよな、restoreできないバックアップ処理系になってるパターン
長く運用されてデータ量増えたりスケールアウト|アップされたのにバックアップ側変更無しで実はトラブってて
JCLだの死活監視だのからはsuccessに見えてるけどいざそのとき使えないゴミデータがバックアップされてるやつ。
Re: (スコア:5, 参考になる)
私も引継ぎマニュアルをみて、ミラーリングとバックアップサーバありね、ふんふん…と見ただけで流しちゃって
その翌月、年次点検で電源落とした時に見事にクラッシュ
ミラーリングのはずのHDDは１つしか刺さっておらず、バックアップは数年前
月額制のブラウザゲーなので壊れちゃいましたゴメンナサイは出来れば避けたいというかヤバイ
メンテの為停止しますとなってから復旧しないため、２chにデータとんだんじゃね？って書かれるしまつ！
結局復旧業者で何とか直ったけど一週間止まったよ
手順あっても実際に確認はほんと大事
バックアップ終了メールきててもメール文面をみないとか
Re: (スコア:0)
確認も大切だが復元テストも大事
Re:バックアップの正常動作のチェック (スコア:0)
あるある・・・