
第6回 LVMによる自動バックアップ・システムの構築
今回は、バックアップ計画立案に際して検討すべき点から、カーネル2.4の機能であるLVMを利用したバックアップ・システムの構築方法を解説する。これを参考に、確実にリストアできるバックアップ体制を整えてほしい。(編集局)
アイティーブースト(http://www.itboost.co.jp/)
2003/2/8
バックアップ計画の立案
前回は、バックアップを実施するために必要なバックアップデバイスやツールの基本的な操作について説明しました。では、バックアップを行うための計画を立案する際に、どのような点を考慮すればいいのでしょうか? バックアップに際して考慮すべき項目は多数存在し、当然ながらシステム環境や要件によって異なります。
■バックアップ計画の検討事項
●リストアが最終目的
バックアップ計画を検討する場合、リストアするときのことを第一に考えるべきです。バックアップの最終的な目的はデータを複製することではなく、何らかの障害が発生した際に「迅速に正しいデータをリストアすること」にあります。これを念頭に置きつつ、「どのデータを」「いつ」「どこに」「どのような方法で」バックアップするのか、そしてそのバックアップは「どれくらいの期間保存するのか」を考える必要があります。
●どのデータをバックアップするのか
システムにはさまざまなデータが存在します。バックアップをより効率的に行うには、バックアップ対象のデータが変更される頻度や重要度によって分類し、バックアップの方法を詳細に検討する必要があります。
例えば、システムを動作させるために必要なプログラムや設定ファイルなどのシステムデータの場合、最悪バックアップデータが存在しない場合でも、構築時、ソフトウェアのアップグレード時、あるいは設定変更時などの際のドキュメントをしっかり残していれば、同じシステムを構築することは可能です。また、更新もそれほど頻繁でないため、バックアップを取る頻度も少なくて済みます。
しかし、ファイルサーバやデータベースシステムなどでユーザーが作成したデータは、常に更新され続けるため、頻繁にバックアップする必要があります。
ログやアクセス統計記録なども更新され続けますが、システムを動作させることだけを考えるなら、必須ではありません。もちろん、システム要件によっては優先的にバックアップされるべきデータになることもあります。
これらのデータが失われた場合の被害の大きさ、システムリソース、バックアップ時間、障害発生からリストアが完了するまでに許される時間などのバランスを詳細に検討する必要があります。
●いつバックアップをするべきか
バックアップを行う時間帯は、多くの場合システムへのアクセスが少ない夜中になります。これは、バックアップの最中にデータの更新が起こる可能性を低くするとともに、提供しているサービスのパフォーマンスに悪影響を及ぼさないようにするためです。
すべてのサービスを停止してバックアップするのであれば、前回に説明したdumpコマンドなどで簡単に実施できます。ただし、バックアップデータが大きくなってくると、サービスの停止中にバックアップが完了しないという事態も起こり得ます。バックアップ時間が不足するようになったときのこともバックアップ計画に含める必要があります。
また、24時間365日の運用を求められるようなシステムも最近では多くなっています。この場合は、システムへの影響が少ない時間を見計らってバックアップを取らなければなりません。
●どこにバックアップするのか
バックアップデータの保管場所も検討事項の1つです。システムのデータが非常に大切なもので、このデータがなくなるとすべての業務がストップしてしまう場合もあるでしょう。クリティカルなデータは、できるだけ大切に扱う必要があります。例えば、災害などによってシステムが物理的な損傷を受けたとしても、別サイトにバックアップデータを保存していれば、すぐにサービスを再開できます。その場合、バックアップテープを別サイトに保管する、あるいはネットワーク経由でリモートサイトとデータ同期を行うなどの方法があります。
●バックアップツールの選択
前回、さまざまなバックアップツールを紹介しました。これらは小規模なシステム構成であれば十分に機能しますが、システムが大規模/複雑になると、処理手順や計画も非常に複雑になります。機材や管理ツールのコストを抑えたとしても、管理のための人的コストが膨れ上がり、トータルで見ると不必要に大きなコストが掛かる可能性があります。また、複雑になればなるほど人的なミスが起きる可能性も多くなります。ある程度の規模を超えた要件になった場合は、商用バックアップツールの使用も検討する必要があるでしょう。
●バックアップのタイプと頻度
どれくらいの頻度でデータが更新されるのかによって、あるいは障害発生時にどの時点のデータまで復旧できればよいのかによって、バックアップの方法や頻度は異なります。
リストアが最も簡単なのは、毎日すべてのデータをバックアップするフルバックアップです。この方法なら、1つのアーカイブ(複数のテープにまたがる場合もある)をディスクに書き出せばリストアを完了できます。ただし、変化することのないデータも毎回バックアップすることになるため効率的ではありません。大量のバックアップメディアが必要になるほか、毎日のバックアップ時間が非常に長くなります。
多くのケースで適切だと思われるのは、週に1度フルバックアップを取り、残りの日は増分バックアップにすることでしょう。例えば、dumpを利用するなら日曜日にダンプレベル0でバックアップし、ほかの曜日はダンプレベル1にします。cronに登録して自動実行させる場合、ダンプレベル0用とダンプレベル1用のスクリプトを用意し、以下のように設定すれば実現できます。
# crontab -e |
00 00 * * 0 ダンプレベル0を実行するスクリプト |
さらに複雑で、リソースの使用効率の良いスケジュールの仕方もあります。ただし、複雑にし過ぎると、リストアの際に混乱して操作ミスしてしまう可能性が増えてしまいます。管理性の良いバックアップツールを使用する場合を除き、あまりお勧めできません。
●世代管理
例えば、ユーザーの操作ミスによってデータを削除してしまったり、ウイルスによってデータが破壊されたり、何らかの障害でバックアップが正常に取れていないことに気付くのが遅れたという場合は、何日かさかのぼったバックアップデータが必要になります。そのため、最悪の状況を想定し、バックアップしたデータをいつまで残しておくのかも考慮すべきです。
●バックアップの自動化とルーチンワークの策定
バックアップ計画を決定したら、次はバックアップが確実に実行されるように、できるだけ処理を自動化できるようにしましょう。
例えば、複数の処理をまとめたスクリプトを作ることによって、バックアップ手順の操作ミスを防ぐことが可能になります。cronを利用して、そのスクリプトを定期的に実行すれば、作業漏れが防げます。また、管理コストも軽減できます。
バックアップのような、ミスや抜けの許されない作業を行う場合は、手順書などのドキュメント整備なども必要です。手順書は、バックアップを取る場合よりも、リストアの手順に重点を置きましょう。迅速にリストアが完了できるように、システムの運用前に何度も検証してリストアの手順を確立すべきです。
また、バックアップメディアの管理方法もあらかじめ定めておき、作業が決まった流れでできるようにしておきましょう。
- ダンプレベル0のデータは必ず1つのテープに保存する
- バックアップテープには必要事項を記載したラベルを貼り、xxに保存する
といったことを決定します。
必要に応じて管理方法は柔軟に変更していく必要もありますが、変更が多過ぎると作業漏れが発生する可能性も高くなります。
また、システム構築の案件がある場合、ここで挙げたようなバックアップの観点から、システムをもう一度確認することをお勧めします。システムが現在どのような状態なのか、どのようなデータがどこに保存されるのか。これらを正確に把握したうえでディスク構成などを決定しないと、後で困ったことになる場合があるからです。
|
1/3
|
|
||||||
|
||||||
| 連載 Linux管理者への道 |
| Linux Squareフォーラム Linux/システム学習関連記事 |
| 連載:Windowsユーザーに教えるLinuxの常識(全12回) Windowsのセオリーが通用しないLinux。Linux初心者向けに、LinuxというOSの考え方/常識をゼロから伝授! |
|
| 連載:LFSで作って学ぶLinuxの仕組み(全4回) 管理者(root)は、何をしなければならないのか? 管理に際して検討すべきことは? 管理のための技術とは? など、駆け出し管理者のための考え方や方法論を検討する |
|
| 連載:Linux管理者への道(全8回) 「Linux From Scratch」というシンプルなLinuxをインストール&環境構築する作業を通して、LinuxがOSとして機能するための仕組みや設定を見直そう |
|
| Linux Squareフォーラム全記事インデックス |
|
ホワイトペーパー(TechTargetジャパン)
- natテーブルを利用したLinuxルータの作成・2 (2010/3/11)
IPパケットのディスティネーションアドレスを書き換える「DNAT」を使って、透過型プロキシを構築します - 一歩進んだ監視のカスタマイズ (2010/3/3)
スクリプトの実行結果などを取得できるユーザーパラメータを用いて、自分のニーズにぴったり合った監視を実現 - OSSライセンス順守の第一歩 (2010/2/18)
企業として、OSSライセンス違反を犯さないためには、どのような手順が必要か、いくつかアドバイスします - 無視できないフラグメンテーション問題への解答は? (2010/2/10)
今回は、メモリコンパクション、そしてメモリバリアを発行するシステムコールという2つのパッチについて深く紹介します
|
|
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
- - PR -
| 「いつかは壊れるサーバ」そんな故障に 迅速で安価に手軽に対応する方法とは? New! |
| 「特権ユーザー」の事件を防げ! 万能権限を持つユーザーの管理方法とは? New! |
| 仮想環境の構築とデータ保護の特効薬?! 実績と信頼性の高いパッケージで安心運用 |
| 仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
| おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |
| 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |
| 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |
- - PR -
お勧め求人情報

**先週の人気講座ランキング**
〜CCNA編〜
| ◆ | TomcatやJBossなどAPサーバ環境に関する 情報を集約! “業務”用APサーバ大百科 New! |
| ◆ | 一気に解説! 最新のクラスタストレージ 「RAIDを超えたストレージ基準」……など New! |
| ◆ | クラウド的ユーザー体験の変化は脅威か? 仮想化技術を使いこなす運用管理術を紹介 New! |

| ◆ | 上司や部下、部署内メンバーとの情報共有 を“ガラッ”と変えるコラボツールとは? New! |
| ◆ | おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| ◆ | 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |

| ◆ | Twitterのアカウントはなぜ突破された? メールによる新手の攻撃手法とその対策 |
| ◆ | もう仮想化のお試しフェイズは終わりだ! Hyper-V 2.0が基幹システムも仮想化 |
| ◆ | 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |

| ◆ | クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 |
| ◆ | .NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は? |
| ◆ | 業務効率と情報セキュリティ対策を両立! 手間なく確実に機密情報を守る方法とは? |

| ◆ | 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |

| ◆ | 【CTC事例】約30の基幹システムを統合! 膨大なバッジジョブを制御した方法は? |
| ◆ | 仮想化すればコストは削減できるか? 仮想化に必要な「3つの視点」を解説する |
| ◆ | その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |






