[データベース編]バックアップ設計を先にしてはいけない:ITpro

リカバリを考えてバックアップを設計しましょうというお話。

データベース全体のバックアップを取得するフルバックアップ(コールド・バックアップ,あるいはオフライン・バックアップともいう)を夜間バッチで取っているシステムは多いだろう。フルバックアップでリカバリできるのはバックアップを取得した時点までである。フルバックアップはデータベースを停止した状態で取得するため,これを使って障害発生ポイントの直前までリカバリすることはできない。
つまり,業務要件としてデータの欠損が許容できない場合には,このバックアップでは意味がない。この点をカバーするにはアーカイブ運用をしてオンライン・バックアップを取得するといったことが必要となる。これをフルバックアップに組み合わせれば,障害発生ポイントの直前までリカバリすることが可能となる。

2GBの壁ってやつですね、LargeFileSystemのやつですね。そういえば、あったなぁ・・・そんなこと。

最近聞かないけど

最近はあまり聞かなくなったが,一昔前の32ビットOSではファイル・システムが扱えるサイズの最大値は2Gバイトが相場だった。データベースの設計の際に,データ・ファイルが2Gバイトを超えないように設計するのが当たり前の世界だった。
その際,リカバリの設計を行っていないシステムだと,論理バックアップ(データベースのデータを外部ファイルとしてエクスポートする)を取得するバックアップ・セットがデータの増大と共に2Gバイトを超えてしまうことがある。この段階でファイルが壊れてしまう。バックアップ・セットが2Gバイトを超えてしまったことに気づかず,いざリカバリを実施しようとしたところで,ファイルが壊れていたことに気づくのである。

screenshot