JP2000293420A

JP2000293420A - データバックアップシステム

Info

Publication number: JP2000293420A
Application number: JP11102167A
Authority: JP
Inventors: Kenichi Kihara; 健一木原; Toshiaki Hirata; 平田　　俊明; Taro Saito; 太朗齋藤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1999-04-09
Filing date: 1999-04-09
Publication date: 2000-10-20
Anticipated expiration: 2019-04-09
Also published as: US6625625B1; JP4075203B2

Abstract

(57)【要約】【課題】クライアントのバックアップファイルをサーバ
に保存する環境において、クライアントの台数が多数の
場合にサーバ上のディスクスペースが大量に必要にな
る。【解決手段】クライアントのバックアップファイルをク
ライアント間で比較し、同一部分と固有部分とに分けて
格納し、サーバのディスクスペースを節約する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はネットワークシステ
ムにおける複数のクライアント機のバックアップ（デー
タの保存）・リストア（データの復旧）方法に関する。

【０００２】

【従来の技術】ネットワーク／システム管理の分野では
ＴＣＯ（総保有コスト）の低減が課題になっており、ク
ライアント機の管理コストがＴＣＯ低減の足かせになっ
ている。特にディスククラッシュからの復旧には、ＯＳ
やアプリケーションソフトの再インストールや環境設定
等、膨大な手間がかかり、管理コスト上昇の元凶となっ
ている。

【０００３】従来からディスククラッシュからの復旧に
対応するためには、バックアップが有効であることは知
られているが、ネットワークシステムにおけるバックア
ップについても例えば特開平2-297643号公報に記載され
ているような技術がある。この技術は複数のクライアン
ト（ワークステーション）機のバックアップを目的とし
たもので、バックアップ用のサーバを設置し、クライア
ント上のバックアップファイルをバックアップ用サーバ
に蓄積する。

【０００４】

【発明が解決しようとする課題】前記技術によると、サ
ーバ上でのデータバックアップ領域のサイズは、全クラ
イアント機（ワークステーション）のバックアップデー
タの総和となり、クライアント台数が多いとサーバ上の
データバックアップ領域も巨大なものが必要となる。バ
ックアップに要するディスク容量を考え、サーバのみバ
ックアップを行いクライアントのバックアップをあきら
めてしまうと、結果的にディスククラッシュから復旧で
きないという問題が生じることになる。

【０００５】本発明の目的は、複数のクライアント機が
使用される環境において、クライアント機の記憶装置の
バックアップデータサイズを縮小することであり、さら
にバックアップへの障害をなくすことでバックアップを
促しディスククラッシュからの復旧に対応できるように
することであり、さらにシステムの管理コストを低減す
ることである。

【０００６】

【課題を解決するための手段】上記目的を達成するため
に本発明では、各クライアントが持つデータ(ファイル
群)内の共通部分を検出し、クライアントのデータ間に
共通な部分と各クライアントのデータに固有な部分に分
けて保存(バックアップ)することで、バックアップデー
タの総容量を低減する。

【０００７】同じネットワークシステム内にあるクライ
アント機それぞれが持つファイルまたはファイル群は、
互いに同じような構成、内容になることが多い。その結
果、各クライアントのバックアップデータの内容も似通
った内容になりやすい。本発明はその特性を利用する。

【０００８】すなわち本発明は、記憶手段を持つ機器に
おける一つあるいは複数のデータで構成されるバックア
ップデータを蓄積する手段において、異なる前記機器用
の前記バックアップデータに含まれるデータの内容を比
較し、前記データ内容に同一のものが発見されれば、前
記内容が同一のデータを一つのデータに集約して蓄積す
る事を特徴とするものである。

【０００９】さらに本発明は、前記機器用の前記同一の
単数または複数のデータを蓄積する記憶手段と、前記同
一のデータ以外の前記機器用の単数または複数のデータ
を蓄積する記憶手段を持つことを特徴とするものであ
る。

【００１０】さらに本発明は、前記機器用の単数または
複数のデータを蓄積する手段すなわち共通データ蓄積手
段と、前記機器別に前記共通データ蓄積手段に含まれる
データの中のどのデータが前記機器用バックアップデー
タに含まれているかを示す情報を蓄積する記憶手段すな
わちデータ所有情報記憶手段とを、持つことを特徴とす
るものである。

【００１１】さらに本発明は、前記バックアップデータ
を蓄積する手段に蓄積された一つあるいは複数のデータ
を、前記機器別に取り出す機能を持つことを特徴とする
ものである。

【００１２】さらに本発明は、前記バックアップデータ
を蓄積する手段すなわちサーバと、データバックアップ
の対象である前記機器であり、前記サーバとの間で情報
をやりとりする機能を持つ手段すなわちクライアントを
持つことを特徴とするものである。

【００１３】さらに本発明は、前記クライアントと前記
サーバの間でデータ名やデータサイズ、データの更新日
時等のデータ属性情報を送信することを特徴とするもの
である。

【００１４】さらに本発明は、前記クライアントと前記
サーバ間でやりとりされた前記データ属性情報にもとづ
いて前記クライアントから前記サーバに転送する必要の
あるデータを決定することを特徴とするものである。

【００１５】さらに本発明は、前記クライアントと前記
サーバの間で巡回冗長符号やチェックサム等データ内容
から計算されるチェックコードをやり取りすることを特
徴とするものである。

【００１６】さらに本発明は、前記クライアントと前記
サーバ間でやりとりされた前記チェックコードにもとづ
いて前記クライアントから前記サーバに転送する必要の
あるデータを決定することを特徴とするものである。

【００１７】さらに本発明は、前記クライアントから前
記サーバに情報を伝達する手段とは異なる手段で前記サ
ーバから前記クライアントに情報を伝達することを特徴
とするものである。

【００１８】さらに本発明は、前記サーバから前記クラ
イアントへの情報伝達手段として、記憶媒体を用いるこ
とを特徴とするものである。

【００１９】さらに本発明は、前記サーバから前記クラ
イアントへの情報伝達手段として、通信衛星等の大容量
のデータ転送に向く通信手段を用いることを特徴とする
ものである。

【００２０】

【発明の実施の形態】１．第一の実施例：基本構成図１はその原理を示した図である。サーバ10、ネットワ
ーク20、クライアントA30、クライアントB31の四つの構
成要素からなる。図１では、クライアントは二台表記し
ているが、一台あるいは三台以上でも問題ない。クライ
アントA30、クライアントB31はサーバ10とネットワーク
20経由で接続されている。

【００２１】各クライアントはローカルにファイルを持
っており、バックアップの際にそれぞれそのファイルを
サーバ10に送信する。サーバ10は各クライアントから送
られたファイルを共通／固有振り分け処理101で、共通
部分と固有部分とに分け、共通部分を共通ストア103
に、クライアントA30の固有部分はクライアントA固有ス
トアA041、クライアントB31の固有部分はクライアントB
固有ストアA042に保存する。

【００２２】たとえば図１の実施例では、クライアント
A30はファイル装置301内にFile A、File B、File C、Fi
le Dという四つのファイルを持っていて、クライアント
B31はFile A、File C、File Eという三つのファイルを
持っている。両クライアントに共通するFile AとFile C
については、共通ストア103に格納される。また、クラ
イアントA30が持つファイル装置301内のFile B、File D
についてはクライアントA30固有なので、固有ストアA10
41に格納する。同様にクライアントB31のファイル装置3
11内のもFile Eも固有ストアB1042に格納する。File A
とFile Cについては、別々に格納するのではなく、一つ
にまとめることで保存領域を節約できる。

【００２３】バックアップされたファイルを元のクライ
アントに戻す場合には、共通ストア103内のファイルと
クライアント固有ストアの内容を合わせることで元のフ
ァイル（群）が得られる。そのファイル合成を行うのが
個別ファイル合成処理102である。たとえばクライアン
トA30のファイル装置301のリストアが必要になったら、
共通ストア103内のFile A、File CとクライアントA固有
ストアA041内のFile B、File DをクライアントA30用の
リストアデータとする。

【００２４】図２はネットワークシステム内で使われる
サーバ装置およびクライアント装置のハードウェア構成
の例である。内部はＣＰＵ41、メモリ42、キーボード4
3、ディスプレイ44、ハードディスクドライブ45、ネッ
トワークインタフェース46の部品で構成されている。ネ
ットワークインタフェース46は、他のマシンとネットワ
ーク20で接続されている。

【００２５】図３は内部処理方法を説明する図で、図１
のデータの流れを示したものである。クライアントA30
はファイル装置301、ファイル送信機能302、ファイル受
信機能303を持つ。ファイル装置301はクライアントA30
で使われるファイルを保持するもので、前記ハードディ
スクドライブ45に相当する。ファイル送信機能302はフ
ァイルのバックアップを行う際に、サーバ10にファイル
装置301内のファイルを送信する機能を持つもので、前
記メモリ42上に前記ＣＰＵ41が実行するプログラムとし
て実現される。その逆にファイル受信機能303はファイ
ルのリストアを行う際にサーバ10からファイルを受け取
り、ファイル装置301に格納する機能を持つもので、前
記メモリ42上に前記ＣＰＵ41が実行するプログラムとし
て実現される。

【００２６】サーバ10はクライアントA30から送られて
くるファイルを、共通／固有振り分け処理101（前記Ｃ
ＰＵ41が前記メモリ42上で実行するプログラムとして実
現される）内のファイル受信1011で受け取り、クライア
ント別にクライアントA用受信バッファ1012またはクラ
イアントB用受信バッファ1013に格納する（受信バッフ
ァはバックアップが必要となるクライアントの台数分を
前記ハードディスクドライブ45に用意すればよい）。各
受信バッファに格納されたファイルはAND1014で共通部
分を抽出され、前記ハードディスクドライブ45内の共通
ストア103に格納する。また、SUB1015によってクライア
ントA用受信バッファ1012から共通部分を差し引いたも
のを前記ハードディスクドライブ45内の固有ストアA104
1に格納する。同様にSUB1016によってクライアントB用
受信バッファ1012から共通部分を差し引いたものを前記
ハードディスクドライブ45内の固有ストアB1042に格納
する。

【００２７】またリストアの際には、個別ファイル合成
処理102（前記ＣＰＵ41が前記メモリ42上で実行するプ
ログラムとして実現される）において、リストアが必要
なクライアントに応じて共通ストアと固有ストアを合成
したものを、ファイル送信1021を用いてクライアントに
送信する。たとえばクライアントA30にリストアが必要
な場合には、ADD1022を使って共通ストア103と固有スト
アA1041の内容を合わせてクライアントA30に送信する。

【００２８】図４はクライアントとサーバ間のバックア
ップのプロトコルを示したものであり、上述の各処理プ
ログラムによって実行される。バックアップの際にはク
ライアントA30からサーバ10に対してファイルバックア
ップ情報50を送信する。ファイルバックアップ情報50の
中は、コマンドＩＤ（バックアップ操作を示す識別コー
ド）、クライアント特定用のＩＤの後に各ファイルのデ
ータを続ける。各ファイルのデータの内容はファイルパ
ス名、ファイル属性、ファイル本体などを含めればよ
い。

【００２９】図５はクライアントとサーバ間のリストア
のプロトコルを示したものであり、上述の各処理プログ
ラムによって実行される。リストアの際には、クライア
ントA30からリストア要求51をサーバに発行する。リス
トア要求51の内容にはコマンドＩＤ（リストア要求を示
す識別コード）とクライアントＩＤを含める。リストア
要求51を受けたサーバ10はリストア要求51内のクライア
ントＩＤを元に、前に示した方法でクライアント用ファ
イルを作成し、リストアファイル情報52として、クライ
アントに送信する。リストアファイル情報52は、コマン
ドＩＤ（リストアファイル情報であることを示す識別コ
ード）にファイル本体が続く。

【００３０】図６はサーバ側のメイン処理の流れを示し
たものであり、上述の各処理プログラムによって実行さ
れる。クライアントからのコマンドを受信し、受信した
コマンドが終了指示なら終了し、バックアップ情報50な
らバックアップ処理を、リストア要求51ならリストア処
理を実行する。

【００３１】図７はサーバ側のバックアップ処理の内容
を示したものであり、上述の各処理プログラムによって
実行される。クライアントから送られてきたファイルを
クライアント受信バッファにスプールする。前述の通
り、クライアントA用受信バッファ1012またはクライア
ントB用受信バッファ1013に格納する。次に、すべての
受信バッファの内容を確認し、全クライアントからのバ
ックアップファイルが集まったかどうかを判断する。全
部集まっていなければ終了する。集まっていれば全受信
バッファに共通するファイルを抽出し、共通ストア103
に格納する。また、各受信バッファ固有のファイルは固
有ストアA1041と固有ストアB1042に格納する。

【００３２】図８はサーバ側のリストア処理の流れを示
したものであり、上述の各処理プログラムによって実行
される。共通分のファイルとリストア要求を出したクラ
イアントの固有ストアのファイルとをリストア要求を出
したクライアントへ送信する。サーバ10内でのファイル
の共有状況は内部処理なので直接目に見えない。そこで
共有状況を画面に表示すれば共有の効果を目視で確認で
きるようになる。

【００３３】図９は共有の効果を確認するため図２のデ
ィスプレイ44上に、共通／固有振り分け処理101によっ
て表示される画面例で、固有格納分と共有格納分のファ
イルサイズを表示している。オリジナル総ファイルサイ
ズ901はクライアント側のファイルの合計（共有な
し）、固有格納分はクライアント固有ストア（図３では
1041,1042）の合計サイズ、共有格納分は共通ストア103
のサイズをそれぞれ表示している。また削減率904は固
有格納分902と共通格納分903を足したものをオリジナル
総ファイルサイズ901で割った値を表示しており、ファ
イル共有による効果の度合いを示している。図１０は図
２のディスプレイ44上に、共通／固有振り分け処理101
によって表示されるクライアント別共有比率の表示画面
例で、クライアント別906に何パーセントのファイルが
共有されているかを、ファイルの個数907とファイルの
サイズ908の観点で表示している。図１１は図２のディ
スプレイ44上に、共通／固有振り分け処理101によって
表示される共有状況の表示画面例で、共通ストア内のフ
ァイルおよび固有ストア内のファイルをそれぞれ表示す
ることで、どのファイルが共有されているかを目視で確
認できる。

【００３４】上述のように、第一実施例によれば、クラ
イアント機のバックアップデータをサーバに集め、バッ
クアップデータをクライアント間で比較し、同じファイ
ルがあれば一つに集約して保存することで、サーバ上の
ディスクスペースを節約できる。

【００３５】２．第二の実施例第二の実施例として、サーバ10上でのバックアップ用フ
ァイルの格納方法を変更した案を図12に示す。第一の実
施例（図３）の共通／固有振り分け処理101、個別ファ
イル合成処理102、クライアントA固有ストアA041、クラ
イアントB固有ストアA042に代わり、第二の実施例では
マルチクライアントファイル格納処理1051（前記ＣＰＵ
41が前記メモリ42上で実行するプログラムとして実現さ
れる）、オーナー対応表1052（前記メモリ42上に実現さ
れる）、マルチクライアントファイル取り出し処理1053
（前記ＣＰＵ41が前記メモリ42上で実行するプログラム
として実現される）を備えている。なお第二の実施例は
サーバ10のみの変更で、クライアントA30には変更は必
要ない。

【００３６】オーナー対応表1052は、共通ファイル103
内のファイルについてどのクライアントがそのファイル
を所有しているかを示すデータで図１３に例示するよう
に、共通ストア上のファイル毎に、ファイルＩＤ1052
1、オーナー10522、ファイルパス名10523が記されてお
り、オーナー対応表1052内の横一行が一レコードになっ
ている。

【００３７】ファイルＩＤ10521はオーナー対応表1052
と共通ストア103の結びつけを行うためのもので、その
レコードが共通ストア103上のどのファイルに対するも
のかを示すための情報となっている。図１３の例では、
ファイルＩＤ10521は1001や1002などの数値で示してい
るが、区別可能なら記号でもよい。オーナー10522はそ
のファイルがどのクライアントによって所有されている
かを示している。ファイルパス名10523はそのファイル
がクライアントのファイル装置301上でどこ（のファイ
ルパス）に配置されていたか（および配置させるか）を
示すものである。

【００３８】図１４はオーナー対応表1052の他の例であ
る。図１３では共通ストア103内の一ファイルに対して
オーナー対応表1052の一行（一レコード）が対応してい
たが、図１４では共通ストア103内の一ファイルがオー
ナー対応表1052の複数行に対応する。こうすることで、
ファイルパス名10523（あるいはタイムスタンプ10524も
しくは属性10525）は異なるがファイルの内容は同じ場
合に、図１３の例では複数のファイルが共通ストア103
に格納されることになるが、図１４の例では一つで済
む。図１４の例では、ファイルＩＤが1001のファイル
は、クライアントAのファイル装置103上ではC:\DIR1\FI
LE01の場所に置かれているが、クライアントBではD:\DI
R2\FILE01の場所に置かれていることを示している。

