JP4126706B2 - データバックアップのための装置、方法、及びプログラム - Google Patents
データバックアップのための装置、方法、及びプログラム Download PDFInfo
- Publication number
- JP4126706B2 JP4126706B2 JP2006058259A JP2006058259A JP4126706B2 JP 4126706 B2 JP4126706 B2 JP 4126706B2 JP 2006058259 A JP2006058259 A JP 2006058259A JP 2006058259 A JP2006058259 A JP 2006058259A JP 4126706 B2 JP4126706 B2 JP 4126706B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- medium
- backup job
- backup
- identification information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1461—Backup scheduling policy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
- G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、ある記録媒体に記録されたデータを別の記録媒体にバックアップするための装置等に関し、より詳しくは、バックアップ対象のデータのうちバックアップすべき部分を特定してバックアップする装置等に関する。
磁気ディスク等の記録媒体に記録されたデータが障害等により破壊された場合、そのデータを復旧するには多大の労力を要する。そこで、業務外のある時点でバックアップジョブを実行し、重要なデータは磁気テープ等の記録媒体(バックアップメディア)にコピー(バックアップ)することが一般に行われている。これにより、万が一、データが破壊されたとしても、バックアップメディアにコピーされたデータを用いて、破壊されたデータを復元(リストア)することができる。
このようなバックアップの手法としては、従来から、種々のものが提案されてきた。
第１の手法として、バックアップを短時間に終了させることの可能な差分バックアップがある。即ち、毎回のバックアップジョブでは、バックアップ対象のデータのうち前回のバックアップジョブ以降に変更された部分を抽出し、その部分をテープ等の記録媒体にコピーする、というものである。より具体的には、以下のような手順で行われる。
１) 初回のバックアップジョブでは、バックアップ対象のデータの全部のバックアップ(全バックアップ)を作成する。
２) ２回目以降のバックアップジョブでは、その時点におけるデータと、前回のバックアップジョブを実行した時点におけるデータとの差分を抽出し、差分バックアップを作成する。ここで、差分は、ファイルのタイムスタンプ、ファイルシステムやディスク装置がディスクブロックに割り当てて管理しているデータのバージョンナンバー等に基づいて抽出することが可能である。
第１の手法として、バックアップを短時間に終了させることの可能な差分バックアップがある。即ち、毎回のバックアップジョブでは、バックアップ対象のデータのうち前回のバックアップジョブ以降に変更された部分を抽出し、その部分をテープ等の記録媒体にコピーする、というものである。より具体的には、以下のような手順で行われる。
１) 初回のバックアップジョブでは、バックアップ対象のデータの全部のバックアップ(全バックアップ)を作成する。
２) ２回目以降のバックアップジョブでは、その時点におけるデータと、前回のバックアップジョブを実行した時点におけるデータとの差分を抽出し、差分バックアップを作成する。ここで、差分は、ファイルのタイムスタンプ、ファイルシステムやディスク装置がディスクブロックに割り当てて管理しているデータのバージョンナンバー等に基づいて抽出することが可能である。
しかし、この手法でバックアップを作成した場合、データを復元する作業の負担が重くなる。まず、初回のバックアップジョブで作成した全バックアップを戻し、次に、２回目以降のバックアップジョブで作成した差分バックアップを順次戻していかなければならないからである。また、復元に必要なバックアップデータが多数の媒体に分散して記録されるため、媒体の紛失や損傷によりデータを復元できなくなるリスクもある。
そこで、かかる作業負担やリスクを軽減するため、何回かに１回のバックアップジョブで全バックアップを作成する手法(第２の手法)を採用するのが一般的である。例えば、１週間に１回、全バックアップを作成し、その他の日は、差分バックアップを作成する、といったものである。
そこで、かかる作業負担やリスクを軽減するため、何回かに１回のバックアップジョブで全バックアップを作成する手法(第２の手法)を採用するのが一般的である。例えば、１週間に１回、全バックアップを作成し、その他の日は、差分バックアップを作成する、といったものである。
また、第３の手法として、ＵＮＩＸ（登録商標）の「ｄｕｍｐ」コマンドに見られるような、レベル付きの差分バックアップもある。この手法では、バックアップにレベルを付け、例えば、毎月のバックアップ、毎週のバックアップ、毎日のバックアップを、それぞれ異なるレベルで行う。そして、毎回のバックアップでは、実際にバックアップすべき差分の抽出を、このレベルの大小によりコントロールする。例えば、毎週のバックアップでは、毎日のバックアップでバックアップを作成したかどうかとは無関係に、前回の毎週又は毎月のバックアップ以降に変更されたデータの全てを抽出し、バックアップメディアにコピーする。
そして、データの復元は、まず毎月のバックアップで最近の月の状態まで戻し、次にその状態からの差分を毎週のバックアップで戻し、最後に毎日のバックアップで１日単位の精度で戻す、といった手法で行う。
この粒度の異なるバックアップを組み合わせる手法によれば、復元に要するバックアップメディアの数をやや減らすことができる。
そして、データの復元は、まず毎月のバックアップで最近の月の状態まで戻し、次にその状態からの差分を毎週のバックアップで戻し、最後に毎日のバックアップで１日単位の精度で戻す、といった手法で行う。
この粒度の異なるバックアップを組み合わせる手法によれば、復元に要するバックアップメディアの数をやや減らすことができる。
更に、第４の手法として、バックアップのスケジューリングに関する種々の技術が既に公知である(例えば、特許文献１、２参照)。
このうち、特許文献１には、バックアップ対象データの重要度及びそのデータを保持する記憶装置の信頼度を基に、バックアップスケジュール表を作成及び/又は編集し、このバックアップスケジュール表に記録されたスケジュールに従ってバックアップ処理を実行することが記載されている。
また、特許文献２には、重要度の高いデータはバックアップ頻度を多くし、重要度の低いデータはバックアップ頻度を少なくするように、バックアップ周期或いはデータ蓄積件数の下限をパラメータとして、バックアップタイミングを制御することが記載されている。
このうち、特許文献１には、バックアップ対象データの重要度及びそのデータを保持する記憶装置の信頼度を基に、バックアップスケジュール表を作成及び/又は編集し、このバックアップスケジュール表に記録されたスケジュールに従ってバックアップ処理を実行することが記載されている。
また、特許文献２には、重要度の高いデータはバックアップ頻度を多くし、重要度の低いデータはバックアップ頻度を少なくするように、バックアップ周期或いはデータ蓄積件数の下限をパラメータとして、バックアップタイミングを制御することが記載されている。
ところで、近年、社会情勢の変化により、１週間のビジネスが２４時間×７日にわたって行われるようになってきている。従って、週末といえども、バックアップに余分な時間をかけるわけにはいかない。
このような社会の要請に対し、第１乃至第３の手法は、満足できる解決策を与えるものではなかった。いずれの手法においても、全バックアップを行う日が存在するからである。即ち、差分バックアップを行う日は、短時間でバックアップが終了するものの、全バックアップを行う日は、バックアップに要する時間が非常に長くなってしまう。そして、この全バックアップにかかる時間が、システムのバックアップを設計する上でのボトルネックとなっているのが現状である。
このような社会の要請に対し、第１乃至第３の手法は、満足できる解決策を与えるものではなかった。いずれの手法においても、全バックアップを行う日が存在するからである。即ち、差分バックアップを行う日は、短時間でバックアップが終了するものの、全バックアップを行う日は、バックアップに要する時間が非常に長くなってしまう。そして、この全バックアップにかかる時間が、システムのバックアップを設計する上でのボトルネックとなっているのが現状である。
かかる状況を打開するためには、全バックアップのような所要時間の突出したバックアップを行う日をなくし、毎日のバックアップに要する時間をなるべく均一にすることが要求される。しかしながら、現在のところ、この要求を満足するための有効な解決策は知られていない。また、特許文献１、２に記載された第４の手法の場合、全バックアップを行う日の存在を明示しているわけではないが、毎日のバックアップに要する時間を均一にするための構成を開示するものでもないので、同じく上記要求に対する解決策を与えるものではない。
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、リストアに要する媒体の本数を所定の数以内に抑えつつ、毎回のバックアップに要する時間を短くし、かつ、均一にすることにある。
かかる目的のもと、本発明では、バックアップするデータに対し、有効期限を付与するようにした。そして、前回のバックアップジョブの実行後に更新されたデータに加え、既にバックアップしたものの有効期限が切れてしまったデータもバックアップすることにした。これにより、各データのバックアップは、有効期限として設定された日数内のいずれかの日に必ず作成される。しかも、有効期限として設定された日数内の各日に分散して作成されることになる。
例えば、有効期限を７日とすると、必ず最新７日分のバックアップメディアに全データが分散して格納されることになる。即ち、全バックアップの場合は１日に現れていたピークを、７日間に分散することができるのである。実際、全データに対しランダムに書き込みが行われる場合は、毎日のバックアップに要する時間は均一になることが期待される。
また、ランダムではなく規則性がある場合、例えば、書き込みが殆どなされないデータがある場合であっても、次のように対処できる。即ち、書き込みが殆どなされない部分を予め分割し、初回に日をずらしてバックアップしておくことにより、以降のバックアップを分散したまま行うことができる。
例えば、有効期限を７日とすると、必ず最新７日分のバックアップメディアに全データが分散して格納されることになる。即ち、全バックアップの場合は１日に現れていたピークを、７日間に分散することができるのである。実際、全データに対しランダムに書き込みが行われる場合は、毎日のバックアップに要する時間は均一になることが期待される。
また、ランダムではなく規則性がある場合、例えば、書き込みが殆どなされないデータがある場合であっても、次のように対処できる。即ち、書き込みが殆どなされない部分を予め分割し、初回に日をずらしてバックアップしておくことにより、以降のバックアップを分散したまま行うことができる。
このようなバックアップ手法を具体化する本発明の装置は、バックアップ対象のデータの全部又は一部を媒体にコピーするバックアップジョブを実行するシステムにおける装置であって、次のような構成を備えている。即ち、既に実行されたバックアップジョブに関する管理情報を取得する取得部と、管理情報に基づいて、予め決められた期間、媒体にコピーされていないデータの部分を特定し、その部分を媒体にコピーすることを決定する決定部とを備えている。
また、この装置は、データの部分と、その部分を媒体にコピーしたバックアップジョブの識別情報との対応関係を示す管理情報を記憶する記憶部を更に備えてもよい。
更に、この装置は、データの部分の更新に応じて、管理情報でその部分に対応付けられた識別情報を消去する消去部を更に備え、決定部は、識別情報が消去されている場合に、部分を媒体にコピーすることを決定するものであってもよい。
また、この装置は、データの部分と、その部分を媒体にコピーしたバックアップジョブの識別情報との対応関係を示す管理情報を記憶する記憶部を更に備えてもよい。
更に、この装置は、データの部分の更新に応じて、管理情報でその部分に対応付けられた識別情報を消去する消去部を更に備え、決定部は、識別情報が消去されている場合に、部分を媒体にコピーすることを決定するものであってもよい。
また、本発明は、データを媒体にバックアップするための方法として捉えることもできる。その場合、本発明の方法は、データの前回のバックアップからの経過期間が、予め決められた期間に達しているかどうかを判定するステップと、経過期間が予め決められた期間に達していると判定された場合に、データを媒体にバックアップするステップとを含んでいる。
更に、本発明は、所定の機能をコンピュータに実現させるプログラムとして捉えることもできる。その場合、本発明のプログラムは、バックアップ対象のデータの全部又は一部を媒体にコピーするバックアップジョブを実行するシステムにおいて用いられるプログラムである。そして、このシステムを構成するコンピュータに対し、既に実行されたバックアップジョブに関する管理情報を取得する機能と、管理情報に基づいて、予め決められた期間、媒体にコピーされていないデータの部分を特定し、その部分を媒体にコピーすることを決定する機能とを実現させるものである。
本発明によれば、リストアに要する媒体の本数を所定の数以内に抑えつつ、毎回のバックアップに要する時間を短くし、かつ、均一にすることが可能となる。
以下、添付図面を参照して、本発明を実施するための最良の形態(以下、「実施の形態」という)について詳細に説明する。
図１〜３は、本発明の実施の形態によるバックアップの概要を説明するための図である。
このうち、図１は、データセット＃１〜＃１２が１４日間に変更されていく様子を視覚化したものである。ここでは、網掛けによる濃度の違いでデータセットの世代(書き換えの有無)を表している。即ち、白塗りのデータセットが更新されて細い斜線のデータセットになり、これが更新されて太い斜線のデータセットになり、それが更新されて黒塗りのデータセットになっている。例えば、データセット＃１は、５日目と１０日目と１１日目に書き換えられており、データセット＃２は、１日目と６日目に書き換えられている。一方、データセット＃９、＃１１、＃１２は、この１４日間で１回も書き換えられていない。
尚、本明細書において、「データセット」とは、例えば、データブロックやファイルを指すが、一まとまりの何らかのデータの単位であれば、如何なるものであってもよい。
図１〜３は、本発明の実施の形態によるバックアップの概要を説明するための図である。
このうち、図１は、データセット＃１〜＃１２が１４日間に変更されていく様子を視覚化したものである。ここでは、網掛けによる濃度の違いでデータセットの世代(書き換えの有無)を表している。即ち、白塗りのデータセットが更新されて細い斜線のデータセットになり、これが更新されて太い斜線のデータセットになり、それが更新されて黒塗りのデータセットになっている。例えば、データセット＃１は、５日目と１０日目と１１日目に書き換えられており、データセット＃２は、１日目と６日目に書き換えられている。一方、データセット＃９、＃１１、＃１２は、この１４日間で１回も書き換えられていない。
尚、本明細書において、「データセット」とは、例えば、データブロックやファイルを指すが、一まとまりの何らかのデータの単位であれば、如何なるものであってもよい。
ここで、図２は、従来技術として述べた、１週間に１回全バックアップを行い、その他の日に差分バックアップを行う手法を用いた場合に、各データセットが実際にバックアップされる日を示したものである。
この手法では、図から明らかなように、０日目、７日目、１４日目に全てのデータセットがバックアップされている。そして、その他の日においては、その日に更新されたデータセットのみがバックアップされている。例えば、データセット＃１は、５日目と１０日目と１１日目に書き換えられているので、０日目、７日目、１４日目に加え、これらの日にもバックアップされている。また、データセット＃２は、１日目と６日目に書き換えられているので、０日目、７日目、１４日目に加え、これらの日にもバックアップされている。
この手法では、図から明らかなように、０日目、７日目、１４日目に全てのデータセットがバックアップされている。そして、その他の日においては、その日に更新されたデータセットのみがバックアップされている。例えば、データセット＃１は、５日目と１０日目と１１日目に書き換えられているので、０日目、７日目、１４日目に加え、これらの日にもバックアップされている。また、データセット＃２は、１日目と６日目に書き換えられているので、０日目、７日目、１４日目に加え、これらの日にもバックアップされている。
一方、図３は、本実施の形態の手法を用いた場合に、各データセットが実際にバックアップされる日を表したものである。ここでは、有効期限を７日としている。
例えば、データセット＃１は、５日目と１０日目と１１日目に書き換えられているので、これらの日にバックアップされている。但し、データセット＃１は、有効期限である７日が経過する前に常に書き換えられているので、有効期限切れによるバックアップは行われていない。
また、データセット＃２は、１日目と６日目に書き換えられているので、これらの日にバックアップされている。そして、６日目に書き換えられた後、有効期限である７日が経過しても書き換えられていないので、１３日目に有効期限切れによるバックアップが行われている。
例えば、データセット＃１は、５日目と１０日目と１１日目に書き換えられているので、これらの日にバックアップされている。但し、データセット＃１は、有効期限である７日が経過する前に常に書き換えられているので、有効期限切れによるバックアップは行われていない。
また、データセット＃２は、１日目と６日目に書き換えられているので、これらの日にバックアップされている。そして、６日目に書き換えられた後、有効期限である７日が経過しても書き換えられていないので、１３日目に有効期限切れによるバックアップが行われている。
その他のデータセットも、書き換えられた日に加え、前回のバックアップから７日が経過する日にもバックアップするようにしている。例えば、データセット＃３の１１日目、データセット＃５の９日目、データセット＃８の７日目、データセット＃９の７日目及び１４日目、データセット＃１０の７日目、データセット＃１１の７日目及び１４日目、データセット＃１２の７日目及び１４日目が、このようなバックアップに該当する。
そして、図２と図３を比較すると明らかなように、本実施の形態の手法を用いることにより、従来の手法では全バックアップを行っていた７日目や１４日目に、全バックアップを行う必要がなくなっている。即ち、毎日のバックアップに要する時間の短縮及び均一化が図れている。
そして、図２と図３を比較すると明らかなように、本実施の形態の手法を用いることにより、従来の手法では全バックアップを行っていた７日目や１４日目に、全バックアップを行う必要がなくなっている。即ち、毎日のバックアップに要する時間の短縮及び均一化が図れている。
以下、本実施の形態の手法を用いてデータをバックアップするシステムの構成及び動作について説明する。尚、システムの形態としては、データセットを更新する機能及びバックアップすべきデータセットを決定する機能とが連携している形態と、これらが連携していない形態とが考えられる。そこで、前者を第１の実施の形態、後者を第２の実施の形態として説明する。
［第１の実施の形態］
図４は、本実施の形態におけるシステムの構成を示したブロック図である。
図示するように、本実施の形態におけるシステムは、データ記憶部１１と、アプリケーションプログラム(以下、「ＡＰ」という)１２と、第１アクセス部１３と、第２アクセス部１４と、バックアップメディア１５とを含む。
図４は、本実施の形態におけるシステムの構成を示したブロック図である。
図示するように、本実施の形態におけるシステムは、データ記憶部１１と、アプリケーションプログラム(以下、「ＡＰ」という)１２と、第１アクセス部１３と、第２アクセス部１４と、バックアップメディア１５とを含む。
このうち、データ記憶部１１は、バックアップ対象のデータを記憶する記憶媒体であり、例えば、磁気ディスク装置によって実現される。また、ＡＰ１２は、データ記憶部１１に記憶されたデータの更新を伴う所定の処理を行うプログラムであり、第１アクセス部１３は、このＡＰ１２からの更新指示に従い、データ記憶部１１に記憶されたデータを更新する。また、第１アクセス部１３は、バックアップ時には、データ記憶部１１からデータを読み出して第２アクセス部１４に受け渡し、リストア時には、第２アクセス部１４から受け渡されたデータをデータ記憶部１１に書き込む。
一方、第２アクセス部１４は、バックアップ時には、第１アクセス部１３から受け渡されたデータをバックアップメディア１５に書き込み、リストア時には、バックアップメディア１５からデータを読み出して第１アクセス部１３に受け渡す。また、バックアップメディア１５は、データをバックアップするために用いられる記録媒体であり、例えば、磁気テープ等によって実現される。
尚、第１アクセス部１３及び第２アクセス部１４は、データ記憶部１１からバックアップメディア１５へデータを転送するという観点から、「転送部」として捉えることも可能である。
尚、第１アクセス部１３及び第２アクセス部１４は、データ記憶部１１からバックアップメディア１５へデータを転送するという観点から、「転送部」として捉えることも可能である。
これらに加え、本実施の形態は、データ記憶部１１に記憶されたデータのバックアップすべき部分を決定する機能を有する。特に、第１の実施の形態では、この機能が第１アクセス部１３に接続されている。この機能は、より詳細には、情報記憶部１６と、取得部１７と、決定部１８と、更新部１９とを含む。
このうち、情報記憶部１６は、バックアップすべき部分を決定するのに用いられる管理情報を記憶する部分であり、例えば、磁気ディスク装置により実現される。また、取得部１７は、この情報記憶部１６から管理情報を取得し、決定部１８は、この管理情報に基づいてバックアップすべきデータを決定する。更に、更新部１９は、必要に応じて管理情報を更新する。この管理情報の更新には、バックアップジョブのバージョン番号の消去や書き換えがあるが、特に前者だけに着目した場合、この更新部１９を「消去部」と捉えることも可能である。
このうち、情報記憶部１６は、バックアップすべき部分を決定するのに用いられる管理情報を記憶する部分であり、例えば、磁気ディスク装置により実現される。また、取得部１７は、この情報記憶部１６から管理情報を取得し、決定部１８は、この管理情報に基づいてバックアップすべきデータを決定する。更に、更新部１９は、必要に応じて管理情報を更新する。この管理情報の更新には、バックアップジョブのバージョン番号の消去や書き換えがあるが、特に前者だけに着目した場合、この更新部１９を「消去部」と捉えることも可能である。
ここで、情報記憶部１６に記憶される管理情報について説明する。
図５は、管理情報のうち、本実施の形態に直接関係する部分のみを抜き出して示したものである。即ち、管理情報には、ファイルシステムのメタデータ、磁気ディスク装置のブロック情報管理テーブル等があるが、そのような情報において、図５に示すような対応関係を管理する。即ち、データセットごとに、その番号と、そのデータセットの前回のバックアップを実行したバックアップジョブの実行回数を表す番号(以下、「バージョン番号」という)とを記録している。
尚、管理情報には、後述する有効期限Ｅや前回のバックアップジョブのバージョン番号等の情報を含めてもよい。
図５は、管理情報のうち、本実施の形態に直接関係する部分のみを抜き出して示したものである。即ち、管理情報には、ファイルシステムのメタデータ、磁気ディスク装置のブロック情報管理テーブル等があるが、そのような情報において、図５に示すような対応関係を管理する。即ち、データセットごとに、その番号と、そのデータセットの前回のバックアップを実行したバックアップジョブの実行回数を表す番号(以下、「バージョン番号」という)とを記録している。
尚、管理情報には、後述する有効期限Ｅや前回のバックアップジョブのバージョン番号等の情報を含めてもよい。
次に、本実施の形態におけるシステムの動作について説明する。尚、本実施の形態では、図３に示した例と同様、１日１回バックアップジョブが実行されるものとする。つまり、この場合、「有効期限」は、バックアップされたデータが有効でなくなるまでのバックアップジョブの実行回数と等価である。
まず、本システムにてバックアップすべきデータを決定する際の動作を説明する。
図６は、このときの動作の流れを示したフローチャートである。
バックアップジョブの開始が指示されると、取得部１７は、バージョン番号Ｍを取得する(ステップ１０１)。ここで、バージョン番号は、バックアップジョブの実行ごとに１ずつ増加する値である。そして、システムの構築時に初期値(例えばゼロ)に設定され、かつ、十分に大きな整数の値が最大値となっていることで、システムの使用期間内に使い切ることのない値の範囲を提供できるものであることが好ましい。尚、バージョン番号の取得方法としては、例えば、前回のバックアップジョブの終了時に、そのバックアップジョブのバージョン番号を予め決められた記憶領域に保存しておき、その記憶領域に保存されたバージョン番号に１を加算したものを今回のバックアップジョブのバージョン番号として用いることが考えられる。
図６は、このときの動作の流れを示したフローチャートである。
バックアップジョブの開始が指示されると、取得部１７は、バージョン番号Ｍを取得する(ステップ１０１)。ここで、バージョン番号は、バックアップジョブの実行ごとに１ずつ増加する値である。そして、システムの構築時に初期値(例えばゼロ)に設定され、かつ、十分に大きな整数の値が最大値となっていることで、システムの使用期間内に使い切ることのない値の範囲を提供できるものであることが好ましい。尚、バージョン番号の取得方法としては、例えば、前回のバックアップジョブの終了時に、そのバックアップジョブのバージョン番号を予め決められた記憶領域に保存しておき、その記憶領域に保存されたバージョン番号に１を加算したものを今回のバックアップジョブのバージョン番号として用いることが考えられる。
また、取得部１７は、バックアップされたデータの有効期限Ｅを取得し、今回のバックアップジョブにて有効期限切れとなるデータをバックアップしたバックアップジョブのバージョン番号Ｎを算出する(ステップ１０２)。ここで、有効期限Ｅは、システム構成時に構成情報の一部としてユーザの指定により設定されたものである。また、バージョン番号Ｎのバックアップジョブでバックアップされたデータが、その後のＥ回目のバックアップジョブである今回のバックアップジョブ(バージョン番号Ｍ)で有効期限切れになることから、バージョン番号Ｎは、Ｎ＝Ｍ−Ｅにより求めることができる。
尚、これらの情報は、決定部１８によるバックアップすべきかどうかの決定に用いられるものであるので、決定部１８に受け渡されるものとする。
尚、これらの情報は、決定部１８によるバックアップすべきかどうかの決定に用いられるものであるので、決定部１８に受け渡されるものとする。
次に、各データセットに対し、バックアップすべきかどうかの判定処理、及び、バックアップすべきと判定された場合のバックアップメディア１５へのコピー処理を行う。
即ち、取得部１７は、情報記憶部１６から、着目するデータセットの管理情報のうち、前回のバックアップを実行したバックアップジョブのバージョン番号Ｄを取得する(ステップ１０３)。そして、この情報も、決定部１８に受け渡す。
これにより、決定部１８は、ステップ１０３でバージョン番号Ｄが取得できたかどうかを判定する(ステップ１０４)。そのデータセットがまだ一度もバックアップされていない場合は、バージョン番号Ｄは存在しない。また、後述するように、前回のバックアップ後に更新されたデータセットについては、バージョン番号は消去されている。そこで、ステップ１０４では、これらのいずれかに該当していないかを判定する。
即ち、取得部１７は、情報記憶部１６から、着目するデータセットの管理情報のうち、前回のバックアップを実行したバックアップジョブのバージョン番号Ｄを取得する(ステップ１０３)。そして、この情報も、決定部１８に受け渡す。
これにより、決定部１８は、ステップ１０３でバージョン番号Ｄが取得できたかどうかを判定する(ステップ１０４)。そのデータセットがまだ一度もバックアップされていない場合は、バージョン番号Ｄは存在しない。また、後述するように、前回のバックアップ後に更新されたデータセットについては、バージョン番号は消去されている。そこで、ステップ１０４では、これらのいずれかに該当していないかを判定する。
その結果、バージョン番号Ｄが取得できなければ、上述したように、まだ一度もバックアップされていないか、前回のバックアップ後に更新されたかのいずれかであり、今回バックアップする必要があるので、着目するデータセットをデータ記憶部１１から読み出してバックアップメディア１５にコピーする(ステップ１０６)。具体的には、第１アクセス部１３がデータ記憶部１１から着目するデータセットを読み出して第２アクセス部１４に転送する。そして、第２アクセス部１４がそのデータセットをバックアップメディア１５に書き込む。また、その際、更新部１９は、情報記憶部１６に記憶された管理情報において、着目するデータセットに対して記憶されていたバージョン番号を、今回のバックアップジョブのバージョン番号Ｍに書き換える(ステップ１０７)。
一方、バージョン番号Ｄが取得できれば、バージョン番号Ｄがバージョン番号Ｎ以下であるかどうかを判定する(ステップ１０８)。
ここで、バージョン番号Ｄがバージョン番号Ｎ以下であれば、前回バックアップされたデータがもはや古くなっているので、新たにバックアップを行う必要がある。そこで、着目するデータセットをデータ記憶部１１から読み出してバックアップメディア１５にコピーする(ステップ１０６)。具体的には、第１アクセス部１３がデータ記憶部１１から着目するデータセットを読み出して第２アクセス部１４に転送する。そして、第２アクセス部１４がそのデータセットをバックアップメディア１５に書き込む。また、その際、更新部１９は、情報記憶部１６に記憶された管理情報において、着目するデータセットに対して記憶されていたバージョン番号を、今回のバックアップジョブのバージョン番号Ｍに書き換える(ステップ１０７)。
ここで、バージョン番号Ｄがバージョン番号Ｎ以下であれば、前回バックアップされたデータがもはや古くなっているので、新たにバックアップを行う必要がある。そこで、着目するデータセットをデータ記憶部１１から読み出してバックアップメディア１５にコピーする(ステップ１０６)。具体的には、第１アクセス部１３がデータ記憶部１１から着目するデータセットを読み出して第２アクセス部１４に転送する。そして、第２アクセス部１４がそのデータセットをバックアップメディア１５に書き込む。また、その際、更新部１９は、情報記憶部１６に記憶された管理情報において、着目するデータセットに対して記憶されていたバージョン番号を、今回のバックアップジョブのバージョン番号Ｍに書き換える(ステップ１０７)。
また、バージョン番号Ｄがバージョン番号Ｎよりも大きければ、バックアップは行わない。そして、バックアップが不要と判定された場合も、必要と判定された場合も、次のデータセットがあるかどうかを判定し(ステップ１０８)、次のデータセットがあれば、ステップ１０３へ進み、なければ処理を終了する。
次に、本システムにてデータセットの更新を管理情報に反映させる際の動作を説明する。
図７は、このときの動作の流れを示したフローチャートである。
ＡＰ１２からの指示により、第１アクセス部１３がデータ記憶部１１に記憶されたあるデータセットを更新することにより、この動作が開始する。
まず、更新部１９は、第１アクセス部１３から更新されたデータセットを特定する情報を受け取る(ステップ１１１)。
そして、更新部１９は、情報記憶部１６に記憶された管理情報において、該当するデータセットに対して記憶されていたバージョン番号を消去する(ステップ１１２)。
図７は、このときの動作の流れを示したフローチャートである。
ＡＰ１２からの指示により、第１アクセス部１３がデータ記憶部１１に記憶されたあるデータセットを更新することにより、この動作が開始する。
まず、更新部１９は、第１アクセス部１３から更新されたデータセットを特定する情報を受け取る(ステップ１１１)。
そして、更新部１９は、情報記憶部１６に記憶された管理情報において、該当するデータセットに対して記憶されていたバージョン番号を消去する(ステップ１１２)。
最後に、このようにしてバックアップしたデータセットを用いて、リストアを行う際の動作を説明する。
図８は、このときの動作の流れを示したフローチャートである。
まず、取得部１７は、復元したい日に対応するバックアップジョブのバージョン番号Ｊを取得する(ステップ１２１)。例えば、先に述べたバージョン番号を保存する記憶領域から最新のバージョン番号を取り出し、これをバージョン番号Ｊとすることができる。
次に、取得部１７は、バックアップされたデータの有効期限Ｅを取得し、これをバージョン番号Ｊから減算してバージョン番号(Ｊ−Ｅ)を求める。そして、バージョン番号(Ｊ−Ｅ)のバックアップジョブからバージョン番号Ｊのバックアップジョブまでに使用したバックアップメディア１５の用意を促す(ステップ１２２)。
図８は、このときの動作の流れを示したフローチャートである。
まず、取得部１７は、復元したい日に対応するバックアップジョブのバージョン番号Ｊを取得する(ステップ１２１)。例えば、先に述べたバージョン番号を保存する記憶領域から最新のバージョン番号を取り出し、これをバージョン番号Ｊとすることができる。
次に、取得部１７は、バックアップされたデータの有効期限Ｅを取得し、これをバージョン番号Ｊから減算してバージョン番号(Ｊ−Ｅ)を求める。そして、バージョン番号(Ｊ−Ｅ)のバックアップジョブからバージョン番号Ｊのバックアップジョブまでに使用したバックアップメディア１５の用意を促す(ステップ１２２)。
その後、バックアップメディア１５のバージョン番号をカウントするインデックスＬに初期値としてバージョン番号(Ｊ−Ｅ)を設定する(ステップ１２３)。そして、各バックアップメディア１５に対し、データの復元に関する処理を行う。
即ち、第２アクセス部１４は、バージョン番号Ｌのバックアップジョブにてバックアップしたデータセットを用いて、データを復元する(ステップ１２４)。具体的には、第２アクセス部１４がインデックスＬに対応するバックアップメディア１５からデータセットを読み出して第１アクセス部１３に転送する。そして、第１アクセス部１３がそのデータセットをデータ記憶部１１に書き込む。
即ち、第２アクセス部１４は、バージョン番号Ｌのバックアップジョブにてバックアップしたデータセットを用いて、データを復元する(ステップ１２４)。具体的には、第２アクセス部１４がインデックスＬに対応するバックアップメディア１５からデータセットを読み出して第１アクセス部１３に転送する。そして、第１アクセス部１３がそのデータセットをデータ記憶部１１に書き込む。
また、更新部１９は、情報記憶部１６に記憶された管理情報において、復元されたデータセットに対するバージョン番号としてバージョン番号Ｌを記憶する(ステップ１２５)。
次いで、バージョン番号Ｌに１を加算し(ステップ１２６)、バージョン番号Ｌがバージョン番号Ｊ以下かどうかを判定する(ステップ１２７)。
ここで、バージョン番号Ｌがバージョン番号Ｊ以下であれば、ステップ１２４に戻り、バージョン番号Ｊを超えれば、処理を終了する。
次いで、バージョン番号Ｌに１を加算し(ステップ１２６)、バージョン番号Ｌがバージョン番号Ｊ以下かどうかを判定する(ステップ１２７)。
ここで、バージョン番号Ｌがバージョン番号Ｊ以下であれば、ステップ１２４に戻り、バージョン番号Ｊを超えれば、処理を終了する。
以上により、本発明の第１の実施の形態の動作を終了する。
尚、本実施の形態では、前回のバックアップから有効期限が経過しているかどうかをバックアップジョブの実行回数で判断することとし、この実行回数の判断には、バージョン番号を用いることとした。しかしながら、個々のバックアップジョブを識別可能な情報であれば、バージョン番号以外の情報を用いることとしてもよい。また、バックアップジョブの実行回数で判断するのではなく、文字通り、日付情報を用いて有効期限の経過を判断するようにしてもよい。
尚、本実施の形態では、前回のバックアップから有効期限が経過しているかどうかをバックアップジョブの実行回数で判断することとし、この実行回数の判断には、バージョン番号を用いることとした。しかしながら、個々のバックアップジョブを識別可能な情報であれば、バージョン番号以外の情報を用いることとしてもよい。また、バックアップジョブの実行回数で判断するのではなく、文字通り、日付情報を用いて有効期限の経過を判断するようにしてもよい。
また、本実施の形態では、データセットが更新されたときに、情報記憶部１６に記憶されたそのデータセットに対するバージョン番号を消去するようにしたが、必ずしもこのような形態に限られるものではない。即ち、バージョン番号を通常あり得ないバージョン番号に変更する等、他の方法によってデータセットが更新されたことを示しておくことは可能である。尚、このとき、情報記憶部１６に記憶されたバージョン番号を更新部１９が変更することになるが、この変更機能だけに着目した場合、更新部１９を「変更部」と捉えることも可能である。
更に、本実施の形態では、前回のバックアップを行ったバックアップジョブのバージョン番号Ｄと、今回のバックアップジョブのバージョン番号Ｍから有効期限Ｅを減算した値Ｎとを比較し、ＤがＮ以下であれば、バックアップすることを決定するようにした。しかしながら、このような判断方法は、あくまで一例であり、いかなる方法を用いてもよい。例えば、バックアップしたデータセットに対し有効期限Ｅを記憶しておき、毎回のバックアップジョブの実行時にこの有効期限から１ずつ減算するようにしてもよい。このようにすれば、有効期限の値が０になったときに有効期限切れと判断することができる。
このように、本実施の形態では、バックアップデータに有効期限を付与し、毎回のバックアップジョブでは更新されたデータに加え有効期限切れのデータもバックアップするようにした。このような構成により、本実施の形態は、リストアに要する媒体の本数を所定の数以内に抑えつつ、毎回のバックアップに要する時間を短くし、かつ、均一にすることができるという効果を有する。
即ち、従来技術として述べた第１の手法の場合、２回目以降のバックアップジョブにおいては、バックアップ時間の短縮及び均一化はある程度可能であるが、バックアップメディアの数を所定数以内に抑えたいという要求に応えることはできない。また、第２及び第３の手法の場合、バックアップメディアの数はある程度抑えられるが、バックアップ時間の均一化の要求には応えられない。これに対し、本実施の形態の手法は、これら全ての要求に応えられるものである。
即ち、従来技術として述べた第１の手法の場合、２回目以降のバックアップジョブにおいては、バックアップ時間の短縮及び均一化はある程度可能であるが、バックアップメディアの数を所定数以内に抑えたいという要求に応えることはできない。また、第２及び第３の手法の場合、バックアップメディアの数はある程度抑えられるが、バックアップ時間の均一化の要求には応えられない。これに対し、本実施の形態の手法は、これら全ての要求に応えられるものである。
また、本実施の形態では、データの更新に応じて、バックアップすべきデータを決定するために用いる管理情報にその旨を反映させておくようにした。これにより、更新されたデータをバックアップすべきデータとして決定する処理を迅速に行うことも可能となった。
［第２の実施の形態］
図９は、本実施の形態におけるシステムの構成を示したブロック図である。
図示するように、本実施の形態におけるシステムは、データ記憶部１１と、ＡＰ１２と、第１アクセス部１３と、第２アクセス部１４と、バックアップメディア１５とを含む。尚、これらの構成は、第１の実施の形態で述べたものと同様であるので、詳細な説明を省略する。
図９は、本実施の形態におけるシステムの構成を示したブロック図である。
図示するように、本実施の形態におけるシステムは、データ記憶部１１と、ＡＰ１２と、第１アクセス部１３と、第２アクセス部１４と、バックアップメディア１５とを含む。尚、これらの構成は、第１の実施の形態で述べたものと同様であるので、詳細な説明を省略する。
これらに加え、本実施の形態は、データ記憶部１１に記憶されたデータのバックアップすべき部分を決定する機能を有する。特に、第２の実施の形態では、この機能が第２アクセス部１４に接続されている。この機能は、より詳細には、情報記憶部１６と、取得部１７と、決定部１８と、更新部１９とを含む。
このうち、情報記憶部１６は、バックアップすべき部分を決定するのに用いられる管理情報を記憶する部分であり、例えば、磁気ディスク装置により実現される。また、取得部１７は、この情報記憶部１６から管理情報を取得し、決定部１８は、この管理情報に基づいてバックアップすべきデータを決定する。更に、更新部１９は、必要に応じて管理情報を更新する。
このうち、情報記憶部１６は、バックアップすべき部分を決定するのに用いられる管理情報を記憶する部分であり、例えば、磁気ディスク装置により実現される。また、取得部１７は、この情報記憶部１６から管理情報を取得し、決定部１８は、この管理情報に基づいてバックアップすべきデータを決定する。更に、更新部１９は、必要に応じて管理情報を更新する。
ここで、情報記憶部１６に記憶される管理情報について説明する。
図１０は、管理情報のうち、本実施の形態に直接関係する部分のみを抜き出して示したものである。即ち、管理情報には、ファイルシステムのメタデータ、磁気ディスク装置のブロック情報管理テーブル等があるが、そのような情報において、図５に示すような対応関係を管理する。即ち、データセットごとに、その番号と、そのデータセットの前回のバックアップを実行したバックアップジョブの実行回数を表す番号(以下、「バージョン番号」という)と、前回のバックアップの日時を示すタイムスタンプとを記録している。
尚、管理情報には、後述する有効期限Ｅや前回のバックアップジョブのバージョン番号等の情報を含めてもよい。
図１０は、管理情報のうち、本実施の形態に直接関係する部分のみを抜き出して示したものである。即ち、管理情報には、ファイルシステムのメタデータ、磁気ディスク装置のブロック情報管理テーブル等があるが、そのような情報において、図５に示すような対応関係を管理する。即ち、データセットごとに、その番号と、そのデータセットの前回のバックアップを実行したバックアップジョブの実行回数を表す番号(以下、「バージョン番号」という)と、前回のバックアップの日時を示すタイムスタンプとを記録している。
尚、管理情報には、後述する有効期限Ｅや前回のバックアップジョブのバージョン番号等の情報を含めてもよい。
次に、本実施の形態におけるシステムの動作について説明する。尚、本実施の形態でも、図３に示した例と同様、１日１回バックアップジョブが実行されるものとする。つまり、この場合、「有効期限」は、バックアップされたデータが有効でなくなるまでのバックアップジョブの実行回数と等価である。
まず、本システムにてバックアップすべきデータを決定する際の動作を説明する。
図１１は、このときの動作の流れを示したフローチャートである。
バックアップジョブの開始が指示されると、取得部１７は、バージョン番号Ｍを取得する(ステップ１３１)。また、バックアップされたデータの有効期限Ｅを取得し、今回のバックアップジョブにて有効期限切れとなるデータをバックアップしたバックアップジョブのバージョン番号Ｎを算出する(ステップ１３２)。尚、バージョン番号Ｍやバージョン番号Ｎの取得方法は、第１の実施の形態と同様である。
図１１は、このときの動作の流れを示したフローチャートである。
バックアップジョブの開始が指示されると、取得部１７は、バージョン番号Ｍを取得する(ステップ１３１)。また、バックアップされたデータの有効期限Ｅを取得し、今回のバックアップジョブにて有効期限切れとなるデータをバックアップしたバックアップジョブのバージョン番号Ｎを算出する(ステップ１３２)。尚、バージョン番号Ｍやバージョン番号Ｎの取得方法は、第１の実施の形態と同様である。
更に、本実施の形態では、取得部１７が、バックアップ対象のデータの更新時刻を示すタイムスタンプを、第１アクセス部１３及び第２アクセス部１４を介して取得しておく(ステップ１３３)。
尚、これらの情報は、決定部１８によるバックアップすべきかどうかの決定に用いられるものであるので、決定部１８に受け渡されるものとする。
尚、これらの情報は、決定部１８によるバックアップすべきかどうかの決定に用いられるものであるので、決定部１８に受け渡されるものとする。
次に、各データセットに対し、バックアップすべきかどうかの判定処理、及び、バックアップすべきと判定された場合のバックアップメディアへのコピー処理を行う。
即ち、取得部１７は、情報記憶部１６から、着目するデータセットの管理情報のうち、前回のバックアップを実行したバックアップジョブのバージョン番号Ｄと、前回のバックアップの日時を示すタイムスタンプとを取得する(ステップ１３４)。そして、この情報も、決定部１８に受け渡す。
これにより、決定部１８は、ステップ１３３で取得したタイムスタンプとステップ１３４で取得したタイムスタンプとが等しいかどうかを判定する(ステップ１３５)。そのデータセットがまだ一度もバックアップされていない場合や、そのデータセットが前回のバックアップ後に更新された場合は、ステップ１３３で取得したタイムスタンプの方が新しくなっているはずである。そこで、ステップ１３５では、このような状態になっていないかを判定する。尚、第１の実施の形態と異なり、データセットの更新の有無等をタイムスタンプで判定しているのは、本実施の形態のような構成では、第１アクセス部１３によるデータ記憶部１１内のデータセットの更新を情報記憶部１６に即座に反映させることができないからである。
即ち、取得部１７は、情報記憶部１６から、着目するデータセットの管理情報のうち、前回のバックアップを実行したバックアップジョブのバージョン番号Ｄと、前回のバックアップの日時を示すタイムスタンプとを取得する(ステップ１３４)。そして、この情報も、決定部１８に受け渡す。
これにより、決定部１８は、ステップ１３３で取得したタイムスタンプとステップ１３４で取得したタイムスタンプとが等しいかどうかを判定する(ステップ１３５)。そのデータセットがまだ一度もバックアップされていない場合や、そのデータセットが前回のバックアップ後に更新された場合は、ステップ１３３で取得したタイムスタンプの方が新しくなっているはずである。そこで、ステップ１３５では、このような状態になっていないかを判定する。尚、第１の実施の形態と異なり、データセットの更新の有無等をタイムスタンプで判定しているのは、本実施の形態のような構成では、第１アクセス部１３によるデータ記憶部１１内のデータセットの更新を情報記憶部１６に即座に反映させることができないからである。
その結果、タイムスタンプが等しくなければ、上述したように、まだ一度もバックアップされていないか、前回のバックアップ後に更新されたかのいずれかであり、今回バックアップする必要があるので、着目するデータセットをデータ記憶部１１から読み出してバックアップメディア１５にコピーする(ステップ１３７)。具体的には、第１アクセス部１３がデータ記憶部１１から着目するデータセットを読み出して第２アクセス部１４に転送する。そして、第２アクセス部１４がそのデータセットをバックアップメディア１５に書き込む。また、その際、更新部１９は、情報記憶部１６に記憶された管理情報において、着目するデータセットに対して記憶されていたバージョン番号及びタイムスタンプを、それぞれ、今回のバックアップジョブのバージョン番号Ｍ及び今回のバックアップにおけるタイムスタンプに書き換える(ステップ１３８)。
一方、タイムスタンプが等しければ、バージョン番号Ｄがバージョン番号Ｎ以下であるかどうかを判定する(ステップ１３６)。
ここで、バージョン番号Ｄがバージョン番号Ｎ以下であれば、前回バックアップされたデータがもはや古くなっているので、新たにバックアップを行う必要がある。そこで、着目するデータセットをデータ記憶部１１から読み出してバックアップメディア１５にコピーする(ステップ１３７)。具体的には、第１アクセス部１３がデータ記憶部１１から着目するデータセットを読み出して第２アクセス部１４に転送する。そして、第２アクセス部１４がそのデータセットをバックアップメディア１５に書き込む。また、その際、更新部１９は、情報記憶部１６に記憶された管理情報において、着目するデータセットに対して記憶されていたバージョン番号及びタイムスタンプを、それぞれ、今回のバックアップジョブのバージョン番号Ｍ及び今回のバックアップにおけるタイムスタンプに書き換える(ステップ１３８)。
ここで、バージョン番号Ｄがバージョン番号Ｎ以下であれば、前回バックアップされたデータがもはや古くなっているので、新たにバックアップを行う必要がある。そこで、着目するデータセットをデータ記憶部１１から読み出してバックアップメディア１５にコピーする(ステップ１３７)。具体的には、第１アクセス部１３がデータ記憶部１１から着目するデータセットを読み出して第２アクセス部１４に転送する。そして、第２アクセス部１４がそのデータセットをバックアップメディア１５に書き込む。また、その際、更新部１９は、情報記憶部１６に記憶された管理情報において、着目するデータセットに対して記憶されていたバージョン番号及びタイムスタンプを、それぞれ、今回のバックアップジョブのバージョン番号Ｍ及び今回のバックアップにおけるタイムスタンプに書き換える(ステップ１３８)。
また、バージョン番号Ｄがバージョン番号Ｎよりも大きければ、バックアップは行わない。そして、バックアップが不要と判定された場合も、必要と判定された場合も、次のデータセットがあるかどうかを判定し(ステップ１３９)、次のデータセットがあれば、ステップ１３４へ進み、なければ処理を終了する。
次に、このようにしてバックアップしたデータセットを用いて、リストアを行う際の動作を説明する。
図１２は、このときの動作の流れを示したフローチャートである。
まず、取得部１７は、復元したい日に対応するバックアップジョブのバージョン番号Ｊを取得する(ステップ１４１)。次に、バージョン番号(Ｊ−Ｅ)のバックアップジョブからバージョン番号Ｊのバックアップジョブまでに使用したバックアップメディア１５の用意を促す(ステップ１４２)。尚、バージョン番号Ｊやバージョン番号(Ｊ−Ｅ)の取得方法は、第１の実施の形態と同様である。
図１２は、このときの動作の流れを示したフローチャートである。
まず、取得部１７は、復元したい日に対応するバックアップジョブのバージョン番号Ｊを取得する(ステップ１４１)。次に、バージョン番号(Ｊ−Ｅ)のバックアップジョブからバージョン番号Ｊのバックアップジョブまでに使用したバックアップメディア１５の用意を促す(ステップ１４２)。尚、バージョン番号Ｊやバージョン番号(Ｊ−Ｅ)の取得方法は、第１の実施の形態と同様である。
その後、バックアップメディア１５のバージョン番号をカウントするインデックスＬに初期値としてバージョン番号(Ｊ−Ｅ)を設定する(ステップ１４３)。そして、各バックアップメディア１５に対し、データの復元に関する処理を行う。
即ち、第２アクセス部１４は、バージョン番号Ｌのバックアップジョブにてバックアップしたデータセットを用いて、データを復元する(ステップ１４４)。具体的には、第２アクセス部１４がインデックスＬに対応するバックアップメディア１５からデータセットを読み出して第１アクセス部１３に転送する。そして、第１アクセス部１３がそのデータセットをデータ記憶部１１に書き込む。
即ち、第２アクセス部１４は、バージョン番号Ｌのバックアップジョブにてバックアップしたデータセットを用いて、データを復元する(ステップ１４４)。具体的には、第２アクセス部１４がインデックスＬに対応するバックアップメディア１５からデータセットを読み出して第１アクセス部１３に転送する。そして、第１アクセス部１３がそのデータセットをデータ記憶部１１に書き込む。
また、更新部１９は、情報記憶部１６に記憶された管理情報において、復元されたデータセットに対するバージョン番号としてバージョン番号Ｌを記憶し、リストアした日時をタイムスタンプとして記憶する(ステップ１４５)。
次いで、バージョン番号Ｌに１を加算し(ステップ１４６)、バージョン番号Ｌがバージョン番号Ｊ以下かどうかを判定する(ステップ１４７)。
ここで、バージョン番号Ｌがバージョン番号Ｊ以下であれば、ステップ１４４に戻り、バージョン番号Ｊを超えれば、処理を終了する。
次いで、バージョン番号Ｌに１を加算し(ステップ１４６)、バージョン番号Ｌがバージョン番号Ｊ以下かどうかを判定する(ステップ１４７)。
ここで、バージョン番号Ｌがバージョン番号Ｊ以下であれば、ステップ１４４に戻り、バージョン番号Ｊを超えれば、処理を終了する。
以上により、本発明の第２の実施の形態の動作を終了する。
尚、本実施の形態では、前回のバックアップから有効期限が経過しているかどうかをバックアップジョブの実行回数で判断することとし、この実行回数の判断には、バージョン番号を用いることとした。しかしながら、個々のバックアップジョブを識別可能な情報であれば、バージョン番号以外の情報を用いることとしてもよい。また、バックアップジョブの実行回数で判断するのではなく、文字通り、日付情報を用いて有効期限の経過を判断するようにしてもよい。
尚、本実施の形態では、前回のバックアップから有効期限が経過しているかどうかをバックアップジョブの実行回数で判断することとし、この実行回数の判断には、バージョン番号を用いることとした。しかしながら、個々のバックアップジョブを識別可能な情報であれば、バージョン番号以外の情報を用いることとしてもよい。また、バックアップジョブの実行回数で判断するのではなく、文字通り、日付情報を用いて有効期限の経過を判断するようにしてもよい。
また、本実施の形態では、前回のバックアップを行ったバックアップジョブのバージョン番号Ｄと、今回のバックアップジョブのバージョン番号Ｍから有効期限Ｅを減算した値Ｎとを比較し、ＤがＮ以下であれば、バックアップすることを決定するようにした。しかしながら、このような判断方法は、あくまで一例であり、いかなる方法を用いてもよい。例えば、バックアップしたデータセットに対し有効期限Ｅを記憶しておき、毎回のバックアップジョブの実行時にこの有効期限から１ずつ減算するようにしてもよい。このようにすれば、有効期限の値が０になったときに有効期限切れと判断することができる。
このように、本実施の形態では、バックアップデータに有効期限を付与し、毎回のバックアップジョブでは更新されたデータに加え有効期限切れのデータもバックアップするようにした。このような構成により、本実施の形態は、リストアに要する媒体の本数を所定の数以内に抑えつつ、毎回のバックアップに要する時間を短くし、かつ、均一にすることができるという効果を有する。
即ち、従来技術として述べた第１の手法の場合、２回目以降のバックアップジョブにおいては、バックアップ時間の短縮及び均一化はある程度可能であるが、バックアップメディアの数を所定数以内に抑えたいという要求に応えることはできない。また、第２及び第３の手法の場合、バックアップメディアの数はある程度抑えられるが、バックアップ時間の均一化の要求には応えられない。これに対し、本実施の形態の手法は、これら全ての要求に応えられるものである。
即ち、従来技術として述べた第１の手法の場合、２回目以降のバックアップジョブにおいては、バックアップ時間の短縮及び均一化はある程度可能であるが、バックアップメディアの数を所定数以内に抑えたいという要求に応えることはできない。また、第２及び第３の手法の場合、バックアップメディアの数はある程度抑えられるが、バックアップ時間の均一化の要求には応えられない。これに対し、本実施の形態の手法は、これら全ての要求に応えられるものである。
以上、本発明の第１及び第２の実施の形態について述べてきたが、ここで、情報記憶部１６に記憶された管理情報におけるデータセット番号とバージョン番号との対応が、具体的なバックアップジョブを実行することで、どのように変遷するかについて説明しておく。
図１３は、データセット＃１〜＃１２が図１に示したように更新される場合におけるデータセット番号とバージョン番号との対応関係の変遷を示した図である。図中、「ＤＳ−ＮＯ」がデータセット番号を示し、「Ｖ−ＮＯ」がバージョン番号を示している。また、ここでも、有効期限は７日とする。
まず、図１３(ａ)には、０日目のバックアップジョブを実行する前、つまり初期状態におけるデータセット番号とバージョン番号との対応関係を示している。このように、初期状態では、全てのデータセットについて、バージョン番号が存在せず、図６のステップ１０４での判定が「Ｎｏ」となるため、全バックアップが行われる。そして、図６のステップ１０７で、各データセットに対し、バージョン番号「０」が記憶される。尚、図１１では、タイムスタンプの比較により全バックアップを行うことが決定されるが、同図のステップ１３８で、各データセットに対し、バージョン番号「０」が記憶される。
図１３は、データセット＃１〜＃１２が図１に示したように更新される場合におけるデータセット番号とバージョン番号との対応関係の変遷を示した図である。図中、「ＤＳ−ＮＯ」がデータセット番号を示し、「Ｖ−ＮＯ」がバージョン番号を示している。また、ここでも、有効期限は７日とする。
まず、図１３(ａ)には、０日目のバックアップジョブを実行する前、つまり初期状態におけるデータセット番号とバージョン番号との対応関係を示している。このように、初期状態では、全てのデータセットについて、バージョン番号が存在せず、図６のステップ１０４での判定が「Ｎｏ」となるため、全バックアップが行われる。そして、図６のステップ１０７で、各データセットに対し、バージョン番号「０」が記憶される。尚、図１１では、タイムスタンプの比較により全バックアップを行うことが決定されるが、同図のステップ１３８で、各データセットに対し、バージョン番号「０」が記憶される。
また、図１３(ｂ)には、６日目のバックアップジョブを実行する前のデータセット番号とバージョン番号との対応関係を示している。
データセット＃１、＃３、＃５、＃７は、それぞれ、５日目、４日目、２日目、３日目のバックアップジョブでバックアップされているので、バージョン番号としては、それぞれ、「５」、「４」、「２」、「３」が記憶されている。
データセット＃２、＃４、＃６は、６日目に更新されているので、バージョン番号は消去されている。
データセット＃８〜＃１２は、０日目のバックアップジョブでバックアップされたままなので、バージョン番号は「０」のままになっている。
データセット＃１、＃３、＃５、＃７は、それぞれ、５日目、４日目、２日目、３日目のバックアップジョブでバックアップされているので、バージョン番号としては、それぞれ、「５」、「４」、「２」、「３」が記憶されている。
データセット＃２、＃４、＃６は、６日目に更新されているので、バージョン番号は消去されている。
データセット＃８〜＃１２は、０日目のバックアップジョブでバックアップされたままなので、バージョン番号は「０」のままになっている。
このような状態で６日目のバックアップジョブを実行すると、データセット＃２、＃４、＃６について、図６のステップ１０４での判定が「Ｎｏ」となるため、バックアップが行われる。そして、図６のステップ１０７で、これらのデータセットに対し、バージョン番号「６」が記憶される。尚、図１１では、タイムスタンプの比較により、データセット＃２、＃４、＃６についてバックアップを行うことが決定されるが、同図のステップ１３８で、これらのデータセットに対し、バージョン番号「６」が記憶される。
また、全てのデータセットについて、図６のステップ１０５や図１１のステップ１３６での判定は「Ｎｏ」となる。Ｎ＝Ｍ−Ｅ＝６−７＝−１となり、全てのデータセットに対して記憶されたバージョン番号はこの値以下とはならないからである。
また、全てのデータセットについて、図６のステップ１０５や図１１のステップ１３６での判定は「Ｎｏ」となる。Ｎ＝Ｍ−Ｅ＝６−７＝−１となり、全てのデータセットに対して記憶されたバージョン番号はこの値以下とはならないからである。
更に、図１３(ｃ)には、７日目のバックアップジョブを実行する前のデータセット番号とバージョン番号との対応関係を示している。
データセット＃１、＃２、＃３は、それぞれ、５日目、６日目、４日目のバックアップジョブでバックアップされているので、バージョン番号としては、それぞれ、「５」、「６」、「４」が記憶されている。
データセット＃４は、７日目に更新されているので、バージョン番号は消去されている。
データセット＃５、＃６、＃７は、それぞれ、２日目、６日目、３日目のバックアップジョブでバックアップされているので、バージョン番号としては、それぞれ、「２」、「６」、「３」が記憶されている。
データセット＃８〜＃１２は、０日目のバックアップジョブでバックアップされたままなので、バージョン番号は「０」のままになっている。
データセット＃１、＃２、＃３は、それぞれ、５日目、６日目、４日目のバックアップジョブでバックアップされているので、バージョン番号としては、それぞれ、「５」、「６」、「４」が記憶されている。
データセット＃４は、７日目に更新されているので、バージョン番号は消去されている。
データセット＃５、＃６、＃７は、それぞれ、２日目、６日目、３日目のバックアップジョブでバックアップされているので、バージョン番号としては、それぞれ、「２」、「６」、「３」が記憶されている。
データセット＃８〜＃１２は、０日目のバックアップジョブでバックアップされたままなので、バージョン番号は「０」のままになっている。
このような状態で７日目のバックアップジョブを実行すると、データセット＃４について、図６のステップ１０４での判定が「Ｎｏ」となるため、バックアップが行われる。そして、図６のステップ１０７で、データセット＃４に対し、バージョン番号「７」が記憶される。尚、図１１では、タイムスタンプの比較により、データセット＃４についてバックアップを行うことが決定されるが、同図のステップ１３８で、データセット＃４に対し、バージョン番号「７」が記憶される。
また、データセット＃８〜＃１２について、図６のステップ１０５や図１１のステップ１３６での判定が「Ｙｅｓ」となる。Ｎ＝Ｍ−Ｅ＝７−７＝０となり、データセット＃８〜＃１２に対して記憶されたバージョン番号がこの値以下となるからである。従って、データセット＃８〜＃１２については、バックアップが行われる。そして、図６のステップ１０７や図１１のステップ１３８で、これらのデータセットに対し、バージョン番号「７」が記憶される。
また、データセット＃８〜＃１２について、図６のステップ１０５や図１１のステップ１３６での判定が「Ｙｅｓ」となる。Ｎ＝Ｍ−Ｅ＝７−７＝０となり、データセット＃８〜＃１２に対して記憶されたバージョン番号がこの値以下となるからである。従って、データセット＃８〜＃１２については、バックアップが行われる。そして、図６のステップ１０７や図１１のステップ１３８で、これらのデータセットに対し、バージョン番号「７」が記憶される。
更にまた、図１３(ｄ)には、９日目のバックアップジョブを実行する前のデータセット番号とバージョン番号との対応関係を示している。
データセット＃１、＃２、＃３、＃４、＃５、＃６は、それぞれ、５日目、６日目、４日目、８日目、２日目、６日目のバックアップジョブでバックアップされているので、バージョン番号としては、それぞれ、「５」、「６」、「４」、「８」、「２」、「６」が記憶されている。
データセット＃７、＃１０は、９日目に更新されているので、バージョン番号は消去されている。
データセット＃８、＃９、＃１１、＃１２は、いずれも、７日目のバックアップジョブでバックアップされているので、バージョン番号としては、「７」が記憶されている。
データセット＃１、＃２、＃３、＃４、＃５、＃６は、それぞれ、５日目、６日目、４日目、８日目、２日目、６日目のバックアップジョブでバックアップされているので、バージョン番号としては、それぞれ、「５」、「６」、「４」、「８」、「２」、「６」が記憶されている。
データセット＃７、＃１０は、９日目に更新されているので、バージョン番号は消去されている。
データセット＃８、＃９、＃１１、＃１２は、いずれも、７日目のバックアップジョブでバックアップされているので、バージョン番号としては、「７」が記憶されている。
このような状態で９日目のバックアップジョブを実行すると、データセット＃７、＃１０について、図６のステップ１０４での判定が「Ｎｏ」となるため、バックアップが行われる。そして、図６のステップ１０７で、これらのデータセットに対し、バージョン番号「９」が記憶される。尚、図１１では、タイムスタンプの比較により、データセット＃７、＃１０についてバックアップを行うことが決定されるが、同図のステップ１３８で、これらのデータセットに対し、バージョン番号「９」が記憶される。
また、データセット＃５について、図６のステップ１０５や図１１のステップ１３６での判定が「Ｙｅｓ」となる。Ｎ＝Ｍ−Ｅ＝９−７＝２となり、データセット＃５に対して記憶されたバージョン番号がこの値以下となるからである。従って、データセット＃５については、バックアップが行われる。そして、図６のステップ１０７や図１１のステップ１３８で、データセット＃５に対し、バージョン番号「９」が記憶される。
また、データセット＃５について、図６のステップ１０５や図１１のステップ１３６での判定が「Ｙｅｓ」となる。Ｎ＝Ｍ−Ｅ＝９−７＝２となり、データセット＃５に対して記憶されたバージョン番号がこの値以下となるからである。従って、データセット＃５については、バックアップが行われる。そして、図６のステップ１０７や図１１のステップ１３８で、データセット＃５に対し、バージョン番号「９」が記憶される。
最後に、本実施の形態におけるシステムとして用いるのに好適なコンピュータのハードウェア構成について説明する。
図１４は、このようなコンピュータのハードウェア構成の例を模式的に示した図である。
図１４に示すコンピュータは、演算手段であるＣＰＵ(Central Processing Unit)１０ａと、Ｍ/Ｂ(マザーボード)チップセット１０ｂ及びＣＰＵバスを介してＣＰＵ１０ａに接続されたメインメモリ１０ｃと、同じくＭ/Ｂチップセット１０ｂ及びＡＧＰ(Accelerated Graphics Port)を介してＣＰＵ１０ａに接続されたビデオカード１０ｄとを備える。また、ＰＣＩ(Peripheral Component Interconnect)バスを介してＭ/Ｂチップセット１０ｂに接続された磁気ディスク装置(ＨＤＤ)１０ｅ及びネットワークインタフェース１０ｇを備える。更に、ＰＣＩバスとブリッジ回路１０ｆと低速なバスとを介してＭ/Ｂチップセット１０ｂに接続されたフレキシブルディスクドライブ１０ｈ及びキーボード/マウス１０ｉを備える。
図１４は、このようなコンピュータのハードウェア構成の例を模式的に示した図である。
図１４に示すコンピュータは、演算手段であるＣＰＵ(Central Processing Unit)１０ａと、Ｍ/Ｂ(マザーボード)チップセット１０ｂ及びＣＰＵバスを介してＣＰＵ１０ａに接続されたメインメモリ１０ｃと、同じくＭ/Ｂチップセット１０ｂ及びＡＧＰ(Accelerated Graphics Port)を介してＣＰＵ１０ａに接続されたビデオカード１０ｄとを備える。また、ＰＣＩ(Peripheral Component Interconnect)バスを介してＭ/Ｂチップセット１０ｂに接続された磁気ディスク装置(ＨＤＤ)１０ｅ及びネットワークインタフェース１０ｇを備える。更に、ＰＣＩバスとブリッジ回路１０ｆと低速なバスとを介してＭ/Ｂチップセット１０ｂに接続されたフレキシブルディスクドライブ１０ｈ及びキーボード/マウス１０ｉを備える。
尚、図１４は本実施の形態を実現するコンピュータのハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０ｄを設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０ａにてイメージデータを処理する構成としてもよいし、外部記憶装置として、ＡＴＡ(AT Attachment)やＳＣＳＩ(Small Computer System Interface)等のインタフェースを介してＣＤ−Ｒ(Compact Disc Recordable)やＤＶＤ−ＲＡＭ(Digital Versatile Disc Random Access Memory)のドライブを設けてもよい。
ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。
また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム(装置又は機器)、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ(ＲＡＭ)、リードオンリーメモリ(ＲＯＭ)、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ(ＣＤ−ＲＯＭ)、コンパクトディスク−リード/ライト(ＣＤ−Ｒ/Ｗ)及びＤＶＤが含まれる。
また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム(装置又は機器)、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ(ＲＡＭ)、リードオンリーメモリ(ＲＯＭ)、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ(ＣＤ−ＲＯＭ)、コンパクトディスク−リード/ライト(ＣＤ−Ｒ/Ｗ)及びＤＶＤが含まれる。
１１…データ記憶部、１２…ＡＰ、１３…第１アクセス部、１４…第２アクセス部、１５…バックアップメディア、１６…情報記憶部、１７…取得部、１８…決定部、１９…更新部
Claims (13)
- バックアップ対象のデータの全部又は一部を媒体にコピーするバックアップジョブを実行するシステムにおける装置であって、
前記データの部分と、当該部分を前記媒体にコピーしたときのバックアップジョブの識別情報との対応関係を有する管理情報を記憶する記憶部と、
前記バックアップジョブの識別情報を取得する取得部と、
前記バックアップジョブの識別情報に基づいて、予め決められた期間、前記媒体にコピーされていない前記データの部分を特定し、当該部分を当該媒体にコピーすることを決定する決定部と
を備えた、装置。 - 前記識別情報には、前記システムが前記データの全部又は一部に対して既に実行したバックアップジョブの実行回数の累積を表す番号であるバージョン番号が含まれており、
前記決定部は、前記予め決められた期間と前記バックアップジョブのバージョン番号に基づいて、予め決められた期間、前記媒体にコピーされていない前記データの部分を特定する、請求項１の装置。 - 前記決定部は、前回のバックアップジョブのバージョン番号に１を加算して得た今回のバックアップジョブのバージョン番号と、前記データの部分を前記媒体にコピーしたときのバックアップジョブのバージョン番号との差に基づいて当該データの部分を前記媒体にコピーするかどうかを決定する、請求項２の装置。
- 前記データの部分の更新に応じて、前記管理情報で当該部分に対応付けられた前記識別情報を消去する消去部を更に備え、
前記決定部は、前記バックアップジョブの識別情報に基づいて、予め決められた期間前記媒体にコピーされていない前記データの部分に加えて、前回のバックアップジョブ後に更新された当該データの部分も特定し、当該部分を当該媒体にコピーすることを決定するものであり、当該識別情報が消去されている場合に、当該識別情報に対応付けられた当該データの部分を当該媒体にコピーすることを決定する、請求項１の装置。 - 前記データの部分の更新に応じて、前記管理情報で当該部分に対応付けられた前記識別情報を所定の情報に変更する更新部を更に備え、
前記決定部は、前記バックアップジョブの識別情報に基づいて、予め決められた期間前記媒体にコピーされていない前記データの部分に加えて、前回のバックアップジョブ後に更新された当該データの部分も特定し、当該部分を当該媒体にコピーすることを決定するものであり、当該識別情報が前記所定の情報に変更されている場合に、当該識別情報に対応付けられた当該データの部分を当該媒体にコピーすることを決定する、請求項１の装置。 - 前記決定部は、予め決められた期間前記媒体にコピーされていない前記データの部分に加えて、更新された時刻が当該媒体にコピーされた時刻よりも新しい当該データの部分を特定し、当該部分を当該媒体にコピーすることを決定する、請求項１の装置。
- 前記媒体にコピーすることが決定された前記部分を、当該媒体に転送する転送部を更に備えた、請求項１の装置。
- コンピュータがバックアップ対象のデータの全部又は一部を媒体にコピーするバックアップジョブを実行するための方法であって、
前記コンピュータが、前記データの部分と、当該部分を前記媒体にコピーしたときのバックアップジョブの識別情報との対応関係を有する管理情報を記憶するステップと、
前記コンピュータが、前記バックアップジョブの識別情報を取得するステップと、
前記コンピュータが、前記バックアップジョブの識別情報に基づいて、予め決められた期間、前記媒体にコピーされていない前記データの部分を特定し、当該部分を当該媒体にコピーすることを決定するステップと、
を含む、方法。 - 前記識別情報には、前記コンピュータが前記データの全部又は一部に対して既に実行したバックアップジョブの実行回数の累積を表す番号であるバージョン番号が含まれており、
前記決定するステップでは、前記予め決められた期間と前記バックアップジョブのバージョン番号に基づいて、予め決められた期間、前記媒体にコピーされていない前記データの部分を特定する、請求項８の方法。 - 前記コンピュータが、前記データの部分が前回のバックアップジョブ以降に更新されたかどうかを判定するステップを更に含み、
前記決定するステップでは、前記データの部分が更新されたと判定された場合にも、当該データの部分を前記媒体にコピーすることを決定する、請求項８の方法。 - バックアップ対象のデータの全部又は一部を媒体にコピーするバックアップジョブを実行するシステムにおいて用いられるプログラムであって、
前記システムを構成するコンピュータに対し、
前記データの部分と、当該部分を前記媒体にコピーしたときのバックアップジョブの識別情報との対応関係を有する管理情報を記憶する機能と、
前記バックアップジョブの識別情報を取得する機能と、
前記バックアップジョブの識別情報に基づいて、予め決められた期間、前記媒体にコピーされていない前記データの部分を特定し、当該部分を当該媒体にコピーすることを決定する機能と
を実現させる、プログラム。 - 前記識別情報には、前記システムが前記データの全部又は一部に対して既に実行したバックアップジョブの実行回数の累積を表す番号であるバージョン番号が含まれており、
前記決定する機能では、前記予め決められた期間と前記バックアップジョブのバージョン番号に基づいて、予め決められた期間、前記媒体にコピーされていない前記データの部分を特定する、請求項１１のプログラム。 - 前記データの部分の更新に応じて、前記管理情報で当該部分に対応付けられた前記識別情報を消去する機能を更に実現させ、
前記決定する機能では、前記バックアップジョブの識別情報に基づいて、予め決められた期間前記媒体にコピーされていない前記データの部分に加えて、前回のバックアップジョブ後に更新された当該データの部分も特定し、当該部分を当該媒体にコピーすることを決定するものであり、当該識別情報が消去されている場合に、当該識別情報に対応付けられた当該データの部分を当該媒体にコピーすることを決定する、請求項１１のプログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006058259A JP4126706B2 (ja) | 2006-03-03 | 2006-03-03 | データバックアップのための装置、方法、及びプログラム |
| US11/703,423 US7549031B2 (en) | 2006-03-03 | 2007-02-06 | Method and apparatus for performing data backup |
| CNA2007100861477A CN101030156A (zh) | 2006-03-03 | 2007-03-02 | 用于数据备份的装置和方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006058259A JP4126706B2 (ja) | 2006-03-03 | 2006-03-03 | データバックアップのための装置、方法、及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2007233961A JP2007233961A (ja) | 2007-09-13 |
| JP4126706B2 true JP4126706B2 (ja) | 2008-07-30 |
Family
ID=38472711
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006058259A Expired - Fee Related JP4126706B2 (ja) | 2006-03-03 | 2006-03-03 | データバックアップのための装置、方法、及びプログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7549031B2 (ja) |
| JP (1) | JP4126706B2 (ja) |
| CN (1) | CN101030156A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0648808U (ja) * | 1992-12-14 | 1994-07-05 | 勝 鈴木 | 浴 槽 |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5213488B2 (ja) * | 2008-03-14 | 2013-06-19 | 日立コンピュータ機器株式会社 | バックアップシステム及び世代データ管理方法 |
| US20090307283A1 (en) * | 2008-06-04 | 2009-12-10 | International Business Machines Corporation | Dynamic backup window optimization apparatus and method |
| US9176825B2 (en) * | 2008-12-31 | 2015-11-03 | Symantec Corporation | Granular application data lifecycle sourcing from a single backup |
| CN101739310B (zh) * | 2009-12-10 | 2012-04-25 | 上海爱数软件有限公司 | 一种循环备份的方法及装置 |
| CN102346784A (zh) * | 2011-11-14 | 2012-02-08 | 苏州阔地网络科技有限公司 | 一种数据库备份的方法及系统 |
| JP6003610B2 (ja) | 2012-12-17 | 2016-10-05 | 日本電気株式会社 | 情報処理装置 |
| JP6004115B2 (ja) * | 2013-09-24 | 2016-10-05 | 富士通株式会社 | メモリ制御装置、情報処理装置、及びメモリ制御方法 |
| CN107528871B (zh) * | 2016-06-22 | 2020-05-26 | 伊姆西Ip控股有限责任公司 | 存储系统中的数据分析 |
| CN110784499B (zh) * | 2018-07-30 | 2021-08-20 | 华为技术有限公司 | 备份数据的方法和终端设备 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5454099A (en) * | 1989-07-25 | 1995-09-26 | International Business Machines Corporation | CPU implemented method for backing up modified data sets in non-volatile store for recovery in the event of CPU failure |
| JPH0644116A (ja) | 1990-12-04 | 1994-02-18 | Nec Corp | ディスクファイルセーブ管理方式 |
| JPH04253235A (ja) | 1991-01-29 | 1992-09-09 | Fuji Xerox Co Ltd | ファイルシステムのバックアップ方式 |
| JP2991871B2 (ja) | 1992-09-22 | 1999-12-20 | 住友ベークライト株式会社 | 水添ブロック共重合体エラストマー組成物 |
| JPH06250902A (ja) | 1993-02-24 | 1994-09-09 | Hitachi Ltd | 分散システムのファイルバックアップ方法 |
| JP3176232B2 (ja) | 1994-10-17 | 2001-06-11 | シャープ株式会社 | 用紙収容装置 |
| US6366987B1 (en) * | 1998-08-13 | 2002-04-02 | Emc Corporation | Computer data storage physical backup and logical restore |
| JP2001229297A (ja) | 1999-12-10 | 2001-08-24 | Sanyu Life Service Kk | インターネットを用いた葬儀システム |
| JP4074442B2 (ja) | 2001-03-30 | 2008-04-09 | 株式会社日立製作所 | データのバックアップのための方法、装置、システム、プログラム及び記憶媒体 |
| US7089383B2 (en) * | 2003-06-06 | 2006-08-08 | Hewlett-Packard Development Company, L.P. | State machine and system for data redundancy |
| JP4453323B2 (ja) | 2003-10-02 | 2010-04-21 | 株式会社日立製作所 | 複製データの管理方法、装置、及びプログラム |
| JP2005149285A (ja) | 2003-11-18 | 2005-06-09 | Nippon Telegr & Teleph Corp <Ntt> | 時系列データのバックアップ方法、システム、プログラム及び記憶媒体 |
-
2006
- 2006-03-03 JP JP2006058259A patent/JP4126706B2/ja not_active Expired - Fee Related
-
2007
- 2007-02-06 US US11/703,423 patent/US7549031B2/en not_active Expired - Fee Related
- 2007-03-02 CN CNA2007100861477A patent/CN101030156A/zh active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0648808U (ja) * | 1992-12-14 | 1994-07-05 | 勝 鈴木 | 浴 槽 |
Also Published As
| Publication number | Publication date |
|---|---|
| US7549031B2 (en) | 2009-06-16 |
| US20070208917A1 (en) | 2007-09-06 |
| CN101030156A (zh) | 2007-09-05 |
| JP2007233961A (ja) | 2007-09-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4126706B2 (ja) | データバックアップのための装置、方法、及びプログラム | |
| US8832029B2 (en) | Incremental virtual machine backup supporting migration | |
| JP4923016B2 (ja) | 仮想的データ長期保存処理技術 | |
| JP5346536B2 (ja) | 情報バックアップ／リストア処理装置、及び情報バックアップ／リストア処理システム | |
| US7444545B2 (en) | Computer system, managing computer and recovery management method | |
| JP5021929B2 (ja) | 計算機システム及びストレージシステムと管理計算機並びにバックアップ管理方法 | |
| JP6064608B2 (ja) | ストレージ装置、バックアッププログラム、およびバックアップ方法 | |
| JP2004258944A (ja) | ストレージ装置およびその管理方法 | |
| EP1637987A2 (en) | Operation environment associating data migration method | |
| US7007129B2 (en) | Tape management method by which a virtual tape file emulated on a disk drive is copied between disk drives | |
| US8229892B2 (en) | Storage apparatus and data restoring method used therein | |
| US10083087B1 (en) | Managing backup copies in cascaded data volumes | |
| CN106357703B (zh) | 集群切换方法与设备 | |
| JP2009064160A (ja) | 計算機システム、管理計算機及びデータ管理方法 | |
| US9336250B1 (en) | Systems and methods for efficiently backing up data | |
| KR20170002848A (ko) | 가비지 컬렉션 저널링 장치 및 방법 | |
| JP2008033527A (ja) | ストレージ装置、ディスク装置及びデータ復元方法 | |
| JP2010282586A (ja) | ファイル管理装置、ファイル管理方法、ファイル管理プログラム及び情報システム | |
| JP2012068891A (ja) | 階層型ストレージシステム及びデータアーカイブ方法 | |
| CN102354302B (zh) | 一种擦除磁盘的方法及装置 | |
| JP2010152781A (ja) | バックアップサーバ装置、バックアップ／リストアプログラム、およびバックアップ／リストア方法 | |
| US20060143423A1 (en) | Storage device, data processing method thereof, data processing program thereof, and data processing system | |
| JP5665518B2 (ja) | データベースシステム、その情報処理方法、およびそのプログラム | |
| JP3818130B2 (ja) | データ管理方法及び装置及びデータ管理プログラム及びデータ管理プログラムを格納した記憶媒体 | |
| JP5240086B2 (ja) | データ管理プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20071204 |
|
| A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20071227 |
|
| A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20080128 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080205 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080225 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080430 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20080501 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080502 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140523 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |