アカウント名:
パスワード:
実際ありがちなんだよな、restoreできないバックアップ処理系になってるパターン長く運用されてデータ量増えたりスケールアウト|アップされたのにバックアップ側変更無しで実はトラブっててJCLだの死活監視だのからはsuccessに見えてるけどいざそのとき使えないゴミデータがバックアップされてるやつ。
私も引継ぎマニュアルをみて、ミラーリングとバックアップサーバありね、ふんふん…と見ただけで流しちゃってその翌月、年次点検で電源落とした時に見事にクラッシュミラーリングのはずのHDDは1つしか刺さっておらず、バックアップは数年前月額制のブラウザゲーなので壊れちゃいましたゴメンナサイは出来れば避けたいというかヤバイメンテの為停止しますとなってから復旧しないため、2chにデータとんだんじゃね?って書かれるしまつ!結局復旧業者で何とか直ったけど一週間止まったよ
手順あっても実際に確認はほんと大事バックアップ終了メールきててもメール文面をみないとか
> 年次点検で電源落とした時に
法定点検で電源落としたら再開時にネットに接続できなくなって、原因調べたらISPへの料金滞納が発覚したというひどい話もあったな。フレッツはISP側から回線切断することができないのでこっちから切るまで発覚しないらしい。
ああやっぱり回線って強制切断は出来ないのか学生時代にアレでアレな事をしている時にISPへの接続がbanされる時でも接続中なら大丈夫だった事がある と聞いた
確認も大切だが復元テストも大事
実際に復元テストしようにも、テスト用の復元先環境なんか、オンプレミスだと用意して貰えないって事の方が多い気がする。
あるある・・・
SEしてた頃、しなかったな…復元テスト…。もし失敗したら、また1から環境の作り直し。確実に納期に間に合わない!先輩に「これほんとにリストアできるんですかね?」と聞いたら、「さあ?」という答えだったのが今でも忘れられない。
そんな時嘘でもたぶんといえるそんな優しい人に私はなりたい
それも笑顔でね…。
復元テストといえばMySQLのバックアップが作られていた環境でバックアップの手順として、OSコマンドでフォルダをコピーという形で取得されていたんだけど止めずにコピーしていたので、復元できるかテストをしたらやっぱり壊れてた
壊れたデータを取ってる可能性があるので、見直しはほんとだいじ
興味深いのですが、特定されそうな内容。会社からお叱りを受けませんように。
障害対応の予行演習は必要なんですが、現行のサービスを止めずにとなると、なかなか手を出せないでしょう。しかし、コスト高を嘆いて放置するより、対応策を考える方向で。そうだ、超展開でいこう。
GitLab.com、バックアップも使えずピンチ! 時間ももう残っていない…「グレートGitLab.com、発進!」(中略)グレート「お前の役目はもう終わった」
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
バックアップの正常動作のチェック (スコア:4, 参考になる)
かく言う私自身も、今のように複数系統のバックアップもストレージ多重化もハードウェアの制約と高価なために中小企業では導入が難しかった頃、小規模システムながら更新前バックアップ処理を失敗した状態で年次更新手順を失敗、取りあえず当年度データは無事で次年度データは作成した物の前年度の月次データを丸々紛失、担当者に帳票から再入力で再現してもらい約半年で復旧してもらったという最悪な状況をつくったことがあったから、複数系統のバックアップとその正常性にはいつも気を使うようになったのですが・・・。
Re:バックアップの正常動作のチェック (スコア:5, 興味深い)
実際ありがちなんだよな、restoreできないバックアップ処理系になってるパターン
長く運用されてデータ量増えたりスケールアウト|アップされたのにバックアップ側変更無しで実はトラブってて
JCLだの死活監視だのからはsuccessに見えてるけどいざそのとき使えないゴミデータがバックアップされてるやつ。
Re:バックアップの正常動作のチェック (スコア:5, 参考になる)
私も引継ぎマニュアルをみて、ミラーリングとバックアップサーバありね、ふんふん…と見ただけで流しちゃって
その翌月、年次点検で電源落とした時に見事にクラッシュ
ミラーリングのはずのHDDは1つしか刺さっておらず、バックアップは数年前
月額制のブラウザゲーなので壊れちゃいましたゴメンナサイは出来れば避けたいというかヤバイ
メンテの為停止しますとなってから復旧しないため、2chにデータとんだんじゃね?って書かれるしまつ!
結局復旧業者で何とか直ったけど一週間止まったよ
手順あっても実際に確認はほんと大事
バックアップ終了メールきててもメール文面をみないとか
Re:バックアップの正常動作のチェック (スコア:5, 興味深い)
> 年次点検で電源落とした時に
法定点検で電源落としたら再開時にネットに接続できなくなって、原因調べたらISPへの料金滞納が発覚したというひどい話もあったな。フレッツはISP側から回線切断することができないのでこっちから切るまで発覚しないらしい。
Re: (スコア:0)
ああやっぱり回線って強制切断は出来ないのか
学生時代にアレでアレな事をしている時にISPへの接続がbanされる時でも接続中なら大丈夫だった事がある と聞いた
Re: (スコア:0)
確認も大切だが復元テストも大事
Re:バックアップの正常動作のチェック (スコア:1)
実際に復元テストしようにも、テスト用の復元先環境なんか、オンプレミスだと用意して貰えないって事の方が多い気がする。
Re: (スコア:0)
あるある・・・
Re: (スコア:0)
SEしてた頃、しなかったな…復元テスト…。
もし失敗したら、また1から環境の作り直し。確実に納期に間に合わない!
先輩に「これほんとにリストアできるんですかね?」と聞いたら、
「さあ?」という答えだったのが今でも忘れられない。
Re: (スコア:0)
そんな時嘘でもたぶんといえるそんな優しい人に私はなりたい
Re: (スコア:0)
それも笑顔でね…。
Re: (スコア:0)
復元テストといえば
MySQLのバックアップが作られていた環境で
バックアップの手順として、OSコマンドでフォルダをコピーという形で取得されていたんだけど
止めずにコピーしていたので、復元できるかテストをしたらやっぱり壊れてた
壊れたデータを取ってる可能性があるので、見直しはほんとだいじ
Re: (スコア:0)
興味深いのですが、特定されそうな内容。会社からお叱りを受けませんように。
障害対応の予行演習は必要なんですが、現行のサービスを止めずにとなると、なかなか手を出せないでしょう。
しかし、コスト高を嘆いて放置するより、対応策を考える方向で。そうだ、超展開でいこう。
GitLab.com、バックアップも使えずピンチ! 時間ももう残っていない…
「グレートGitLab.com、発進!」
(中略)
グレート「お前の役目はもう終わった」