【００３９】マルチクライアントの格納処理1051の内容
を図１５に例示する。クライアントからファイルを受信
すると、オーナー対応表1052からその送信元のクライア
ントの情報を取り除く。たとえばクライアントBからフ
ァイルを受信したとき、図１４の例の場合、（図１４に
現れている範囲内で）二行目と三行目のレコードが削除
される。レコードを削除した結果、オーナーが存在しな
くなった共通ストア103内のファイルは、共通ストア103
から削除する。以下、クライアントから受信した各ファ
イルについて次の処理を行う。すなわち、すでに同じフ
ァイルが共通ストア103上に存在するかどうかを判断
し、共通ストア103内になければそのファイルを共通ス
トア103に格納し、共通ストア103内にある・ないに関わ
らずオーナー対応表1052の内容を更新する。

【００４０】第一の実施例と同様に、サーバ10内での共
有状況を表示する仕組みを持たせると利用者が共有状況
を確認できるので良い。図１６はその画面例である。統
計情報911として、オリジナル総ファイルサイズ（クラ
イアントのファイルのサイズの合計）、格納ファイルサ
イズ（共通ストア103内に格納されているファイルのサ
イズの合計）、節約できたバイト数（前者二つの差）を
示している。また共通ストア103内に格納されているフ
ァイルの一覧912として、共通ストア103内の各ファイル
についてそれぞれファイルサイズとオーナー数を表示し
ている。

【００４１】この第二の実施例によれば、あるファイル
が総てのクライアントに共通でなくても二台以上に共通
していれば共有可能になる。そのため、第二の実施例の
方がよりディスクスペースを節約できる可能性がある。

【００４２】第二の実施例において、クライアントから
送られてきたファイルと同じ内容のファイルが、すでに
共通ストア103内にあるかどうかを判定する方法につい
て説明する。クライアントから送られてきたファイルの
それぞれについて、共通ストア103内に格納されている
ファイル（群）の先頭から順に比較を行う手法を使った
場合、次の二つの要因で処理量が膨大になる。

【００４３】要因１．比較回数が膨大共通ストア103内の先頭から順に比較を行うので、クラ
イアント側のファイル一つあたり、最悪で共通ストア10
3内のファイル個数回の比較が必要になる。平均でもフ
ァイル個数の半分程度の比較回数が必要になる。クライ
アント側の全ファイルに対してその処理を行う場合、平
均で、「クライアント側の全ファイル」＊「共通ストア
内のファイル個数」／２回の比較が必要になる。たとえ
ば、クライアントから1,000個のファイルが送られて、
共通ストア103内に10,000個のファイルが存在する場
合、比較回数は、最悪10,000,000回程度の比較が必要に
なる。

【００４４】要因２．比較一回あたりの処理量が膨大ファイル内容同士を比較するため、比較一回あたりの処
理量も大きくなる。

【００４５】そこで、比較回数を低減する方式について
説明する。

【００４６】比較一回あたりの処理量が大きい点につい
ては、ファイル本体を比較する前にファイルパス名やフ
ァイルの長さ、チェックサム等を比較することで処理量
を低減できる。また、比較回数が多い点は、オーナー対
応表や共通ストア103内の情報をファイル名等でソート
しておくことで、二分探索法などの効率の良い検索（比
較）が行えるようになる。

【００４７】ファイルの長さをキーとしたファイル比較
の効率化手法の例を一つ挙げる。本効率化手法例ではフ
ァイル探索を効率化するために、ファイル早見表109を
用意する。ファイル早見表109の構造を図１７に示す。
ファイル早見表109は単数あるいは複数のファイル早見
情報1091で構成されており、各ファイル早見情報1091は
さらにファイルサイズ10911、チェックサム10912、ファ
イルＩＤ10913を含む。ファイル早見情報1091の並び
は、ファイルサイズを主キー、チェックサムを副キーと
してソートされている。すなわち基本的にファイルサイ
ズでソート済みで、ファイルサイズが同じファイル早見
情報1091同士はチェックサムでソートする。クライアン
トから送られてきた個々のファイルのファイルサイズと
チェックサムを比較対象の絞り込みに使用する。

【００４８】図１８はファイル早見表109を用いた探索
手法の例である。この図では、クライアントから送られ
てきたファイル108の内の一つに対して、共通ストア103
内に存在するかを探し出す手順を示している。第一ステ
ップは、クライアントから送られてきたファイル108の
ファイルサイズ（図１８の例では３２バイト）のファイ
ル情報をファイル早見表109内から見つけだす。前述の
通り、ファイル早見表109はファイルサイズでソートさ
れているため、二分探索法による探索が可能である。図
１８の例ではファイルサイズが３２バイトのファイルは
三つある。第二ステップは、クライアントから送られて
きたファイル108のチェックサムと同じ値のチェックサ
ムを持つファイル情報を第一ステップで見つけたファイ
ルの中から探し出す。前述の通り、ファイル早見表109
はチェックサムでもソートされているため、この探索処
理においても二分探索法が使える。図１８の例ではチェ
ックサムが一致するものは一つだけだった。第三のステ
ップでファイル本体の比較を行う。第二ステップで発見
したファイルの本体（図１８の例ではファイルＩＤ＝１
００１のもの）とクライアントから送られてきたファイ
ル108の本体を比較する。

【００４９】このような手順を踏むことで、ファイル本
体の比較は、ファイルサイズおよびチェックサムが一致
するものに限定できるため処理量を低減できる。なお図
１８の例ではファイルサイズにチェックサムを併用した
が、チェックサム算出に要する処理負担が気になる場合
には、ファイルサイズのみとしても良い。

【００５０】３．第三の実施例第三の実施例はサーバ10とクライアントA30間のプロト
コル（通信手順）に関するものであり、第一の実施例、
第二の実施例に付け加える形で実現できる。以下では、
第二の実施例の構成に基づいて説明する。

【００５１】第三の実施例は、バックアップの際に行わ
れるクライアントA30からサーバ10へのファイル転送時
のファイル転送量を削減することを目的としている。そ
の実現のためにサーバ10上にすでにあると考えられるフ
ァイルは転送しない仕組みを持たせる。クライアントA3
0側のファイルがサーバ10側にすでにあるかどうかは、
ファイルのパス名、サイズ、タイムスタンプなどのファ
イルに付属する情報、あるいはファイルの中身のチェッ
クサムやＣＲＣ（巡回冗長符号）などで判断する。なお
リストアについては第二の実施例と同じ仕組みが使え
る。

【００５２】図１９は第三の実施例を実装するシステム
構成例である。図１９の構成は、第二の実施例で出てき
た図１２の構成に転送量削減折衝処理Ｓ106（前記ＣＰ
Ｕ41が前記メモリ42上で実行するプログラムとして実現
される）と転送量削減折衝処理Ｃ304（前記ＣＰＵ41が
前記メモリ42上で実行するプログラムとして実現され
る）を加えた形になっている。第三の実施例では、図１
９の構成を前提として説明を進める。

【００５３】図２０は第三の実施例のサーバ10−クライ
アントA30間のバックアップ時のプロトコルを示したも
のである。クライアントA30−サーバ10間でやりとりさ
れる情報の形式は、コマンドＩＤ（通知の内容を示す識
別コード）＋オプション情報（通知内容によって異な
る）となっている。以下、その手順を追う。

【００５４】最初にクライアントA30からサーバ10に対
してファイルバックアップ要求801を発行する。それを
受けたサーバ10はクライアントA30に対してファイル情
報問い合わせ802を発行する。ファイル情報問い合わせ8
02の中には、要求する情報種別8021が含まれ、前記同一
性チェックのための項目（ファイルパス名、サイズ、タ
イムスタンプ、チェックサム、ＣＲＣ等）をクライアン
ト側に知らせる。たとえばファイルのパス名とサイズ、
タイムスタンプを同一性チェックの基準とするなら、フ
ァイル情報問い合わせ802の中でファイルのパス名、サ
イズ、タイムスタンプと指定する。なお、ファイル情報
問い合わせ802の中には、ファイルの範囲指定も可能
で、全部あるいは指定範囲のみの二通りの設定8022が可
能。指定範囲のみとした場合には、ファイルのパス名が
その後に続く。ファイル情報問い合わせ802を受けたク
ライアントA30は、自身のファイル装置301内のファイル
について、ファイル情報問い合わせ802内で指定された
項目についてファイル装置301の中を調べ、ファイル情
報送信803としてサーバ10に通知する。ファイル情報送
信803の中にはファイル情報8031が含まれており、さら
にファイル情報8031の中にはファイルパス名80311と要
求された情報80312が含まれている。要求された情報803
12は、ファイルパス名80311に関する、要求する情報種
別8021の情報（サイズやタイムスタンプ、チェックサ
ム、ＣＲＣ等）を入れる。ファイル情報送信803を受け
たサーバ10は、ファイル情報送信803の中に含まれるフ
ァイル情報を調べ、共通ストア103や、第二の実施例に
示す構成の場合のオーナー対応表1052に同じ内容のファ
イルが存在しないかを検索する。そして、ファイル情報
送信803に含まれるファイル情報のうち、共通ストア103
およびオーナー対応表1052（第二の実施例の場合）にな
いファイルのファイルパス名をファイル送信要求804と
して、クライアントA30に通知する。ファイル送信要求8
04を受けたクライアントA30は、要求されたファイル本
体をファイル送信805としてサーバ10に送信する。サー
バ10はファイル送信805を受けて、その内容を共通スト
ア103に格納するとともにオーナー対応表1052の内容を
更新する。最後にサーバ10はクライアントA30に対して
終了通知806を送信することでバックアップ処理を終了
した旨を通知して終了する。

【００５５】なお要求する情報種別が固定あるいはクラ
イアント側で確定している場合には、ファイルバックア
ップ要求801、ファイル情報問い合わせ802をスキップ
し、ファイル情報送信803から始めても良い。また図２
０の場合、ファイル送信805がバックアップ処理の最後
だと分かっているので、終了通知806も省略可能であ
る。

【００５６】前述の同一性チェック項目の内容はユーザ
によって変更可能な形を取っても良い。図２１はその設
定画面例である。大きな選択項目として、ファイル本体
の照合が必要913か不要914かがある。同一性チェックの
際、ファイルの内容についてもチェックする必要がある
場合には、ユーザは必要913を選択する。ファイル内容
のチェックが不要な場合には、ユーザが不要914を選択
する。ユーザが必要913を指定した場合には第二の実施
例と同等な動作となる。ユーザが不要914を選択した場
合、さらに同一性チェックの際にファイルのどの項目を
評価するかをユーザに選択させる。この画面で設定した
内容をサーバ10内で記憶しておき、前記プロトコル内の
ファイル情報問い合わせ802中で要求する情報種別8021
で指定するようにすれば良い。

【００５７】図２２は、図20に示すプロトコルを実現す
るクライアント側の処理フローチャートである。最初に
サーバ10に対してバックアップ要求801を発行し、サー
バ10からの応答を待つ。サーバ10からの応答が来たらそ
の内容を調べ、終了通知なら終了する。またサーバ10か
らの応答が、ファイル情報問い合わせ802なら自身のフ
ァイル装置301内を調べてファイル情報送信803をサーバ
10に通知し、再びサーバ10からの応答待ちに入る。サー
バ10からの応答がファイル送信要求804ならファイル送
信要求804内で指定されたファイルの本体を自身のファ
イル装置301から取り出し、ファイル送信805としてサー
バ10に送信した上で、再びサーバ10からの応答待ちに入
る。

