| ブログ Global Site

オープンソース型バックアップソフト

Amanda

ホワイトペーパー

「ソフト開発の新会社の創設者として、知的財産をしっかりと守り、事業拡大に伴い効率的なコスト管理をすることの必要性を強く感じています。Amandaのネットワークバックアップとリカバリソフトは、貴重なデータが保護されているという安心感を与えてくれる点で重要な役割を果たしてきました。容易に導入でき、しかも信頼性が高い。今回、ZmandaのAmandaエンタープライズ版により企業へのサポートとサービスが提供されることになったと知り、大変嬉しく思っています。」

バークレー･デザイン･オートメーション創始者、技術部門担当統括責任者　　　　

アミット・ナラヤン　

「Zmandaが企業向けにAmandaの機能、安定性、サポート提供を開始することは大変喜ばしいことです。Zmandaは、オープンソース型のAmanda開発において主導的役割を果たしてきただけでなく、Amanda開発とユーザコミュニティに対する対応を積極的に行ってきました。Zmandaのエンタープライズレベルでのサポートサービスにより企業はデータ保護のためにAmada技術を一層利用しやすくなるはずです。」
、

Amandaの初代開発者、ジェームス・ダシルバ　　　　

概要

本書ではAmandaのしくみや他のバックップソフトウェアとの違い、またデータ保護ソリューションとしての活用法など、Amandaの簡単な技術的概要を説明します。

最も利用されているオープンソース型バックアップソフト Amandaについて
重要な特色の概要　　
プロプライエタリでないツールの使用を重視したクライアント／サーバアーキテクチャ
Amandaのセキュリティ
ホールディングディスク
バックアップスケジューリング
テープ管理
デバイス管理
Amandaの設定
NFSやSamba（SMB/CIFS）経由でのクライアントのバックアップ
Amandaのリカバリ
今後の計画

このホワイトペーパーに関するご意見ご感想をfeedback@zmanda.comまでお寄せください。

最も利用されているオープンソース型バックアップソフトAmandaについて

本ホワイトペーパー1の目的は、Amandaの技術的概要を説明することです。Amandaのしくみや他のバックップソフトとの違い、またデータ保護ソリューションとしての活用法などについて知ってもらいたいからです。しかし、特定の設定やバックアップ方針についての詳細を述べることで読者の皆さんを圧倒することも避けたいと思っています。この文書では、www.zmanda.com内へのリンクが張られていますので、最新で分かりやすい操作法やAmandaの本番適用において知っておきたいことがすべて分かるようになっています。

Amanda（Advanced Maryland Automated Network Disk Archiver）は最も知られているオープンソース型バックアップソフトで、大量のクライアントワークステーションにあるファイルを単一のバックアップサーバで保護することを目的として1991年にジェームス・ダシルバが中心となってメリーランド州立大学で開発されました。

Amandaプロジェクトは1999年11月11日にSourceForge.netに登録され、最近ではモントリオール大学のジーンルイス・マルティノーがアマンダ開発の管理・主導を行っています。今日までに250人以上の開発者がAmandaコードに貢献し、何千ものユーザがテストやフィードバックを行い、その結果Amandaの安定性と堅牢性が向上しました。2006年4月時点でAmandaは世界中の2万サイト以上で展開されていると推測されています。

当初Amandaは主に大学や技術研究所などで使用されていましたが、今日ではITにおけるLinuxの普及に伴い、様々な場、特にLAMPスタック用のアプリケーションに注力している場で使われるようになりました。

これまでにAmandaは、Linuxジャーナルの読者から「フェイバリットバックアップシステム」賞をはじめとする多数の賞をユーザから受けています。

1 本ホワイトペーパーは、Dmitri Joukovski、John R. Jackson、Alexandre Oliva、Aleen Frisch、Paul Bijnens、Stefan G. Weichingerを始めとする人々による Amandaについての公開された情報に基づきZmanda, Inc により執筆されました。

図１　一般的なAmandaネットワーク

Amanda、すれば利用を単一のマスタバックアップサーバを設定し、Linux、UNIX、MacOS-X、Windowsなどのデータのホストの複数テープライブラリ、自動チェンジャー、光学ジュークボックス、RAIDアレイ、NASデバイスなどを始めとする様々なテープ、ディスク、光学装置にバックアップすることが可能です。

以下はAmandaの実際の使用例です。

ある翻訳会社では、3カ国で3つのAmandaサーバをCentOS上で使用し、Solaris 2.6、Solaris 8、Linux、Windows 2000などの30以上のクライアントを保護しています。9年間で様々なバージョンを使用し、保護されたデータの合計量は500GB以上になり、その量は週に平均8GBの割合で増えています。１ヵ所ではディスクへのバックアップのみを行い、他の２ヵ所ではディスクとLTOオートローダーへのバックアップを行っています。ユーザが間違えてファイルを消去してしまうことがあるため、システム管理者が最低でも週1回ファイルのリカバリを行っています。これまでに何度かハードディスク障害によりサーバがダウンしたことがありますが、Amandaのおかげで無事ベアメタルリカバリができました。

イギリス、ニューキャッスル大学では、合計で2TB以上のデータを持つLinux（Fedora Core、Red Hat Enterprise Linux）、MacOS-X、Solarisなど100以上のクライアントに対し2つのAmandaサーバを使用しています。そのうち1つはSolaris上のSAPとOracleのバックアップ専用に使用しています。

「バットマンビギンズ」や「ハリー・ポッターと炎のゴブレット」などを手がけたある映画編集会社では、84のLinuxとIRIXクライアントの26TBのデータを保護するため、２ヵ所でDebian系Amandaサーバを使用しています。ユーザエラーなどにより週に2回ほどリカバリを行っています。Amanda使用開始から3年間でRAISアレイを使用しているにもかかわらず、全データを損失したことが3度にわたり発生しましたが、Amandaはいずれもすべて回復することができました。

本書では、この他にも実際のAmanda使用例を紹介していきます。様々なシステム構成や様々なレベルのAmandaに関する専門知識を持つユーザからのフィードバックから、Amandaが広く普及した要因として以下が考えられます。

Amandaを利用すると、複数のネットワーククライアントをテープ、ディスク、光学ストレージシステムなどに単一のサーバで容易にバックアップが可能なため、システム管理者の仕事が楽になる。
Amandaはディスクやテープへのバックアップに最適化されており、テープやディスクへのバックアップの独自の同時書き出し機能により、オンラインで手早くディスクからリストアしたり、障害回復や長期保存のためにオフサイトで同じデータを入手することが可能。
Amandaはプロプライエタリなドライバを必要としないため、OSでサポートされているデバイスならすべて使用可能。システム管理者はAmandaをアップグレードする際にデバイスのサポートが中断される心配がない。
Amandaは標準ユーティリティ、dumpまたはGNUtarを使用。また標準的なOSを使用。プロプライエタリなフォーマットがないため、緊急時にAmandaがなくても標準的なツールを使用してデータ回復が可能。
Amanda独自のスケジューラにより、異なるクライアントのバックアップレベルを最適化し、バックアップにかかる時間が毎回同じになるようにできるため、システム管理者は各環境におけるデータ変換のスピードを予測しなくてすむ。
Amandaプロジェクトは巨大でアクティブなコミュニティの注目を集め、そのサイズは日ごとに増大している。

www.zmanda.comでは、ほとんどのLinuxのバージョンに対応したソースコードのTAR書庫やRPMとして、Amandaソフトウェアを提供しています。また、SourceForge.net（http://sourceforge.net/projects/amanda Global Site

）でもソースコードを入手することができます。すべてのLinuxディストリビューション（Fedora Core、Red Hat Enterprise Server、Debian、Ubantu、OpenSUSE、SUSE Linux Enterprise Server等）には旧バージョンですが安定したAmandaが装備され、また、x86アーキテクチャだけでなく、x64、Itanium、IBM p-Series、さらにIBM S/390、z-Seriesなどのメーンフレームにも対応しています。

Google検索のヒット数による調査では、Amandaは、Linuxシステム管理者の約16％、UNIXシステム管理者の約8％に知られており、Amandaの専門知識やAmandaユーザの一覧が容易に入手できることで、IT管理者がAmandaを自分の環境に導入・設定する際の情報源として非常に役立っています。

Zmanda, Inc.が提供するAmandaはエンタープライズサポートのある唯一のオープンソース型バックアップソフトです。サポートは「Zmanda Network」と呼ばれるサブスクリプションを通じて提供しています（これはRed HatやMySQLなどと同様のサブスクリプションサービスです）。また、Zmandaでは知的財産に関する免責を「Amanda Enterprise Edition」のサブスクリプション購入者に提供しています。さらに、導入・設定に関する専門サービスもZmandaおよびその他機関を通じて提供しています。Zmanda Networkについての詳細は、http://zmanda.com/network_overview.html Global Site

をご覧ください。

ユーザによるユーザのためのAmanda関連文書は、Amanda Wiki:http://wiki.zmanda.com Global Site

で提供しています。このWikiでは、複数ユーザによるリモート編集も容易にでき、また変更履歴、検索機能などが主な特長となっています。

AmandaコミュニティはAmandaフォーラム：http://forums.zmanda.com Global Site

などの様々なコラボレーションツールを利用しています。Amandaユーザには、利用しやすいメーリングリスト：
amandausers@amanda.orgがあり、過去ログはhttp://groups.yahoo.com/group/amanda-users Global Site

で閲覧することができます。

Amandaの紹介の締めくくりとして、Amandaに窮地を救われ、効を奏した数多くの事例のひとつをご紹介します。これは長年のAmandaユーザであるジョン・ラバディの話です。

私は1999年に米国政府関連の小さなサービス組織である社内電話会社のコンサルティングを始めました。そこでは約40のウインドウズ系 PCと3つのSunサーバを使用し、SunではOracleを起動していました。バックアップには2種類の市販製品を使っていましたが、どちらにも満足していませんでした。既に4機目のSunサーバを購入済みでUNIXのバックアップなど、タスクの入れ替えも行っていました。

私は、追加コピーを購入しサポートされていない契約を更新する前に、何か別のバックアップソフトについて意見を求められました。多少リサーチを行い、Amandaを発見しました。まず自分の家のシステムにインストールしてみて１週間試してからボスに提案しました。しかし、当時どこでもそうであったように、無料ソフトは受け入れられませんでした。どこがサポートしてくれるのか、何か問題が起きたらどうするのか、バックアップという大事な機能に無料ソフトを使っていることが知れたらどうするのか、無料ソフトだから限界があるのではないか…。ありがとう、でも遠慮しておくよ。ここは無難に、大手ベンダのソフトであるという理由だけで、満足していないソフトに何千ドルという大金を払うことにするよ、といった具合でした。

というわけで、苦労してバックアップを別のサーバに移行しました。一方で私はボスに内緒で一番古いSunサーバとスペアのDATドライブを使い、並行してAmandaでシステムバックアップを始めました。それから約１ヵ月後に大変なことが起こったのです。数週間前からのディレクトリツリーが必要となり、私自身はリカバリに係わっていませんでしたが、これは両システムのリカバリ時間を比べるいいチャンスだと思いました。約20分後にAmandaのリカバリを使って必要と思われるものを取り出し、会社のシステム上の/var/tmpのディレクトリにコピーしました。

社内のもう一方の陣営からは午前中ずっと文句やイライラの叫びが聞こえていました。午後になって、/var/tmpディレクトリを見せて、「必要なのはこれかい？」と言って、彼らを苦悩から解放してあげました。

後で分かったことですが、市販のバックアップソフトではバックアップテープがバックアップサーバに適合されているという問題があったのです。ですからリストアは同じサーバからではなくてはできませんでした。必要だったデータは以前のバックアップサーバで作られていて、そのサーバにはソフトもライセンスもインストールされていませんでした。つまりバックアップテープは使い物にならなかったのです。

そこで、ボスはAmandaを主要バックアップシステムとして使ってみることにしました。その後PCもAmandaでバックアップするようになりました。その部門に１年前に連絡を取ったときには、まだAmandaを使用していました。

重要な特色の概要

はじめにAmandaアーキテクチャの概要について説明します。これはAmandaの機能性についての最も重要な概念を理解するのに役立つものです。

プロプライエタリでないツールの使用を重視したクライアント／サーバアーキテクチャ

Amandaは大量のクライアントとデータに対応するようにできていますが、インストールもメンテナンスも簡単にできます。　規模の拡大も縮小も容易にでき、小規模の構成、つまり単一のクライアントでも可能です。Amandaサーバである単一のクライアントのみのバックアップを行っているユーザもたくさんいます。
一方で何百、何千というファイルシステム（保護するシステムにつき複数のファイルシステムの場合もある）を複数のドライブで大規模なテープライブラリにバックアップしているユーザもたくさんいます。AmandaのコードはC言語（Perl、Shellスクリプトも含む）で書かれており、　　　　Max OS-Xを含むLinuxやUNIX向けに移植可能です。現在WindowsクライアントはWindows向けのLinuxのような環境であるSambaやCygwinのクライアント経由でバックアップが可能です。AmandaコミュニティはWindows向けのネイティブクライアントを提供するために積極的に動いています。新しいWindowsクライアントは　オープンファイルのスナップショットなど、システムのボリュームのスナップショットを提供するボリュームシャドウコピーサービス（VSS）などのMicrosoft技術を利用する予定です。
他のバックアップソフトに比べて、Amandaの最大のメリットはAmandaがプロプライエタリなフォーマットを一切使用しないということです。クライアント上のファイルシステムからテープ、ディスク、あるいは光学ディスクへのデータ移動に、Amandaではdumpやtarなどの標準OS、あるいはGNUtar、smbtar、starなどのほとんどのOSで使用可能なオープンソースユーティリティを使用します。これらのユーティリティを自由に組み合わせて自分のファイルシステム、ディレクトリ、ファイルに最適なものを使用できます。使用するユーティリティは標準的なものですから、いつでも使用できるという安心感もあります。また、標準ユーティリティ　を使うことのもう一つのメリットとして、障害回復やその他の緊急時にAmandaがインストールされていなくてもデータのリカバリが可能であるということがあげられます。Amandaを使用しないでデータのリカバリを行う方法についてはAmandaリストアの項で説明します。Amandaは標準ユーティリティを使用するため、以下が可能となります。

スパースファイルのバックアップ
　
ハードリンクのバックアップ
バックアップ時にファイルのタイムスタンプの変更がない
　　
ファイルやディレクトリの排除

システム管理者の視点からAmandaがプロプライエタリなデバイスドライバを使用しないことは大変重要なことで、OSがサポートするデバイスであればどんなデバイスでもAmandaに対応できます。実際、Amandaは幅広いテープストレージ　　デバイスをサポートするため、新しいデバイスでも問題なく追することができるということを意味します。特別なテープ　　チェンジャスクリプトを使用することでほとんどのテープチェンジャや、スタッカー、ジュークボックス、テープライブラリが　　サポートされるので、完全自動のバックアップが可能となります。つまり、テープドライブへの読み書きができ、mtなどの標準的なOSコマンドでテープライブラリのテープを移動できれば、そのテープライブラリでAmandaを使用することが可能です。Amandaはプロプライエタリなデバイスドライバを使用しないため、Amandaを最新バージョンへアップグレードしてもデバイスのサポートが中断される心配をしなくてもよいというメリットもあります。

Amandaのアーキテクチャと仕組みを理解するため、簡略化されたAmandaの構成を見ながらバックアップサイクルの例を見てみましょう。

図2　2つのバックアップクライアントを持つAmandaサーバ

簡単に説明するために、２台のワークステーション上にAmandaクライアントが2機のみあるという設定とします。このワークステーションは Solaris搭載の「Copper」とLinux搭載の「Iron」とします。各ワークステーションには保護したいユーザデータのある2つのファイルシステムがあります。Amandaサーバ「Quartz」は別のLinuxホストにインストールされており、ここでは簡略化するためにAmandaサーバ「Quartz」自体のバックアップは行っていないことにします。本番環境や評価環境においてはAmandaサーバ自体のバックアップを常に行うことをお勧めします。ここでは、4日に一度はフルバックアップを行い、その間に増分バックアップも行うこととします。

Amandaは従来型のクライアント、つまりサーバアーキテクチャとして設計されています。また、Amandaサーバはこれまでもテープホストとして知られており、テープドライブやテープチェンジャに直接、またはストレージエリアネットワークを通じて接続されています。各クライアントのバックアッププログラムは標準出力に書き込むように指示されており、それをAmandaが集めてテープサーバに送信します。クライアント／サーバのアーキテクチャには以下のメリットがあります。

単一クライアントとCD-ROMだけの環境から何百というクライアントと複数のテープドライブと大量のテープからなる大容量のテープライブラリという環境まで、Amandaの拡張性を保証。
すべての設定がAmandaサーバで可能。Amandaの初期設定ができてしまえば、検証済みのバックアップ手順を中断させる心配なく容易にクライアントの追加が可能。
圧縮や暗号化などのCPUに負担のかかる作業をAmandaサーバにバックアップイメージを送る前にクライアント上で実行可能。

プライバシー保護やコンプライアンスという点からバックアップデータのセキュリティの重要性が今後も増すと考えられることから、次にAmandaのセキュリティについての概要を説明します。

Amandaのセキュリティ

AmandaクライアントはTCPやUDP上の独自ネットワークプロトコルを介してAmandaサーバと通信します。Amandaのクライアントとサーバ間の通信はdumpが使用する従来の/etc/rmt方式（例えばルートのホームディレクトリにあるrhostsファイルを使用するなど）に特有のセキュリティホールの心配がありません。　　　　

他のクライアント／サーバ設定と同様、自分の信頼できるAmandaサーバのみがAmandaクライアントと通信できるように注意してください。Amandaはamandahostsファイルを使用してこれを行います。図2にはAmandaサーバ「Quartz」に1つ、各Amandaクライアントに1つずつ、計3つのamandahostsファイルがありますが、クライアント側にAmandaサーバ（同一のホストを複数のAmandaサーバで保護する場合は複数のAmandaサーバ）とクライアントバックアップが許可されているAmandaユーザの名前を追加する必要があります。例えば、図2のLinuxクライアント「Iron」のamandahostsファイルの場合、以下のようなエントリとなります。

quartz.zmanda.com amandabackup

これにより、Amandaサーバ「Quartz」が「amandabackup」と通信するようにAmandaクライアント「Iron」に指示します。

リストア中はAmandaサーバへのアクセスが必要となります。図2の設定では、テープサーバ「Quartz」上のamandahostsファイルは以下のエントリとなります。　

iron.zmanda.com root　　　　

copper.zmanda.com root　　　　　　　　

このエントリは各クライアント上の「ルート」ユーザがリストアを行うようにAmandaサーバに指示します。セキュリティのためAmandaはルートユーザのみがデータのリストアを行えるように設計されています。より強力なデータ転送セキュリティのためのamandahostsによる認証とバックアップクライアントの認証のほかにもAmandaではOpenSSHも使用可能です。これにより、Amandaは強力な認証・オーソリゼーションのメカニズムでクライアントとバックアップサーバ間のデータ転送を保護することができます。現行のAmandaバージョン2.5では、抽象化された安全な通信のAPIにより、開発者がバックアップサーバとクライアント間に別の通信プラグインを簡単に追加できるようになっています。　　　　

バックアップメディア上のデータを保護するためにAmanda2.5では対称的または非対称的な暗号化アルゴリズム（aespipeまたはgpgのいずれか）によりバックアップデータを暗号化することができます。CPU使用率という意味では暗号化は非常に高くつきますから、使用可能なCPUサイクルにより、Amandaの暗号化はサーバまたはクライアントで行うことができます。AmandaサーバのCPUの領域を開放するだけでなく、クライアントサイトの暗号化により、リモートクライアントのバックアップにも重要な、ネットワーク上のデータのセキュリティも確保されます。CPU制限によりデータの一部のみを暗号化したい場合も、Amandaは単一ディレクトリや単一のファイルでもデータの暗号化設定が柔軟にできます。aespipeやgpgが暗号化の要件に合わなくても、Amandaはカスタム暗号化ユーティリティもサポートします。　　　

AmandaはSecurity-Enhanced Linux（SELinux）でも使用可能で、また、初期設定のときにUDPとTCPのポートレンジを選べば、Amandaのサーバとクライアント間の一般的なファイアウォールにも無理なく対応できます。ファイアウォールのセットアップについてのインストール・設定の詳細はhttp://wiki.zmanda.com Global Site を参照してください。

Amandaのセキュリティについての簡単な説明の最後に、そのセキュリティ設定の柔軟性によりAmandaは徹底したセキュリティ要件のある組織においても、ほとんどのIT環境におけるセキュリティ方針やプロセスに対応できるということを強調したいと思います。

ところで、Amandaは実際、略語であり、AmandaのDは「Disk」の頭文字だということを思い出してください。Amandaがどのようにしてクライアントから最終的なデータの転送先であるテープやディスクへデータを転送するのかを説明するために、まずAmandaの重要な概念である「ホールディングディスク」について説明します。

ホールディングディスク

図2ではAmandaサーバ「Quartz」に「ホールディングディスク」がついているのが分かります。ホールディングディスクとはAmandaサーバからアクセスできるファイルシステムにある一つまたは複数のディレクトリのことを言います。それには、Amandaサーバドライブ上の単一の10GBのディレクトリからファイバアタッチトRAIDアレイ上の5～10TBまでと、幅広いサイズがあります。その名の通り、ホールディングディスクはすべてのAmandaクライアントからのバックアップデータを保存するキャッシュとして使用されます。クライアントのファイルシステムまたはクライアントのディレクトリからのバックアップデータは、それぞれがホールディングディスク上のファイルの束に過ぎません。その後、テープドライブのストリーミングを維持するため、独立したプロセスがホールディングディスクからテープへと個々のバックアップイメージを最大スループットでフラッシュします。ホールディングディスクをバックアップのステージングエリアとして利用することにはいくつかのメリットがあります。

最新型のテープドライブは非常にスピードが速く、例えばLTO-3の転送速度は80MB／秒です。ギガビットネットワークでも単一のクライアントからAmandaサーバを介してLTO-3ドライブにバックアップデータを転送するのに、テープを一旦停止させて待機するという、いわゆる「シューシャイニング」（これによりスループットが減少しメディアやドライブの消耗が早まる）を避けることができるほどの転送速度にはなりません。ホールディングディスクはすべてのクライアントからデータを集め、はじめのバックアップが完了次第、Amandaサーバが可能な限りの速い速度でデータをテープへと転送し始めます。しかし、ほとんどのユーザはデータをテープにフラッシュし始める前にすべてのクライアントバックアップを完了させたいと思っています。
ホールディングディスクは、同時に複数のクライアントからデータストリームを受け入れることができ、テープの逐次的な性質を克服することができます。バックアップを次から次へとテープへ書き込むのではなく、複数のバックアップを同時に行うように設定でき、使用可能なネットワークの容量を最大限に利用でき、さらにバックアップにかかる時間も短縮できます。ネットワークが性能のネックとなる場合は、バックアップサーバにもう一つのNICを追加するか、あるいはバックアップ専用のネットワークを設定するなどしてバックアップにかかる時間を全体的に減らすことができます。
最後に、ホールディングディスクを使用することで、テープが不良あるいは不適切なものだった場合や使用できるテープがない場合などでも安心できます。休暇前に新しいテープを入れ忘れたとしてもバックアップはちゃんと完了しているはずです。

Amandaは複数のホールディングディスクをサポートするので異なるクライアントからのバックアップイメージを別のホールディングディスクに転送することが可能です。これによりAmandaの拡張性も広がり、また、ホールディングディスクは異なるコントローラに接続できるため入出力のロードバランスもよくなります。

新たにAmandaを使い始めたユーザからよく聞かれることは、ホールディングディスクはどの程度のサイズであるべきか、ということですが、一般的なフルバックアップと増分バックアップのサイクルではほとんどのバックアップがごくわずかな増分ですので、ホールディングディスクに適量のスペースがあれば、ディスクがないときに比べスムーズにバックアップイメージをテープへ転送することができます。目安としては、最大のバックアップイメージが二つ同時に入るだけの十分な空きがホールディングディスクにあれば、一つのイメージがテープに書き込まれている間にもう一つのイメージがホールディングディスクに転送されますので問題ないでしょう。例えば図2で「Copper」のフルバックアップが50GBで「Iron」のフルバックアップが30GBだとしたら、「Quartz」のホールディングディスクの最適な容量は最低でも80GBとなります。それができない場合は、小さい増分バックアップが少なくとも2～3入るぐらいの容量があれば、ホールディングディスクがないよりは良いでしょう。今はディスクの値段も安くなっていますから、かなりの容量のホールディングディスクでも投資の価値はあるでしょう。

一方で、非常に大容量のホールディングディスクを使っているAmandaユーザもいます。例えば、日本の大手メーカーではSolarisとBSD上で4機のAmandaサーバを使用して、BSD、Windows、Linux、HP-UX、Oracleを稼動しているSolarisなどで100以上のAmandaクライアントを保護しています。ホールディングディスクの一つは合計容量が4TBのRAIDアレイ上にあります。高速のアレイと高入出力のAmandaサーバにより、ホールディングディスクからテープへのストリーミングスループットは約120MB／秒となっています。　　　　　

Amandaの柔軟性により、ホールディングディスクを使用しない設定でバックアップを直接テープに転送することも可能ですが、その場合、バックアップはホールディングディスクへの同時書き込みではなく、テープへの逐次的な書き込みとなります。ホールディングディスクを使用しないと、明らかにバックアップの性能が大幅に落ちてしまうことが分かります。

ホールディングディスクがバックアップファイルを一時的に保存するために使われるのなら、Amandaはホールディングディスクへ何を転送するかをどのように決定するのでしょうか。では次にAmanda独自のバックアップのスケジューリング法について見てみましょう。

バックアップスケジューリング

一般的にほとんどのバックアップ製品のバックアップスケジューリング機能は同じですが、システム管理者はフルバックアップのスケジュールを日曜日、あるいは隔週の日曜日、月末などと設定し、その間に様々な増分バックアップスケジュールを設定します。この方法の最大の問題は、ロードバランスが調整できないということです。フルバックアップ中のバックアップサーバCPUやネットワーク、I/Oのピーク需要を管理するために十分な資源があることを確認する必要があります。フルバックアップは時々しか行わないので、ほとんどいつも資源がフルに使われていない状態にあります。システム管理者が月曜日の朝に行ったら、ライブラリ内のテープが足りなくて日曜日のフルバックアップが完了していなかったというのは、認めたくはないもののよくある話です。あるいはフルバックアップがまだ終わっていなくて、ユーザからすべてのバックアップをストップするように言われてしまうなどということもあるでしょう。もちろん、バックアップソフトに1週間の間にフルバックアップをクライアントに振り分けるように指示し、ロードバランスを維持することも可能ですが、新しいクライアントがそのバランス図式を崩してしまうなど、環境変化が一切起こらないようにしなくてはなりません。

Amandaではバックアップのロードバランスを最適化する独自のスケジューリング機能により、楽にスケジュール管理ができます。「クライアントA、B、Cで隔週日曜日に、クライアントD、E、Fで毎週水曜日にフルバックアップを行い、そのほかのときは増分バックアップを行う」といった特定の指示をAmandaに出すのではなく、Amandaのスケジューリングを管理する2、3の基本ルールを設定するだけです。例えば、「7日間に最低1度はフルバックアップを行い、その7日間のフルバックアップの間を最長期間としてその間に増分バックアップを行う」というルールをAmandaに与えるとします。このフルバックアップと次のフルバックアップまでの間の最長期間を「ダンプサイクル」と言います。

ダンプサイクルを指定すれば、バックアップごとのバックアップデータの合計が最小で、それがバックアップごとに一貫して実行されるようになるような、すべてのクライアントからのフルバックアップと増分バックアップの最適な組み合わせをAmandaが見つけてくれます。このバランスを見つけるためにAmandaは以下の点を考慮します。

各クライアントから報告される前回バックアップ時からのデータ変更分に基づく合計データ量
指定されたバックアップ間の最長期間（ダンプサイクル）
バックアップ時ごとに使用可能なバックアップメディア（テープまたはディスク）のサイズ

最適なバックアップレベルを計算するに当たり、Amandaは「推定フェーズ」と呼ばれるバックアップを開始します。それぞれのAmandaクライアントはどのファイルに変更があったか、変更されたファイルの合計サイズなどを判断する特別な処理を行います。この推定フェーズは特にクライアント数やファイル数が多い場合は時間がかかります。あまり動的でない、あるいはあまり変更がないファイルシステムがある場合は、それをAmandaに指示することができます。それにより推定フェーズにかかる時間を短縮できます。すべてのクライアントからデータを集めたら、次は「計画フェーズ」に入ります。ここではAmandaがすべてのクライアントのフルバックアップと増分バックアップを行う最適な組み合わせを計算します。

図2でホームディレクトリがそれぞれ100GBで、データ変更率が15％、ダンプサイクルが4日であると想定して、Amandaがどのようにクライアントのバックアップスケジューリングを行うかを見てみましょう。ここでは簡略するため、AmandaはDailySet1からDailySet4までの新しいテープへのバックアップを行い、すべての増分バックアップはレベル1（通常はレベル0がフルバックアップと定義されている）、つまり前回のフルバックアップ時からすべてに変更があったと想定します。

図3Amandaのスケジューリング図式

１回のバックアップごとにAmandaは合計データ量の「ダンプサイクル」分の１のフルバックアップを行うようにスケジューリングします。ここではダンプサイクルは4日ですから、DailySet1についてはデータの4分の1のフルバックアップ（ここでは例として/home1とする）を行います。DailySet2についてもまた4分の1のフルバックアップ（/home2）と15GB（100GBの15％）の/home1の増分バックアップを行います。DailySet3では/home3のフルバックアップと/home1と/home2の増分バックアップを行います。1回目の4日間のサイクルが終わったら、/homeディレクトリのうちの一つのフルバックップとその他のディレクトリの増分バックアップを行います。では、それぞれのDailySetテープの合計データ量を計算してみましょう。

表１　Amandaのスケジューリング図式.DailySetテープごとの合計データ量

DailySet1とDailySet2の合計データ量は計算するまでもありません。/home1の3回目のバックアップは、100GBの15％に相当するDailySet2にバックアップされたデータの15％に再び変更があったことを考慮する必要があります。

図4各テープの合計データ量の説明図

二重計算を避けるため、30GBから重複部分を差し引く必要があります。DailySet3では、/home1の増分サイズは30GB－（15GB×15%）＝27.75GBとなります。同様のロジックで、DailySet4について計算すると、/home1の増分は 45GBではなく、45GB－（27.75GB×15%）＝40.84GBとなります。

この例はAmandaのスケジューリングを説明するための例えに過ぎません。実際には9レベルすべての増分バックアップレベルを使用してテープ上の合計データ量を最小限にします。

フルバックアップとその間の増分バックアップという従来の図式のほかに、Amandaは以下にも対応しています。
.

フルバックアップのオフサイトへの保存など、定期的なアーカイブバックアップ
　
非常にアクティブな領域でオフラインに格納する必要がある場合や、ベンダのメディア（OSのインストールCDなど）で容易に復旧できる領域でバックアップが必要ない場合など、Amanda以外でフルバックアップが行われる場合に、増分のみバックアップ
　
バックアップごとに完全に変更が行われるデータベース、または単一の復旧作業であれば緊急時に容易に対応できるその他の重要領域のフルバックアップを常時実行

従来のフルバックアップとその間の増分バックアップを週に1度やりながら、オフサイトのストレージへのフルバックアップも行うなど、同一Amandaサーバで複数の設定をすることも簡単にできます。複数のテープドライバがあれば、複数の設定を同時に同一のテープサーバで行うことも可能です。

ダンプサイクルの期間を決定する際、3、4日の短いダンプサイクルの方が、増分が少ないだけリストアが容易にできますが、使用するテープの量も時間も余計にかかるということを考慮してください。ダンプサイクルが長いとAmandaはロードを複数のテープに分配しやすくなりますが、リストア中に行う処理数が多くなることがあります。データ量やテープドライブの容量に応じた合理的なダンプサイクルのバランスについての詳細はhttp://wiki.zmanda.com Global Site

を参照してください。

では、次にAmandaのテープ管理について説明します。

テープ管理

Amandaのコマンドamlabelを使用する前に、「DailySet1」などとそれぞれのテープに名前をつけます。名前にはデフォルトのテンプレートがありますが、独自のテンプレートを定義することもできます。名前をつけることで有効なバックアップイメージを保存してあるテープへの上書きを避けることができ、また、Amandaサーバが名前のついたテープを全て管理することが可能となります。

現時点では、Amandaは、毎晩のバックアップなど、個々のバックアップ時に新しいテープを開始させ、前回のテープに新規のバックアップを付け加える機能はありません。

バックアップ保存方針によりAmandaはそれぞれの名前のついたテープの有効期限や期限切れの古いバックアップイメージを把握し、そのテープを新規バックアップに再利用します。しかし、Amandaが特定のテープを再利用しないようにも設定できます。バックアップイメージの中には有効期限を設定しないものもあるでしょうが、それはAmandaを使ってアーカイブを作成することができます。最近では、Amandaは光学メディアにも対応するようになったので、アーカイブに役立っています。

また、大量のデータのバックアップには、クライアントA、B、Cからのバックアップを一つのテープに、クライアントE、F、Gからのバックアップを別のテープにといった具合に、一回のバックアップで複数のテープを使用することが可能です。

かつては単一のバックアップイメージを複数のテープにわたって保存することができず、システム管理者は大きなファイルをいくつかのディレクトリに分けるなど、細分化しなければなりませんでしたが、バージョン2.5では、複数のテープにバックアップすることが可能になりました。これにより、大きな制限がなくなり、Amandaは拡張性と使いやすさの面で大きく進歩しました。バックアップされたイメージのサイズが一つのテープに制限されなくなり、システム管理者も一つのテープに収まるようにデータを無理に細分化しなくてもよくなったのです。

デバイス管理

Amandaがテープや光学装置のプロプライエタリなドライバを必要としないということは既に述べましたが、AmandaはOSが使用しているテープドライブからの読み書きができれば、そのデバイスで使用できます。お使いのテープ装置が/dev/nst0、/dev/nst1など、巻き戻しなしの設定になっていなければなりません。また、お使いのテープ装置技術に固有の「テープ定義」を選択する必要があります。Amandaでは多くのテープ定義をデフォルトで提供しています。以下はDLT8000のテープ定義の例です。

define tapetype DLT8000 {
comment “Quantum DLT8000 created by tapetype”
length 38130 mbytes
filemark 29 kbytes
speed 5627 kps
}

同様に、テープチェンジャについてもテープチェンジャスクリプトを選択する必要があります。一般的なテープドライブのテープ定義例とテープドライブの設定、テープチェンジャスクリプトについての詳細はhttp://wiki.zmanda.com Global Site

を参照してください。

これまでもAmandaではバックアップ先のメディアとしてディスクの使用が可能でした。専用ディレクトリはvtapeと呼ばれる「仮想テープ」として使われています。vtapeは「本物の」テープを使うように使用でき、Amandaで使用する前にvtapeと名づける必要があります。vtapeを使用する理由として以下が考えられます。

ディスクへのバックアップは、高価なテープライブラリを購入するかどうか決める前にAmandaをテスト・評価する良い手段となる。
　
ディスクへのバックアップは、コストの面から本番環境における実行可能なオプションとなっている。細かい注意が必要なテープドライブを管理する手間がなく、データのバックアップが取得できる。

最も面白い使い方は、テープとディスクを同時に使うことです。AmandaにはRAITというユニークな機能があり、これは「Redundant Array of Inexpensive Tapes」を略したものです。もともとは冗長性を高めるために作られたものですが、これはデータをいくつかのディスクにストライプするRAID技術と同じものです。Amandaは2、3、または5台のドライブでRAITに対応しています。

ドライブが3台のときRAITは2つのデータストリームと1つのパリティストリームを書き込み、容量もスループットも2倍となり、故障率は2乗になります（テープが2つとも障害があるか、または使用できない場合にのみデータを失う可能性があるので、例えば故障率が百分の1の場合、1万分の1になる）。同様にドライブが5台のときは容量もスループットも4倍になります。

ドライブが2台のときは出力ストリームを複製し、それぞれの出力ストリームは同じメディアまたは別々のメディアをバックアップ先とすることができます。同じメディア、例えば2台のテープドライブの場合、クローンと呼ばれる全く同一のバックアップデータの複製ができます。1つはオンサイトで偶発的なリストアを行うために使い、もう1つのクローンはオフサイトで障害復旧用として使用できます。

異なるメディアをバックアップ先として使用する場合、バックアップデータを2～3週間ディスクに保存しておき偶発的なリストアを行うために使い、長期保存用としてはテープにコピーを保存しておくこと
もできます。ほとんどの場合、リストアはファイルがなくなってから10日以内に行われ、ディスクからデータをいかに速く復旧できるかが重要なポイントとなります。

同一のデータをディスクとテープに同時に書き込める機能はAmandaのもう一つのユニークな特長です。本書の執筆時点では他にその機能を持つバックアップ製品は知られていません。

Amandaについての重要な概念についてすべて説明しましたので、次はAmandaのバックアップサイクルの設定方法について説明します。

Amandaの設定

Amandaサーバとクライアントのインストールと設定方法についての詳細はhttp://wiki.zmanda.com Global Site

を参照してください。ここでは設定についてのロードマップを示します。

Amandaのインストールは、www.zmanda.comにあるRPMから行うことを推奨します。Amandaをソースからコンパイルするには：

「disk」グループに「amandabackup」ユーザを作ります。
ソースアーカイブから解凍、コンパイル、インストールを行い、クライアントのみのインストールのオプションを指定します。
Amanda関連のエントリを/etc/servicesと/etc/xinetd.dディレクトリに追加し、xinetdをリスタートします。

いずれにしても、Amandaのインストール後にクライアントにどのサーバが接続可能かを指示する必要があります。
クライアントとサーバ間の認証を行うため、 .amandahostsファイルを編集します。

Amandaサーバをインストールするには、ここでもRPMを利用します。ソースからコンパイルする場合：

「disk」グループに「amandabackup」ユーザを作ります。
ソースアーカイブから解凍、コンパイル、インストールを行い、クライアントとサーバのインストールのオプションを指定します。
Amanda関連のエントリを/etc/servicesと/etc/xinetd.dディレクトリに追加し、xinetdをリスタートします。

インストールしたらいくつかの手順を踏んでAmandaサーバを設定します。
.
Amanda設定用ディレクトリ/etc/amanda/(config name)を作ります。（Zmandaパッケージを使う場合）
amanda.confのサンプルを/etc/amanda/(config name)にコピーします。
/etc/amanda/(config name)内にdisklistファイルを作ります。
クライアントとサーバ間の認証を行うため、amandahostsファイルを編集します。
設定ファイルamanda.confとdisklistを編集します。
デバイスを設定します（デバイスのノードまたはディレクトリを作ります）。
amlabelを使ってメディア（テープまたはvtape）に名前をつけます。
Amandaのバックアップのスケジューリングを行うため、cronジョブを設定します。
amcheckプログラムを実行し、設定、クライアントとサーバ間の通信、ホールディングディスク、テープに問題がないか確認します。

注：クライアントとサーバの両方を１台でできるので、上記の手順を２回実行する必要はありません。通常は、サーバをインストールするとクライアントもインストールされます。

図5Amanda設定ファイル

Amandaのセットアップに最も重要な設定ファイルはamanda.confです。サンプルファイルは700行にも及ぶ大きなファイルですが（そのため、ここでは割愛。詳細はhttp://wiki.zmanda.com Global Site

を参照）、簡単に理解できるコメントと例がありますので、説明は不要です。次のパラメータを設定することにより、そのファイルがバックアップを行う方法を決定します">http://wiki.zmanda.comを参照）、簡単に理解できるコメントと例がありますので、説明は不要です。次のパラメータを設定することにより、そのファイルがバックアップを行う方法を決定します。

組織名、バックアップ完了報告や警告を送る Eメールアドレス、Amandaディレクトリの場所などのローカル設定
テープ装置、テープタイプの定義、テープチェンジャスクリプト、テープの名前のテンプレート、Amandaが使用するネットワークの帯域幅などのデバイスとネットワークの設定
ダンプサイクル、増分バックアップの詳細、ダンプサイクルに行うバックアップの回数、ローテーションするテープの数などのバックアップ方針の設定
ホールディングディスクの場所とAmandaが使用できる容量
dumpとgnutarのどちらを使用するか、インデックスデータ、暗号化、圧縮の詳細など、バックアップの実行方法についての指示

何をバックアップするかという指示はdisklistファイルにあります。例えば、図5のクライアント「Iron」と「Copper」の/homeディレクトリをバックアップするには、以下のディスクリストエントリ（DLE）が必要になります。

# hostname diskname dumptype
Copper /home1 stable
Copper /home2 stable
Iron /home3 normal
Iron /home4 normal

ディスクリストエントリのダンプタイプは、amanda.confファイルに定義される「dumptype」のことを言います。Dumptypeは、バックアップを圧縮するか、バックアップの結果を/etc/dumpdatesに記録するか、ディスクの相対的なプライオリティ、除外リストなど、バックアップに関連するパラメータを特定します。Disklistファイルで「Copper」と「Iron」のエントリに使用する「通常」の「安定」したダンプサイクルの定義の例を以下に示します。

define dumptype normal {
comment “gnutar backup”
holdingdisk yes # (on by default)
index yes
program “GNUTAR”
priority medium
　　　　　　　　　　}

define dumptype stable {
comment “ufsdump backup”
holdingdisk yes # (on by default)
index yes
program “DUMP”
priority medium
　　　　　　　　　　}

amanda.confのパラメータの多くは編集不要のデフォルト値がありますが、すべてのパラメータは編集することも可能なので自分のバックアップ環境を自由に管理できます。

これまで、保護するシステム上で設定したAmandaクライアントの最も一般的なシチュエーションをご紹介しましたが、このほかにもAmandaサーバ上でNFSやSamba経由でファイルシステムを搭載たり、同一システム（Amandaサーバ）上のAmandaクライアントでこれらのネットワークされたファイルシステムをバックアップしたりなど、様々な状況が考えられます。

NFSやSamba（SMB/CIFS）経由でのクライアントのバックアップ

保護するシステム上でAmandaクライアントを使う従来のやり方と比べて、NFSやSamba経由でバックアップを行うことにはいくつかのメリットがあります。

保護するシステム上でAmandaクライアントソフトをインストール・設定する必要がなく、ほとんどのシステムは一つのシステム上でファイルを変更するだけで保護するシステムとして追加することができます。
OSによってはネイティブのAmandaクライアントの使用ができない場合がありますが、NFS/SMBではそういったOSのバックアップが可能になります。
保護するシステムのCPUやメモリの使用率が大幅に節約されます。
保護するシステム上の重要なデータがNFSやCIFSプロトコルで使用可能であれば、会社のIT方針と統合しやすくなります。

しかし、この方法にはデメリットもあります。

搭載するメカニズム、つまりSMBやNFSのセキュリティ問題を考慮する必要があります。データがクライアントからサーバへと転送される際、その暗号化にAmandaのメカニズムは使用できません。また、それ以前にNFSやSambaを保護するシステム上で起動することによるセキュリティへの影響も理解する必要があります。例えば、バックアップしたいシステム上でNFSサーバを常に起動したくない場合、Amandaサーバへのバックアップが始まる直前にシステム上のNFSサーバが起動するという、同期方式を採用する必要があります。
アクセス権について注意が必要です。AmandaサーバはNFS搭載点での読み書きの両方の権限が必要となります。バックアップ中は読み込み許可が、リストア中は書き込み許可が必要となります。
バックアップ処理を最適化するためにローカルファイルシステムを使用することができません。例えばdumpまたはxfsdumpをネットワークでアクセスしたファイルシステム上で使うことはできません。
Samba経由でアクセスしているオープンファイルのバックアップはできません。また、Samba経由で拡張ファイル属性をバックアップすることもできません。

図6NFSによるバックアップの設定における注意点

バックアップ対象となるシステム上でSFSサーバ、Amandaサーバ上でNFSクライアントのインストールと設定が必要となります。

この時点でバックアップするファイルシステムを転送します（対象システムの/etc/exportsファイルにリストする）。Amandaサーバがバックアップする必要があるすべてのファイルにアクセスできることを確認してください。この場合、バックアップされているNFS共有のno_root_squash」オプションをオンにすることでAmandaサーバがすべてのファイルにアクセスできるようになります。対応するディスクリストエントリの「hostname」が、NFS共有がマウントされているシステム（バックアップ対象ではないシステム、図6の場合「Quartz」）となります。

図7SambaによるWindows系システムのバックアップ中の設定における注意点

AmandaサーバにSambaクライアントをインストールする必要があります。リモートファイルシステムを必ずマウントしなければならないというわけではありません。Amandaはsmbclientユーティリティ（サーバ上のSMB/CIFSリソースにアクセスするためのftpのようなクライアント）とうまく統合されます。smbclientユーティリティの「-T」オプションを使ってSMB/CIFSシェア上のすべてのファイルのtarに対応したバックアップを作ります。Amandaはバックアップするファイル（Windows系の対象システム）のアーカイブビットを消去し、それにより増分バックアップ処理ができるようになります。

Windowsシステム上で共有（図7ではユーザ「amandabackup」）へのアクセス権（読み／書き）をフルに与えられたユーザを作る必要があります。Amandaはこのユーザを介して共有に接続します。ユーザにフルアクセス権がないと、増分バックアップができず、また共有のすべてが毎回バックアップされてしまいます（アーカイブビットがリセットされないため）。Windowsシステム上の他のプログラムがファイルのアーカイブビットに行ってリセットすると、Amandaはそのファイルをバックアップしないことがあります。

標準のAmanda設定以外にsmbclientユーティリティを起動しているシステム上に/etc/amandapassというファイルを作る必要があります。このファイルには特定のWindows共有にアクセスするための認証情報が含まれています。また、対応するディスクリストエントリの「hostname」はsmbclientを起動しているシステム上にあり、バックアップしているWindowsシステム（図7ではAmandaサーバ「Quartz」）にはないということに注意してください。

Sambaを介したバックアップの説明の最後にもう一度言っておきたいことは、Amandaのインスールにより本番運用環境でWindowsサーバやPCを保護しているケースがたくさんあるというということです。例えば、大規模なアメリカ中西部の大学にある放射線学部では1999年からAmandaを導入しており、これまでにIRIX、AIX、SolarisなどでAmandaサーバを稼動していましたが、現在はインデックスを別のサーバに複製してLinux上で運用しています。70台以上のLinux、Solaris、IRIX、Mac OS-X、Windowsなどのクライアントのバックアップを行い、その合計データ量は約4TBほどにもなります。ホールディングディスクは1.4TBでダンプサイクルは90日です。すべてのWindowsクライアントはSamba経由で保護しています。ユーザエラーやハードドライブの故障により、月に数回ファイルのリカバリを行っており、いつもAmandaがなくしたファイルを復旧してくれるのでデータを取得したことは一度もありません。

では次にAmandaのリカバリについての概要を簡単に説明しましょう。

Amandaのリカバリ

Amandaのバックアップをリストアするプログラムはamrecover とamrestoreの二つです。amrecoverはバックアップファイルのインデックスを特定の日付までさかのぼってブラウズし、リストアが必要なファイルを選ぶことができるインターフェースを使って、ファイルをリストアします。もちろんamrecoverを使うためにはamanda.configでdumptypeを指定する時にバックアップファイルのインデックスができるようにしなければなりません。ファイルを選んだらAmandaが必要なテープを見つけ、バックアップイメージを探し、必要であれば解凍し、ネットワークでクライアントに送信し、要求されたファイルを抽出するために必要な引数で適切なリストアプログラムを実行させます。増分バックアップからファイルをリストアする必要がある場合、Amandaは必要なテープの正しい順番について指示します。セキュリティのためamrecoverはクライアントのルートとして実行する必要があり、Amandaサーバ上の.amandahostsにあるリモートユーザとしてルートをリストします。

ファイルシステムのフルリカバリはamrestoreにより行います。これはテープからすべてのファイルシステムイメージを取り出すものです。

amrecoverはAmandaサーバを含むどのクライアントでも可能です。amrestoreはAmandaサーバでのみ可能です。バックアップインデックスがないときはamrestoreを使う必要があります。

OSも含めてすべてのバックアップを行うことがバックアップ方針で指定されている場合、Amandaでベアメタルリカバリができます。

ディスクを交換します。
Knoppixなどの LiveCDを使ってブートします。
ディスクのフォーマット、セグメント化を行います。
Amandaサーバの amrestoreを使って OSも含めてすべてを新しいディスクにリストアします。（増分のリストアも必要な場合があります）。
新しいディスクにブートローダを作成します。

Amandaのテープフォーマットは緊急時に備えて意図的に簡略されたものになっており、Amandaのツールがなくてもリストアができるようになっています。最初のテープファイルはテープボリュームのシリアル番号と書き込みが行われた日付がついたボリューム名となっています。そのフォーマットはANSIではなく、ブレーンテキストです。その後各ファイルには32KBブロックを使って一つのイメージが格納されます。はじめのブロックはAmandaヘッダで、イメージを作成したクライアント、領域、オプションが記載されています。他のボリューム名と同様、ヘッダのフォーマットはANSIではなく、プレーンテキストです。イメージは次のテープブロックから始まって、ファイルの最後まで続きます。

amrestoreが使用できないときに標準のUNIXユーティリティからイメージを取り出すには、テープをイメージのポジションに合わせて、ddを使用して読み込みます。

# mt rewind
# mt fsf NN
# dd if=$TAPE bs=32k skip=1 of=dump_image

「skip=1」オプションはAmandaファイルのヘッダを飛ばすようにddに指示します。「of=」オプションがないと、ddはイメージを標準出力に書き込み、必要であれば解凍プログラムに送られてからクライアントのリストアプログラムへと送られます。

イメージヘッダがテキストなので、以下のようして見ることができます。

# mt rewind
# mt fsf NN
# dd if=$TAPE bs=32k count=1

イメージの説明のほかに、リストアに必要なコマンドを示したテキストも含まれています。
iron.zmanda.com上の/home2ファイルシステムの標準的なエントリを以下に示します。Solarisのufsdumpを使用、圧縮なしでダンプレベルが１となっています。

AMANDA: FILE 20060418 copper.zmanda.com /home2 lev 1
comp N program /usr/sbin/ufsdump

リストアを行うためにはテープをファイルのはじめのポジションにして以下を実行します。

# dd if=$TAPE bs=32k skip=1 | /usr/sbin/ufsrestore -f... -

他のバックアップシステムと同様、リストアの手順を何度もテストして、実際に障害が起こったときに何をすべきか把握しておとよいでしょう。

今後の計画

今日のITにおける最大の課題のひとつはシステムの全体的なセキュリティです。セキュリティはバックアップの基本的な部分ですから（特に暗号化されていないテープをなくしたときなど）、Amandaチームではあらゆる面においてAmandaのセキュリティの一層の強化を図っていきます。

ディスクがバックアップの主要メディアになってきており、バックアップ業界に抜本的な転換が起こっています。Amandaは当初からディスクへのバックアップを行うように設計されていましたが、Amandaチームでは、同時に複数のバックアップやディスクからのリストアなど、これからも、ディスクへのバックアップにさまざまな改善を加えていきます。

Amandaユーザの多くは増え続ける膨大なデータ量と常に闘っています。Amandaがそのための役割を果たすべく、Zmandaではその拡張性とパフォーマンスの向上に取り組んでいます。

オープンソース、とりわけLinuxの普及により、Oracle、MySQL、SAPを始めとする様々なアプリケーションでAmandaが本番環境で使用されています。要求の厳しい環境でAmandaをうまく活用しているユーザがたくさんいる中、Amandaチームはそういったアプリケーションのバックアップを簡略化するアプリケーションAPIに取り組んでいます。

Amandaは常にシステム管理者の仕事を容易にするために改良されてきました。Zmandaでも、システム管理者にバックアップ方法についての自由を保障しつつ、インストール、管理、リカバリの簡略化を目指していきます。

この短い文書からも分かるように、Amandaはひとりひとりの現実に即した要件に対応すべく開発が続いています。Amandaの開発チームとAmandaコミュニティは、この強力で広く知られたソフトウェアスイートのさらなる整備と強化に取り組んでいきます。

概要

目次