はじめに
この記事は、「本番環境などでやらかしちゃった人 Advent Calendar 2024」の15日目の記事です。10年以上前にグループウェアのデータベースを破損してしまった体験を共有させて頂きます。
当時の状況
- 職場環境：中小企業(インフラ担当は私のみ)
- 業務内容：PCやネットワーク全般
-
システム状況：
- 社内運用のグループウェア（OS：Windows Server）
- バージョンアップは不定期
- 物理サーバ運用(仮想化・クラウド未導入)
アップデートが引き起こす「罠」
軽い気持ちの計画が命取りに
グループウェアの新機能を知らせるメールに心が躍り、「試してみたい！」という気持ちが高まりました。しかし、すぐの実施は危険だと判断し、翌週末に作業を計画。
休日のアップデート作業が始まる
休日出勤して、グループウェアのアップデート作業を開始。リモートデスクトップを使いながら手順書通りにインストーラを実行します。順調に進んでいるように見えましたが、3時間後にインストーラの進捗表示画面が消え、状況が不明に。さらに3時間ほど待ってみた後、焦りからプロセスを強制終了した結果、グループウェア全体が使用不能に…。
誰にも頼れない現実
もちろん保守契約していますのでサポート内容を確認しましたが、土日対応の窓口がなく、相談相手もいない状態。結局、自力での復旧を試みるしかありませんでした。
バックアップに頼る「復旧作戦」
NAS頼みのバックアップに潜む罠
グループウェアのバックアップは簡易的なファイルコピー方式でした。復元作業を開始しましたが、復元完了予定が7時間とのこと。焦燥感に苛まれながら作業を進めました。
7時間後の絶望
復元が完了してもMySQLが正常に起動せず。グループウェアは依然として使用不能のまま。
しかも、トラブルによって動揺しているため、問題点を冷静に判断できていなかったと思います。
リストア作業の事前検証の重要性を実感しました。
トラブルから学ぶ「教訓」
なぜ失敗したのか？
- リリース直後のアップデートを実施
- データベースのテーブル変換に必要な時間を想定していなかった
- バックアップ体制が不十分だった
アップデート前に考慮すべきこと
- バックアップからのリストアを事前に検証
- リストア手順書を作成する
- ロールバックポイントを考えておく
- トラブル時に相談できるよう一人で作業しない
- リリース直後のアップデートを避ける
- 可能ならテスト環境を用意して、事前に問題ないか検証する
再発防止の対策
環境によりけりですが以下のいずれかの対策を実施するよう心がけてます。
- クラウド移行
- 仮想化環境でスナップショットバックアップを取る
- 物理サーバ運用なら、サーバ更新時にバックアップ・リストア検証を実施
トラブルの顛末
グループウェアサーバーを新規構築し、半壊状態のMySQLからなんとかエクスポートで一部データを取り出すことができました。もちろん、それでも社内に多大な迷惑をかけ、謝り倒す状況となりました。
あとがき
ここまで読んでいただきありがとうございました。
なにかのお役に立てば幸いです。