【００５８】同じく図20の第三の実施例の前記プロトコ
ルを実現するサーバ10側の処理フローチャートを図２３
および図２４に示す。

【００５９】クライアントA30からのバックアップ要求8
01を受信したら、まずファイル本体の照合が必要かどう
かを判定する（7210）。これは第三の実施例の前記同一
性チェック設定（図２１）で設定された内容を受けて判
断する。必要911な場合には、クライアントに全ファイ
ルの送信要求を発行し（7213）、以下、第二の実施例と
同様に、ファイルをクライアントA30から受け取り、受
信したファイルのそれぞれについて、共通ストア103内
に同一内容のファイルが無いかどうかを確認しオーナー
対応表1052と共通ストア103の内容を更新し（7214）、
復帰（処理を終了）する。

【００６０】不要912の場合には、バックアップ要求801
を出したクライアントA30に全ファイルのファイル情報
問い合わせ802を発行する（7211）。このファイル情報
問い合わせ802の内容は、クライアント側処理の高速化
のため図21で設定した内容から、チェックコードを除い
たものにする。チェックサムやＣＲＣなどのチェックコ
ード処理を行っても性能的に問題無い場合には、7216、
7217、7218、7219の処理を7211の処理中に行ってもよ
い。

【００６１】クライアントA30から送られてくるファイ
ル情報送信803を受信する（7212）。続いて同一見込み
リスト1061を作成する（7215）。同一見込みリスト1061
は図２５に示すようにファイルのパス名の一覧であり、
その記憶には一時的なメモリ領域（変数領域）を使用す
れば良い。図２３の処理7212で受け取った内容と、共通
ストア103とオーナー対応表1052の内容を比較し、共通
するファイルのパス名を同一見込みリスト1061に格納す
る）。

【００６２】続いてチェックコードによる確認が必要か
どうかを判定する（7216）。必要でないなら、図２４の
処理（7221）に進む。必要な場合には、図２３の処理72
17、7218、7219を実行する。すなわち、同一見込みリス
ト1061中の各ファイルのチェックコードをクライアント
側に要求する（7217）。言い換えると、処理7216では図
２３の処理7211、7212で照会した結果、同一であると考
えられるファイルのチェックコードをクライアントに要
求していることになる。そしてクライアントからチェッ
クコードを受信し（7218）、共通ストア内のファイルの
チェックコードと比較し、チェックコードが同じでない
ファイルを同一見込みリスト1061から取り除き（721
9）、図２４の処理（7221）に進む。

【００６３】図２４では、最初に同一見込みリスト1061
に入っていないファイルがあるかどうかを判定し（722
1）、ない場合には復帰（処理を終了）する。ある場合
には、同一見込みリストに入っていないファイルの送信
要求をクライアントに発行し（7223）、以下、第二の実
施例と同様に、ファイルをクライアントA30から受け取
り（7224）、受信したファイルのそれぞれについて、共
通ストア103内に同一内容のファイルが無いかどうかを
確認しオーナー対応表1052と共通ストア103の内容を更
新し（7225）、復帰（処理を終了）する。続いて、同一
見込みリスト1061が空かどうかを判断し（7226）、空な
ら復帰（処理終了）。そうでないなら、同一見込みリス
ト1061内の各ファイルについてオーナー対応表の内容を
更新（処理対象となっているクライアント名を追加）
（7227）し、復帰（処理終了）する。

【００６４】上述のように、第三の実施例によれば、ク
ライアントからサーバにバックアップファイルを送信す
る際に、ファイル属性情報（ファイルパス名・ファイル
サイズ・タイムスタンプなど）やファイル内容のチェッ
クコード（ＣＲＣ・チェックサム等）をサーバ・クライ
アント間で事前に交換することで、サーバ上にすでにあ
るファイルを再度送らずにすませることができ、バック
アップ時のサーバの処理負荷、クライアントの処理負
荷、ネットワーク負荷を低減し、バックアップ処理時間
も短縮できる。

【００６５】４．第四、第五の実施例の概要第四、第五の実施例はリストア時に発生するサーバ10か
らクライアントA30へのファイル転送の方法に関するも
ので、第一の実施例、第二の実施例、第三の実施例のリ
ストア処理に追加あるいはリストア処理を置き換える形
で適用できる。以下、第四、第五の実施例に共通する内
容について説明する。

【００６６】クライアントA30のバックアップファイル
をサーバ10に保管する場合、同じクライアントA30のバ
ックアップ処理を繰り返すと、第三の実施例あるいは差
分バックアップ等の技術を用いることで、クライアント
A30からサーバ10への毎回のファイル転送量は低減され
る。一方、リストアでは対象クライアントのリストア用
のファイルをすべて送るため、ファイル転送量は大きく
なる。一般的にバックアップは定期的に行われるのに対
して、リストアの頻度は低い。

【００６７】すなわち、バックアップでは比較的小容量
のファイル転送が多く行われるのに対して、リストアで
は大容量のファイル転送が低い頻度で発生する。第四、
第五の実施例はこのファイル転送の性質の違いを利用
し、バックアップ時とリストア時とでファイル転送手段
を変えるものである。

【００６８】５．第四の実施例：記憶メディアによるリ
ストア以下、第四の実施例を第二の実施例をベースに説明する
が、第一の実施例、第三の実施例にも適用可能である。

【００６９】第四の実施例ではリストア時に発生するサ
ーバ10からクライアントA30へのファイルの受け渡しに
記憶メディアを使う。そのためサーバ10、クライアント
A30双方に記憶メディアの読み書き装置を設ける。

【００７０】図２６はサーバ10のハードウェア構成を示
したもので、図2に示す第一の実施例のハードウェア構
成に記憶メディア書き込み装置47を追加している。記憶
メディア書き込み装置47は記憶メディア49に情報を書き
込む機能を有するもので読み書き兼用であってもよい。
記憶メディア49はたとえばＭＯ、ＣＤ−ＲＯＭ（書き換
え可能型）、ＤＶＤ（書き換え可能型）などの可搬型の
記憶メディアが好ましいが、必ずしも可搬型である必要
はなく、サーバ10からクライアントA30にデータ（ファ
イル）を受け渡し可能な記憶手段ならば良い。

【００７１】図２７はクライアントA30のハードウェア
構成を示したもので、サーバ10の場合と同様、第一の実
施例で取り上げた図２に記憶メディア読み込み装置48を
追加したものになっている。記憶メディア読みとり装置
48は、少なくとも記憶メディア49に格納されている情報
を読み出す機能を有している。書き込み機能を有してい
ても差し支えない。

【００７２】図２８は記憶メディアによるリストア処理
のためのシステム構成とデータの流れを示した図であ
る。サーバ10内に、オーナー対応表1052、共通ストア10
3、クライアント用メディア作成処理1062、メディア書
き込み処理1063を備える。オーナー対応表1052、共通ス
トア103は図１２に記したものと同じである。リストア
データ生成処理1062（前記ＣＰＵ41が前記メモリ42上で
実行するプログラムとして実現される）はオーナー対応
表1052、共通ストア103を元にクライアントに渡すデー
タを生成する機能を持つ。メディア書き込み処理1063
（前記ＣＰＵ41が前記メモリ42上で実行するプログラム
として実現される）はリストアデータ生成処理1062で作
られたデータを記憶メディア49に書き込む機能を持つ。
一方、クライアントA30内にはメディア読み取り処理305
1とリストア処理3052（それぞれ前記メモリ42上に前記
ＣＰＵ41が実行するプログラムとして実現される）、フ
ァイル装置301がある。メディア読み取り処理3051は記
憶メディア49内に記憶されている情報を読み出す機能を
持つ。

【００７３】図２９は記憶メディア49の記憶内容を示し
た図である。記憶メディア49内に複数台のクライアント
の情報を含む場合と単独のクライアントの場合とでは構
造が異なる。複数格納時491の場合には、オーナー対応
表4911と共通ストアファイル4912を含んでいる。すなわ
ち、記憶メディア49上でもクライアント間でのファイル
共有手法が働くようにしている。なお代案として、複数
のクライアントファイルを個別に格納する形（493）に
しても良い。単独の場合には、リストア対象のクライア
ント用のファイルを入れる（492）。

【００７４】図３０はサーバ側の記憶メディア作成処理
1062を示した図である。最初に全クライアントのリスト
アデータを記憶メディア49に格納するか、一部を格納す
るかをたとえば図３１に示す選択画面中の全体915か指
定916にてユーザに選択させる。指定916が選択された場
合にはさらにどのクライアントかをユーザに選択させ
る。常にクライアント全体を選択する形で良いならこの
選択画面は必要ない。次にユーザによって選択されたク
ライアントの台数が単数か複数かを判定する。複数なら
オーナー対応表1052の中を調べ、指定された複数クライ
アントがオーナーとなっているレコードを抜き出し記憶
メディア49に書き込み、さらにそのファイルの本体を共
通ストア103から抜き出して記憶メディア49に書き込
む。単数の場合には、オーナー対応表1052の中を調べ、
指定されたクライアントがオーナーとなっているファイ
ルの本体を共通ストア103から抜き出して記憶メディア4
9に書き込む。

【００７５】図３２はクライアント側のリストア処理30
52の流れを示した図である。まず記憶メディア49に格納
されている内容を調べ、オーナー対応表4911が含まれて
いるかどうかを判定する。オーナー対応表4911が無いな
ら、単数のクライアントの情報が含まれていると判断
し、特定クライアント用ファイル4921の内容をクライア
ントA30自身のファイル装置301にリストアして、リスト
ア処理は終了となる。オーナー対応表4911があるなら、
オーナー対応表4911内に登場するクライアントのうち、
どのクライアントに対してリストア操作を行うかをたと
えば図３３のようなユーザへの確認画面を用いてユーザ
に確認する。またクライアントA30のＯＳ（Operating S
ystem）がクライアント名を保持しているなどの理由
で、クライアントA30自身がクライアント名を知る手段
があるならその手段を使って得られたクライアント名を
自動的に選択する形にしても良い。その場合にはユーザ
によるクライアント名の選択操作は不要になる。クライ
アント名が明らかになった所で、記憶メディア49内のオ
ーナー対応表4911の内容を調べ、該当クライアント用の
ファイル（群）を見つけだし、共通ストアファイル4912
から対応するファイルの本体を取り出し、ファイル装置
301にリストアして終了する。

【００７６】６．第五の実施例：大容量通信回線利用に
よるリストア第五の実施例はリストア時のサーバ10−クライアントA3
0間データ転送に、通信衛星利用回線のような大容量デ
ータ転送向きの通信回線を用いるものである。これは本
発明でのリストアのような比較的大容量のデータ送信に
向く。また、前記通信衛星経由の通信を含むマルチキャ
スト、ブロードキャストなどの多数の相手に同時にデー
タを転送することが可能な通信手段は、本発明のような
複数のクライアントでデータを共有するような構造を持
つデータの配布に向く。なお通信回線のデータ帯域に余
裕があるならリストアデータ、すなわちオーナー対応表
1052と共通ストア103を常時送信しておいて、クライア
ントはリストアの必要が生じた時に、送られているデー
タを受信するという形にしても良い。

【００７７】第五の実施例ではデータ転送手段として通
信衛星を用いるため、サーバ10側には通信衛星に対する
送信装置、クライアントA30側には通信衛星からの受信
装置を備える。サーバ10側のハード構成例を図３４に、
クライアントA30側のハード構成例を図３５に示す。

【００７８】図３６は通信衛星を用いたリストア部分の
システム構成例である。第四の実施例とほぼ同様な構成
となっているが、第五の実施例では記憶メディア49の代
わりに通信衛星61を用いる。それに合わせてサーバ10側
にＢＳ（Broadcast Satellite）送信装置1065、クライ
アントA30側にＢＳ受信装置3061を備える。処理内容は
第四の実施例と同様である。

【００７９】上述のように、第四、第五の実施例によれ
ば、リストア処理時に発生するサーバからクライアント
へのファイル転送手段として、ＭＯディスクなどの記憶
媒体または衛星通信などの大容量通信回線を用いること
で、通常用いるサーバ・クライアント間のネットワーク
トラヒックを低減できる。

【００８０】

【発明の効果】本発明によれば、複数のクライアント機
が使用される環境において、クライアント機の記憶装置
のバックアップデータサイズを縮小することができる。

【００８１】さらにバックアップへの障害をなくすこと
でバックアップを促しディスククラッシュからの復旧に
対応できるようになり、システムの管理コストを低減す
ることが可能になる。

【図面の簡単な説明】

【図１】本発明によるクライアント向きバックアップシ
ステムの原理図である。

【図２】本発明のハードウェア構成を示す図である。

【図３】本発明の論理構成図を示す図である。

【図４】バックアップのプロトコルを示す図である。

【図５】リストアのプロトコルを示す図である。

【図６】サーバ側のメイン処理を示す図である。

【図７】サーバ側のバックアップ処理を示す図である。

【図８】サーバ側のリストア処理を示す図である。

【図９】共有効果の確認画面例を示す図である。

【図１０】クライアント別共有比率の表示画面例を示す
図である。

【図１１】共有状況表示画面例を示す図である。

【図１２】第二の実施例の構成図を示す図である。

【図１３】オーナー対応表の例１を示す図である。

【図１４】オーナー対応表の例２を示す図である。

【図１５】第二の実施例のバックアップ処理を示す図で
ある。

【図１６】第二の実施例の状況表示画面例を示す図であ
る。

【図１７】第二の実施例におけるファイル早見表の構造
を示す図である。

【図１８】第二の実施例におけるファイル探索手法の例
を示す図である。

【図１９】第三の実施例の構成図を示す図である。

【図２０】第三の実施例のプロトコルを示す図である。

【図２１】第三の実施例の設定画面例を示す図である。

【図２２】第三の実施例のクライアント側処理を示す図
である。

【図２３】第三の実施例のバックアップ処理（前半）を
示す図である。

【図２４】第三の実施例のバックアップ処理（後半）を
示す図である。

【図２５】同一見込みリストの例を示す図である。

【図２６】第四の実施例、サーバのハードウェア構成を
示す図である。

【図２７】第四の実施例、クライアントのハードウェア
構成を示す図である。

【図２８】第四の実施例、論理構成図を示す図である。

【図２９】第四の実施例、記憶メディアの内容を示す図
である。

【図３０】第四の実施例、サーバ側記憶メディア作成処
理を示す図である。

【図３１】第四の実施例、メディア作成種別指定画面例
を示す図である。

【図３２】第四の実施例、リストア処理の内容を示す図
である。

【図３３】第四の実施例、クライアント名選択画面例を
示す図である。

【図３４】第五の実施例、サーバのハードウェア構成を
示す図である。

【図３５】第五の実施例、クライアントのハードウェア
構成を示す図である。

【図３６】第五の実施例、通信衛星経由のリストアファ
イル転送を示す図である。

【符号の説明】

10…サーバ、101…共通／固有振り分け処理、102…個別
ファイル合成処理、103…共通ストア、1041…固有スト
アA、1042…固有ストアB、20…ネットワーク、30…クラ
イアントA、301…クライアントA用ファイル装置、31…
クライアントB、311…クライアントB用ファイル装置。

───────────────────────────────────────────────────── フロントページの続き (72)発明者齋藤太朗神奈川県横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウェア事業部内Ｆターム(参考） 5B082 DA02 DC05 DE06 HA08

Claims

【特許請求の範囲】

【請求項１】複数のクライアント機器と、サーバ機器と
からなるネットワークシステムにおけるデータバックア
ップシステムであって、前記サーバ機器は、前記各クライアント機器が持つデータから各クライアン
ト機器に共通なデータ部分と各クライアントに固有なデ
ータ部分とを検出する手段と、前記共通なデータ部分を
保存する共通データ保存手段と、前記固有なデータ部分を保存する固有データ保存手段と
を備えることを特徴とするデータバックアップシステ
ム。
【請求項２】請求項１記載のデータバックアップシステ
ムにおいて、前記共通データ保存手段に保存されたデー
タそれぞれが、どのクライアント機器のデータであるか
を示すデータを記憶する手段を備えることを特徴とした
データバックアップシステム。
【請求項３】請求項１記載のデータバックアップシステ
ムにおいて、前記蓄積されたデータを、前記クライアント機器別にリ
ストアする手段を備えることを特徴としたデータバック
アップシステム。
【請求項４】請求項１記載のデータバックアップシステ
ムにおいて、前記クライアント機器は、バックアップ対象となるデー
タの属性情報を前記サーバ機器へ送信する手段を備える
ことを特徴としたデータバックアップシステム。
【請求項５】請求項４記載のデータバックアップシステ
ムにおいて、前記サーバ機器は、各クライアント機器から送信された
前記データ属性情報にもとづいて、データバックアップ
時に前記クライアント機器から前記サーバ機器に転送す
る必要のあるファイルを決定する手段を備えることを特
徴としたデータバックアップシステム。