SAP SQL Anywhere Tips – バックアップ方法の選択

はじめに

*今回はリクエストを受け作成した記事となります。こういうのを解説してほしいとかありましたらお気軽にリクエストいただければと思います。

SAP SQL Anywhere を運用する際にバックアップを行うことになる場合が殆どだと思います。この際にバックアップの方法をいくつか選択することが可能です。今回の記事はこの選択基準と注意点、運用についてまとめたものとなります。基本的にVer.9以降の全バージョンで活用できるようにまとめてみました。

バックアップの役割の変遷

バックアップは通常以下の役割があります。

• • 障害が発生した際にその前の時点の状態に復旧できるようにする

それに加え、昨今は以下の役割を要求されることもあります。

• • 特定時点のデータのスナップショットを見る

もし、後者の役割を要求されるというのであればバックアップの保存先容量の問題がありますのでそれを考慮に入れておく必要があります。

バックアップの種類

コマンドによる種類

SAP SQL Anywhereではバックアップコマンドは２種類あります。

• • dbbackupコマンド

OSのコマンドプロンプトからdbbackupコマンドを実行してバックアップを取得する方法です。タスクスケジューラー的なソフトウェアから実行する場合に向きます。

• • BACKUP DATABASE文

これはクライアントアプリケーションと同様にデータベースに接続し、そこでSQL文と同様に実行する手法です。バックアップを行うという動作もアプリケーション内に含めたい、管理を行うアプリケーションを別途作成しそこに含めるという場合に向きます。

バックアップコマンドは２種類ありますが、dbbackupでしか行えないバックアップ手法というのがいくつか存在します。但し大凡は両方で使用することが出来ます。また、バックアップしたファイル・バックアップ媒体の内部形式は変わりませんのでミックスして使用することも可能です。

論理的な種類

SAP SQL Anywhereにおいて「バックアップ」は論理的に2種、細かく3種あります。

• • フルバックアップ

データベースファイルとログファイルからなるそのバックアップ時点に完璧に復旧できるバックアップです。

dbbackupユーティリティはデータベースに接続する必要がありますので引数に接続文字列が必要となります。BACKUP DATABASE文はSQLと同様の手法で実行することから先にデータベースに接続している必要がありますので接続文字列は不要です。但し、SQL構文ですのでWindowsでディレクトリを示す「\」は「\\」と記述しなければならないことに注意してください。

• • インクリメンタルバックアップ

ログファイルだけのバックアップです。

• • • ライブバックアップ
      インクリメンタルバックアップの一形態で、ログファイルだけのバックアップを別のマシン上に継続的に取得するという方法です。別のマシンにログファイルのミラーをSQL Anywhereの機能で取得すると考えてください。

      ライブバックアップコマンド例： dbbackupの場合：（別のマシン上から実行） dbbackup -c <connection strings> <backup-dir> -l <logfilename> <backup-dir> : （別マシン上の)バックアップ先のディレクトリ -l : ライブバックアップの宣言 <logfilename> :  バックアップファイル名 dbbackup -c “HOST=myHost;SERVER=demo17;DBN=demo” “c:\temp\SQLAnybackup” -l “demo.log” BACKUP DATABASE文の場合： ライブバックアップは不可能です

      ライブバックアップは強力なインクリメンタルバックアップの取得形態です。ログの内容は2台のマシンで同期されています。仮にデータベースを動作させているマシンが破壊し、データが全て破壊された場合でもフルバックアップとライブバックアップを利用して最新のコミット時点までリカバリが可能です。インクリメンタルバックアップでは「バックアップを破壊されたマシン外に移動した」ことを前提とした場合、リカバリできるのは「そのインクリメンタルバックアップを取得した時点」までとなります。

インクリメンタルバックアップはログファイルだけのバックアップとなりますが、これは「増分バックアップ」です。「増えた分」だけですので、その「増える前」が無いとバックアップとして使用することが出来ないことに注意が必要です。

