偶発的なワイプコマンドにより重要な生産データベースサーバーがダウン

The Situation

韓国を拠点とするマネージドサービスプロバイダーは、クライアントのNetAppシステムの構成を変更しようとして、エンジニアがLUN上で誤って「dd」コマンドを打ち込んでしまいました。このため、エンドユーザーの稼働Sybaseサーバーの一部であるデータが、事実上消えました。

データにアクセスできなければ、このプロバイダーは顧客との契約を失うだけでなく、賠償費用も請求される可能性がありました。

問題のプロバイダーには、161 x 900GB SAS HDDを含むNetApp FAS8060システムがあり、2つの別々のアグリゲート（68ドライブ+ 93 ドライブ）に配置されていました。各アグリゲートからは、Sybaseサーバーに3 x 468GB FC LUNが提示されていました。6つあったLUNは結合して1つのディスクプールとなり、3つの論理ボリュームがプールから切り出されました。誤った「dd」コマンドは、論理ボリュームの約45GBにゼロを書き込み、このボリュームはSybaseサーバーから見えなくなりました。

The Solution

最初の相談中、エンジニアは、オーバーライトによる損傷を防ぐため、アグリゲートをオフラインにするようこのプロバイダーに指示しました。アグリゲートは、最初のデータ損失が発生してから12時間でオフラインになりました。その後、両方のアグリゲートから161個のHDDすべてが単一のWindowsマシンに提示され、オントラックのRDR（リモート・データリカバリ）サーバーに接続されました。

最初の検査で、両方のアグリゲートの名前が「aggr0」であることがわかり、エンジニアがアグリゲートを自動的に再構築することができなくなりました。ドライブはアグリゲートグループに分類され、そのアグリゲートは手動で再構築されました。当社のエンジニアは、可能な限り最近の時点までアグリゲートを再構築できました。別々のアグリゲートで「dd」による損傷が発生する前の、2分以内の時点まで再構築されました。

The Resolution

論理ボリュームがSybaseサーバーによってRAWストレージとして使用されていたため、エンジニアは内部データを抽出または検査できませんでした。そこで、6つのすべてのLUNがフラットファイルとして外部ストレージに抽出されました。NetAppサポートは、これらのLUNをSybaseサーバーに戻しました。論理ボリュームが復旧し、Sybaseサーバーの整合性がチェックされ、問題ないことがわかりました。これですべてが正常に機能するようになりました。エンドユーザーのデータベースサーバーは、データが失われることなく、障害発生から数日以内にオンラインに戻ることができました。

Share Print Page