NetApp ファイラーを使用した超高速バックアップ＆リカバリ

今日は何となく時間があいてるので久々の oracle ネタです。本業ではデータベースとして mysql と oracle を使っています。ぶっちゃけ oracle の方がいろいろと面倒です。面倒極まりないことの１つとしてバックアップ＆リカバリがあげられますが、あるソリューションを適用することでめちゃくちゃ簡略化することができました。もっとも、ここ１年ほどは危機的な障害とは無縁ではありますが・・・。

さていきなり結論ですが、そのあるソリューションとはずばり NetApp ファイラーのことです。別に oracle に限った話ではありませんが、データベースのストレージとして NetApp ファイラーを候補の１つに考えてみてはどうでしょうか？

- スポンサーリンク -

ぶっちゃけ NetApp ファイラーですが、最低構成で数百万円（多分、会社によって価格はかなり違うが300万円程度だった・・・）します。単なるストレージと見れば非常に高価です。駆け出しのベンチャー企業の方々には高嶺の花に映ってしまうかもしれませんが、ある程度の規模のシステムを有しているならこういったソリューションもあるんだという興味でこの記事を読んで頂ければと思います。

別に NetApp 社員でもなければ回し者でもありませんし、大好きなアフィリエイトでもないわけですが、NetApp ファイラーはかなり便利に使ってます。この手の話がブログに書かれているのを見た記憶もないので、いつかは記事にしようかと思っていたところでした。ちなみに僕が携わっている業務のシステムはこんな感じの構成になっています。いろいろな意味でお金かかってます。はい。

system.jpg

この NetApp ファイラーの何がそんなに便利なんだ？と申しますと、snapshot 機能につきます。snapshot 機能はその名前の通りある時点のディスクの状態のスナップショットつまりバックアップを作成する機能です。しかも、そのスナップショットが僅か１秒程度で作成が完了してしまいます。そのカラクリですが、NetApp ファイラー上のデータファイルは 4KB のブロックが複数割り当てられた形で配置され、snapshot はファイルがどのブロックに割り当てられているかを示すマップ情報のみコピーし、実データのブロックはコピーしないため、非常に高速に snapshot が生成可能となるわけです。具体的なイメージは下記の通りです。

netapp01.jpg

NetApp ファイラーを使用した oracle 超高速バックアップ

この snapshot の機能を使えばデータサイズに依存せず瞬間バックアップが可能であることがおわかり頂けたと思います。これを oracle のバックアップの手順で考えてみます。手順はコールドバックアップとほぼ同じです。データファイル等を file-copy 等でバックアップする部分が snapshot に置き換わるイメージです。

  1. ALTER DATABASE BEGIN BACKUP;
  2. snapshot の作成で全てのデータファイル等 oracle に関連するファイルをバックアップ。コマンドレベルで具体的に記述すれば、
    rsh -l root LUN名 snap delete ボリューム名 old　　で２世代前のsnapshotを削除
    rsh -l root LUN名 snap rename ボリューム名 new old　　で１世代前のsnapshotを作成
    rsh -l root LUN名 snap create ボリューム名 new　で新規のsnapshotを作成
  3. ALTER DATABASE END BACKUP;

これだけ。実行時間僅かに数秒程度。この後、snapshot をテープに時間をかけて２次バックアップすれば最強っす。oracle の標準機能の RMAN とか目じゃないッス。ちなみに oracle を oracle でバックアップするという RMAN の思想自体が僕はあまり好きではなかったりします。ｗ

NetApp ファイラーを使用した oracle 超高速リカバリー

逆にリストアする際もめちゃくちゃ高速です。なんせ snapshot に切り戻せば良いだけです。そこからロールフォワードして最新状態にもっていけばいいので、巨大なデータファイル群をテープから切り戻す時間が数秒になると思えばほぼ正しいです。

  1. shutdown abort 　でデータベースを停止
  2. umount ファイルシステム名　　で破損したファイルシステムをアンマウント
  3. rsh -l root LUN名 snap restore new ボリューム名　で最新snapshotに切り戻し
  4. mount ファイルシステム名　　でリカバリたファイルシステムをマウント
  5. startup mount 　でデータベースを起動
  6. recover automatic database;　でロールフォワードして最新状態へリカバリする
  7. alter database open; 　でデータベースを利用可能状態にして復旧完了。

もちろんアーカイブログの保存場所や破損した箇所によって若干の手順が異なるかもしれませんが、NetApp ファイラーを導入する場合は、oracle に関連するほぼ全てのファイルは NetApp ファイラー上に配置するので、上記手順でほぼ間違いなくリカバリできているはずです。oracle 以外のバックアップ＆リカバリの手順も基本ファイルのコピー部分が snapshot に置き換わるイメージで考えれば良いかと思います。

そのほか NetApp ファイラーにはいろいろ機能がありましてそれぞれそれなりに便利です。ハードの拡張性もかなり柔軟な設計だと思います。

僕自身オープンソースが凄く好きで費用をかけずに環境構築することに喜びを感じてしまいますが、LVM の snapshot でもよく似たことはできるかもしれないけどリブートしたら snapshot が消えたりとか不安点とかいろいろあります。適材適所って感じである程度の費用をちゃんと使ってこういったソリューションを選択するのは全然ありかと思う派でもあります。


より詳しい情報はこちらをどうぞ。このブログ経由で受注とかあったら何か良いことないかなぁ〜なんて書いてみるテスト。

ふぅ〜それにしてもこの手の記事を書くのは時間がかかるし疲れるなぁ・・・おしまい。

- スポンサーリンク -

関連する記事＆スポンサーリンク