• 補足：ログを小さくする、切り替える

バックアップの際にログのトランケートを適宜行わないと前回バックアップしたログ内容を含みます。ログのトランケートを行うとそこで現行ログがクリアがされますので前回バックアップしたログの内容は含まれないことになります。

バックアップの際にログをトランケートすることで現在のログファイルの大きさを一旦小さく出来、結果としてバックアップを小さくすることが出来ます。これはバックアップ時間の短縮にも繋がります。デメリットとしては例えば上の図で④のバックアップ時点までリカバリする場合、トランケートしていない場合は④のログファイルだけあればよいのですが、トランケートした場合は①②③が揃っていないと④が適用出来ません。バックアップファイルを消失した場合を考慮するとトランケートはリスクになるとも言えます。（⇔トランケートしないとバックアップ時間がリスクです）

ログのトランケートはフルバックアップの際にもインクリメンタルバックアップの際にも行うことが出来ます。なお、ログのトランケートはデータベースミラーリング機構とMobile Linkシステムを使用する場合は行わないようにしてください。代わりに後述の「ログのリネーム」を使用するようにしてください。ログのトランケートを行うとデータベースミラーリングでは片肺運転からの復旧の際にデータベースリカバリが必要になる、Mobile Linkシステムではデータベースの同期が出来なくなることがあります。

• • フルバックアップ＋ログトランケート

フルバックアップの完了とともにデータベースは新しいログファイルを使用するようにします。

• • インクリメンタルバックアップ＋ログトランケート

インクリメンタルバックアップの完了とともにデータベースは新しいログファイルを使用するようにします。

ログにはトランケートではなくリネームというものもあります。リネームはトランケートと同様にバックアップを行い、その際にログのトランケートを行いますが、現行ログファイルをyyyymmddxx.logというファイル名（日付とカウント）でリネームし、現在のログが配置しているディレクトリに保持し、且つ現行のログと同じ名前で新しいログを開始します。これはデータベースミラーリングやMobile Linkシステムを使用する際に必須の選択肢となります。

• • フルバックアップ＋ログリネーム

フルバックアップの完了とともにデータベースは現行ログファイルをリネームし、新しいログファイルを使用するようにします。

• • インクリメンタルバックアップ＋ログリネーム

フルバックアップの完了とともにデータベースは現行ログファイルをリネームし、新しいログファイルを使用するようにします。

リネームを行う場合は現行のログファイルのディレクトリにリネームされたログファイルが残存することに気をつけてください。SAP SQL Anywhereはそれらを自動で削除しないので、何らかの方法で（古いものを）削除する必要があります。

トランケートやリネームの際に便利な機能があるので紹介します。上記で挙げたコマンド例群ではバックアップされるログファイルは現行で使用しているログのファイル名そのままでバックアップされます。ここで下記のオプションを付与すると

バックアップされるログのファイル名がリネームと同形式のyyyymmddxx.logというファイル名形式でバックアップされます。通常ではバックアップは元のデータベースファイルとログファイルの名称のまま保存されるのでバックアップしたファイルを適宜移動させないと上書きされてしまいます。これにより下記の状態が発生します。

この対策としては

• • バックアップ取得後に別のディレクトリに上書きされないよう管理して移動する。
  • バックアップ取得先を重複しないようにする。例えば
    dbbackup -c “HOST=myHost;SERVER=demo17;DBN=demo” -t -x “c:\temp\SQLAnybackup\yyyymmddhhmmss”
    のように取得日時を付けたディレクトリにバックアップするようにする。
  • -n・TRANSACTION LOG RENAME MATCHを付与してバックアップ先でのログファイル名をリネームする

が挙げられます。データベースファイルはリネームされないことに注意してください。リカバリ可能な最新日時にリカバリしたいという要件のみなら良いのですが、特定日時にリカバリしたい要件があると上書きされることでリカバリが出来なくなってしまいます。

物理的な種類

物理的に考えた場合は2種です。但し、現在ではほぼイメージバックアップしか使用されません。

• • イメージバックアップ

これはバックアップしたファイルがそのままデータベースファイル・ログファイルとして機能するバックアップです。大雑把に言うと、現在のデータベースのファイル・ログファイルのファイルコピーです。リカバリもこのファイルを元の場所に戻せばよいだけなので簡単です。なお、上記で挙げた例は全てイメージバックアップです。

• • アーカイブバックアップ

あまり使われなくなった形式で、本来はテープに対してバックアップデータを保存するものです。バックアップ対象が一つのファイルもしくはデバイスに対して保存されます。

実行形態による種類

データベース・サーバー側の状態による種類も存在します。

• • オンラインバックアップ

データベースがオンライン中に取得するバックアップです。これまで挙げたコマンド例は全てオンラインバックアップです。OSのコマンド・ツールにてオンライン中のデータベースファイル＆ログファイルのコピーを取ることはバックアップにはならないことに注意してください。*
*例外としてMicrosoft ボリュームシャドウコピーサービス (VSS) を使用した場合はバックアップ可能です。

• • オフラインバックアップ

データベースを正常に停止させた状態でOSコマンドでデータベースファイル＆ログファイルのコピーを取得することです。両方取得すればフルバックアップに相当します。異常停止状態でのコピーはバックアップになりません。理由は中身が破損している可能性があるからです。（破損した状態のデータベースファイルのコピーは役にたちません。）
現在は「夜間は止める」といった要件がない限り、日常で使用するバックアップとして選ばれることは無いかと思います。年に一度のシステムバックアップで結果として取得されるやSQL Anywhereアップグレード前の一時的なバックアップとして取得されるという使い方が殆どです。

バックアップ先による種類

バックアップをどこに行うか？も選択が可能です。

• • クライアント側バックアップ
    クライアントマシン上にバックアップを取得することです。このクライアントとは「バックアップ保存先のマシン」を意味します。クライアントマシンからバックアップコマンドを実行した場合、バックアップはクライアントマシン上に作成されます。

• • • dbbackupコマンドがこの形式に対応しています。
    • BACKUP DATABASE文はこの形式を使用できません。

• • サーバー側バックアップ
    サーバーマシン上にバックアップを取得することです。クライアントマシンからバックアップコマンドを実行した場合、バックアップはサーバーマシン上に作成されます。
    • dbbackupコマンドはこの形式に対応しています。
    • BACKUP DATABASE文はこの形式のみに対応しています。

但し、昨今はNFS等リモートマシンのディスクドライブを自マシンのドライブとしてマウントするという手法もあり、サーバー側バックアップでありながら実質リモート（クライアント）側にバックアップされるということになりますので、選択肢は増えている状態です。重要なのはバックアップ元と同じディスク上、マシン上、あるいは物理的な場所にバックアップを保管していることはリスクになり得るという認識です。可能な限り別のディスク、マシン、場所にバックアップを移動、あるいは取得するべきです。

注意：可用性との兼ね合い

バックアップは特定の日時のデータを確認するという用途を除き、障害から復旧する際に必要となるものです。その障害自体を避けるためにはディスクのミラーリング機能やSQL Anywhere自身のクラスタリング機能（ミラーリング）を用いることが可能です。これらを用いればディスクの故障が発生した際やマシン自体が故障した場合にサービスを続行できるのは確かですが、だからといってバックアップを減らす、不要になると考えるのは一考です。故障が発生し、ミラーリングやクラスタリングでサービスを継続出来たとしても、もう片方のディスクやマシンでサービスを継続したとしている最中に再度故障が発生するということも有りえるのです。このときはバックアップからの復旧が必要となります。可用性とバックアップは補完関係にあると考えてください。

これらのバックアップをどのように組み合わせて使用するか？そして本番環境ではどのように運用するかを考えなくてはなりません。

バックアップ運用のサンプル

ここで紹介するのはあくまで「たたき台」です。これをベースに要件を詰めていくという形で使用すると良いと思います。

サンプルの前提

• エンドユーザーはAM9;00からPM5:00が勤務時間
• PM12:00-1:00がランチタイム
• PM15:00-15:15に休憩時間
• PM10:00から日次の締めの夜間バッチが流れる
• AM3:00に他システムからのデータが連携（ロード）され、データ更新バッチが流れる
• 土日は基本休みだが、システムは稼働停止しない
• エンドユーザーはバックアップ専用のファイルサーバーがあり、そこにファイルを保存することが社内ルール。このファイルサーバのディスクはリモートディスクとしてデータベース・サーバーマシンにマウントすることが出来る。
• サーバマシンはRAIDディスク機能が有り、データベースファイルとログファイルはそのディスクに配置することが可能。

サンプル１：

サンプル１は最もシンプルな例です。１日１回フルバックアップを行い、業務が空く時間帯にバックアップを取得します。復旧可能な最新時点までリカバリするという要件のみであればフルバックアップ取得後前日のバックアップは全て削除することが出来ます。

サンプル２：

サンプル２はバックアップ容量も考慮した例です。サンプル１の場合何世代バックアップを保管するかにもよりますが、毎日フルバックアップを保管しておくのが難しい場合、あるいはグローバルなシステムでバックアップによるパフォーマンス低下を避けたい場合の例です。フルバックアップを週一回とし、インクリメンタルバックアップで補います。この場合、平日深夜のインクリメンタルインクリメンタルバックアップ＋ログトランケートは保管しておく必要がありますが、正常に取得した時点で前日の日中のインクリメンタルバックアップは削除出来ます。（深夜のバックアップに日中のインクリメンタルバックアップの内容が含まれています。）

まとめとポイント

RPO（目標復旧時点）を新しくするにはバックアップの頻度を上げる

RPO（目標復旧時点：バックアップから復旧した際に復旧できるデータの日時）を障害発生時点まで近づけたいのであればバックアップの頻度を高くする必要があります。そのバックアップを取得した時点がRPOとなるからです。一番頻度が高い形態が別マシンで常時インクリメンタルバックアップを取り続ける「ライブバックアップ」となります。

RTO（目標復旧時間）を短くするにはフルバックアップの頻度を上げる

バックアップからリカバリする際は、フルバックアップをリカバリするということが一番高速です。イメージバックアップであればバックアップしたデータベースファイルとログファイルを元の場所にコピーするだけで復旧出来ます。インクリメンタルバックアップがある場合はフルバックアップのリカバリ後にインクリメンタルバックアップの適用が必要です。これはインクリメンタルバックアップの量が多ければ多いほど時間が必要となります。フルバックアップの頻度が高ければ結果としてインクリメンタルバックアップの適用量が減りますのでRTOが短くなります。

ログのトランケートは適宜必要

ログは適宜トランケートを行わないとどんどん増大していきます。これはバックアップ時間・容量の増大を招きます。適宜トランケートが必要です。

「差分」「差分からの差分」を理解する

インクリメンタルバックアップは「差分」です。差分はその元が存在しないと役に立ちません。「差分からの差分」の場合はその前「差分」が無いと役に立ちません。つまり、差分の元となるバックアップは削除してはならず、「セット」として考える必要があります。バックアップを削除する場合はこれらを理解して削除してください。

バックアップファイルの管理は慎重に

バックアップファイルは通常現行のデータベースファイルとログファイルと同名でバックアップされます。上書きされてしまいますので管理が必要です。

いかがでしたでしょうか？バックアップは単純であれば管理も楽なのですが要件が重なると運用も難しくなります。ルールを決め、特にファイル管理、ファイルの削除は慎重に行うようにしてください。