ラベル バックアップ の投稿を表示しています。 すべての投稿を表示
ラベル バックアップ の投稿を表示しています。 すべての投稿を表示

2022-01-24

正月休み明け、仮想マシン上の FileMaker Server 5.5 バックアップが失敗していた

 正月休み明け、Windows 2012 Hyper-V上のWindows 2008 で FileMaker Server 5.5(FMS) を運用している取引先から、「バックアップが失敗している」との連絡がありました。
仮想マシンの構成は以下の通りです。

■Windows 2008仮想マシン(VM)構成
[C:内臓VHD]
[E:内臓VHD]←FMSを実行
[F:外付VHD]←FMSのバックアップ先

 上記Fドライブの特定ディレクトリはReadできるのに、他のディレクトリはReadできず、Writeは全くできないという状況で、図の「I/Oデバイスエラーが発生したため、要求を実行できませんでした。」が出ます。


 そこでFドライブ(外付ディスク)にハード的問題があると思い、このドライブを取り外して別のPCに取り付けてチェックすると、普通にマウントできて、Read/Writeできました。


 気を取り直して、Hyper-V機に同じ外付けドライブを戻してもらい、Hyper-Vマネージャーで問題のVHDを一度取り外して、再度アタッチ。 これによりRead/Writeも、FMSバックアップも実行できるようになりました。

“削除”ボタンで問題のVHDを取り外し、“参照”ボタンで同VHDを再度アタッチ


 休みの前後、取引先でHyper-V機を落とすとき、外付けHDDの電源On/Offの順番を間違ったのが原因かもしれません。

 マシンを落とすときは外付けHDDを最後にOFF、起動するときは外付HDDを最初にON。


(NuckyT)

2015-12-11

iSCSI を利用したFileMaker Server の冗長構成を考える

 先日の記事で、FileMaker Server 14 オリジナルのスタンバイサーバ機能のテスト環境構築方法についてご紹介しましたが、このスタンバイサーバ機能には、以下のような問題点があります。

  1. プライマリからスタンバイサーバへの切り替えはコマンドライン入力が必要で面倒で、誤操作が発生する可能性がある
  2. 前回保存以降(0~99分間)のデータが失われる

 そこで今回は、上記のスタンバイサーバ機能の代わりに、プライマリ/スタンバイサーバでiSCSIディスクを共有するように設定し、障害時にはサーバ切替を行う冗長構成を考えてみました。

尚、本稿でもプライマリサーバの代替機という意味でスタンバイサーバという言葉を使用しています。 前稿のFileMaker Server 14 オリジナルのスタンバイサーバ機能と混乱しないようにご注意ください。


注意点:

 本記事でご紹介する操作は、動作を保証するものではありません。
 実運用前に社内で入念な動作検証を行い、お客様の責任で導入をお願いします。


 前回構築した仮想マシン二台を流用した iSCSI ドライブ共有モデルがこちらになります。
iSCSI ドライブの共有によるデータベース公開モデル
平常時はスタンバイサーバはiSCSIドライブには接続せず、プライマリサーバがダウンした時にのみ接続する
iSCSI ターゲットに配置されたデータベースファイルを FileMaker Server で公開することによって、緊急時にはスタンバイサーバから同じデータベースファイルにアクセスできるようにします。
 ※スタンバイサーバ側は、初回導入時にプライマリサーバと同様に iSCSI ドライブ内のデータベースを公開できるように設定します。設定後に iSCSI ドライブを切断するため、上図では接続状態を黄色の矢印で示してあります。

プライマリサーバの設定:

 iSCSIターゲット上でデータベース専用ドライブを作成し、プライマリサーバ上にマウントします(下図のEドライブ)。

 このとき、FileMaker Server 14 アプリケーションはCドライブにインストールし、データベースファイルはすべて iSCSI ドライブ(Eドライブ)に配置します。

 たとえば、下図のように iSCSI ドライブを E: ドライブとしてマウント。その中に FmData フォルダを作成して、この中に FileMaker データベースファイル群を配置します。



次に FileMaker Server Admin Console を使用し、上記で作成したデータフォルダが公開されるようにそのフォルダのパスを指定します。

 下図では、filewin:/E:/FmData/ が公開されるように設定しています。
 また、データベースファイル破損時に備えて、バックアップはローカルディスク上に取っておきます。




スタンバイサーバーの設定:

 プライマリサーバで iSCSI を切断し、FileMaker Server を停止させます。
 プライマリサーバの設定内容と同様にスタンバイサーバの設定を行います。

 ※ プライマリサーバの FileMaker Server の動作競合や、iSCSI ディスクへの書き込みエラーを防止するために、スタンバイサーバの設定が終わったら FileMaker Server を停止させて iSCSI 接続を切断しておきます。
 iSCSI の切断後は、スタンバイサーバをシャットダウンします。

正常時の操作


 普段はプライマリサーバのみ稼働させておきます。

プライマリサーバ稼働時の iSCSI 接続状態


緊急時の操作


 プライマリサーバのメンテナンスが必要になったり、プライマリサーバに障害が発生したりした場合は、FileMaker Server を停止させて iSCSI ドライブへの接続を切断します。

 そして、スタンバイサーバから iSCSI ドライブへ接続後に、FileMaker Server を起動します。

スタンバイサーバ稼働時の iSCSI 接続状態

ポイント:
 ― FileMaker Server 14 のサーバ切替コマンド操作が不要な分、サーバのダウンタイムは短縮できますが、プライマリサーバの iSCSI 切断、スタンバイサーバの iSCSI 接続と FileMaker Server 起動までの操作は手動作業になります。

 ― スタンバイサーバはプライマリで運用していたファイルを直接引き続くため復旧時にデータロスは発生しませんが、iSCSIターゲット(ディバイス)の堅牢性が要求されます。RAID6やRAID10などの採用を検討してください。

 ― FileMaker Server 14 以前の FileMaker Server にも応用できます。


とっても重要:

 フルバックアップ及びプログレッシブバックアップにより作成されるバックアップファイルは iSCSI ディスク上ではなく、ローカルディスク及び外部メディアに取ることをおすすめします。

 これにより、iSCSI ターゲット自体が故障した場合に、ローカルディスクにあるバックアップから復旧作業を行えます。
 また、ローカルディスクも同時に損傷しまった場合にも、外部メディアから復旧する手段が残ることになります。






(亀)



2015-12-09

Hyper-V VMを使用しFileMakerスタンバイサーバーのテスト環境を構築する


 FileMaker Server 14 でスタンバイサーバーが導入されたことにより、システムメンテナンス時や障害時にもすみやかに FileMaker データベース作業を再開できるようになりました。


 スタンバイサーバー - 概要


 プログレッシブバックアップを利用した現用系(プライマリ)と予備系(スタンバイ)のサーバ切替が可能になった分、突然のデータロスの可能性を低減できることは大きいと思います。

 しかしながら、切替制御が自動でないため、人為作業がどうしても発生してしまう点や、緊急時に FileMaker Server 管理者が対応不能の場合に作業が一時中断してしまう点などの問題は残りますので、緊急時の作業規則をあらかじめ社内で決めておくことが大切です。

 今回は、Windows OS で FileMaker Server 14 のスタンバイサーバー機能の動作検証を行いたい方のために、スタンバイサーバーのテスト環境を Hyper-V の仮想マシンを使って手っ取り早く構築する方法をご紹介します。

Hyper-V 上の仮想マシン(VM)のイメージ ― 1台のホストOS上で複数のVMを運用する

準備するもの

1. Hyper-V サービスがインストールされたコンピュータ 1 台
 今回は Windows Server 12 を使用しています。

2. FileMaker Server 14 が動作する Windows Server ライセンス 2 つ
 今回は Windows Server 2008 R2 を使用しています。

3. FileMaker Server 14 ライセンス 1 つ
 スタンバイサーバーを構成する場合、必要な FileMaker Server 14 のライセンスは1つのみです。

Hyper-V 環境の構築方法


1. 一台めの仮想マシンを作成してから仮想ハードディスクを接続します。
 その後、Windows Server OS と FileMaker Server 14 をインストールし、必要なデータベースファイルを Data/Databases ディレクトリの中に入れておきます。

新規仮想マシンと Windows Server OS および FileMaker Server 14 のインストール

ポイント:
 ― Windows Server の IP アドレスを正しく設定し、Windows 認証を済ませておきます。
 ― FileMaker Server 14 をインストールしたら、すぐにプログレッシブバックアップ設定をしておきます。



 このとき、プログレッシブバックアップ先のパス名の指定を忘れないようにしてください。
 上図では便宜的に filewin:/C/FMSProgBkup/ を指定してあります。

2. 一台めの仮想マシンをシャットダウンします。
そして、仮想マシンから仮想ハードディスクを削除(切断)します。

仮想マシンから仮想ハードディスクを切り離す

3. 仮想ハードディスク1 (VHD1) を複製して仮想ハードディスク2(VHD2=スタンバイサーバー用VHD)を作成します。
 Windows Server OS と FileMaker Server 14 がインストールされた状態の仮想ハードディスクを複製するため、インストール作業の二度手間を大幅に省くことができます

仮想ハードディスクを複製する

4. 一台めの仮想マシンに仮想ハードディスク1(VHD1)を再接続し、無事に起動してきたら、二台めの仮想マシンを新規作成し、仮想ハードディスク2(VHD2)を接続し、同様に起動します。

仮想マシンを新規作成して、二台の仮想マシンを稼働させる
ポイント:
 ― Active Directory に参加しているサーバを複製した場合は、二台めのサーバはドメインに参加できなくなります。
 このため、一旦ローカルログインし、IP アドレスの変更、コンピュータ名の変更、ワークグループへの切り替えを行ったあとで仮想マシンを再起動し、再度 ActiveDirectory に参加するようにする必要があります。

参考記事:ドメインにログインできなくなって泣かされる

 ― Windows OS は新たに仮想ハードディスクを接続すると、Windows 認証作業が必要になります。
  ボリュームライセンス利用者の場合は、「自動ライセンス認証が始まるまで XX 日です。今すぐ行う場合はここをクリックしてください」をクリックし、指示どおりに操作します。



 シングルライセンス利用者の場合は、「プロダクトキーの変更」をクリックして、二台めの Windows ライセンスを入力します。

 ― FileMaker Server 14 のプログレッシブバックアップの設定はプライマリサーバと共通になるので作業は不要です。FileMaker Server に付ける名前だけ変更すれば OK です。

FileMaker Server 14 スタンバイサーバーの設定方法


1. プライマリサーバの公開済データベースを全部閉じます。



 コマンドプロンプトから以下のコマンドを入力します。

fmsadmin standby connect スタンバイサーバーの名前または IP アドレス

 接続およびログインに成功すると、8桁のセットアップコードが表示され、待ち状態となります。
 このセットアップコードをメモしておきます。


2. スタンバイサーバー側でコマンドプロンプトを開き、以下のようにセットアップコードを入力します。

fmsadmin standby accept XXXXXXXX

ログイン成功後、スタンバイサーバー切替のメッセージが出るので y を選択後、ログインします。

3. プライマリサーバに戻り、待ち状態のコマンドプロンプトで Enter キーを押すとスタンバイサーバーへの接続が完了します。

ポイント:
 ― スタンバイサーバーでセットアップコードを入力して受理されたものの、セットアップコードが不正だった場合は Enter キーを押すとエラー終了になります。この場合は、手順 1. のコマンド入力からやり直してください。


4. プライマリサーバのコマンドプロンプトで、以下のコマンドを入力します。

fmsadmin standby update

 ログイン成功後、プライマリサーバのデータベースがスタンバイサーバーの公開データベース環境にコピーされます。


5. プライマリサーバのデータベースを再度公開します。


 すると、プライマリサーバとスタンバイサーバーのデータベース同期が行われるようになります。
 このとき、スタンバイサーバーの FileMaker Server Admin Console を開こうとすると、以下のように待機状態であることが確認できます。



 スタンバイサーバーのさらに詳しい設定方法および、スタンバイサーバーの動作確認方法(メンテナンス時、障害発生時のサーバ切替)は、FileMaker 社の公式動画がおすすめですので、ご覧になってみてください。



おまけ: FileMaker Server 14 プライマリサーバとスタンバイサーバの同期関係を解除する方法


 これまで、FileMaker Server 14 でプライマリサーバとスタンバイサーバーで同期が取れるように設定しましたが、逆に同期を解除したいという要望も出てくることでしょう。

 そのようなときは、プライマリサーバ側でコマンドプロンプトより以下のように切断コマンドを入力します。


fmsadmin standby disconnect

 本当にスタンバイサーバーを切断してよいかと聞いてきますので、y を選択し、ログインすると、スタンバイサーバーとの接続が切断されます。

 これにより、今までスタンバイサーバーだった FileMaker Server 14 はスタンドアロンサーバとして動作するようになります。

以上

(亀)

FileMaker バックアップ関連記事:

データベースのバックアップ方法
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方


Hyper-V 関連記事:

Hyper-V の仮想マシンの移行方法(エクスポート&インポート)
Hyper-V の仮想マシンのエクスポート時の注意点
物理マシンを Hyper-V 仮想マシンに移行する(P2V)
Hyper-V のゲスト OS を起動しようとすると、「一般のアクセスが拒否されました」というメッセージが表示される
計画停電対策(1) --- ノートPCサーバとHyper-Vで乗り切る


2014-05-15

FileMaker Server のプログレッシブバックアップ機能の考え方と使い方

通常バックアップとプログレッシブバックアップの違い


 FileMaker Server の通常バックアップ機能のしくみは、以下のとおりです。



 この場合は 8 時間おき、つまり一日 3 回、データベース全体がバックアップされます。
 この全体のバックアップを取ることをフルバックアップと呼びます。

 上記のように定期的にフルバックアップを取っておけば、たとえばバックアップ 1 を取り終えたあとに重大なデータベース障害が発生したとしても、データベースをバックアップ 1 の状態に戻せば業務を再開できます。

 ただし、この場合、バックアップは最長約 8 時間前の状態に戻ってしまいます。
 このうな場合はその約 8 時間分のデータベース作業を丸ごとやり直さなければならないことになります。

 一日の更新データ量が膨大になる業務の場合、この復旧作業は大変な労力と時間を費やすことになりますし、そもそもデータがもと通りになる保証はありません。
 かと言って、フルバックアップを1時間とか数分に1度実行するように設定すれば、パフォーマンスが低下することは明らかです。

 このような欠陥を補うため、FileMaker Server 12/13 にはプログレッシブバックアップ(Progressive Backup)という機能が搭載されています。

 プログレッシブバックアップを図解すると、次のようになります。



  プログレッシブバックアップでは、データベース全体ではなく更新分のみをバックアップします。これにより、短い時間でバックアップを終了するので、システムのパフォーマンス低下を短い時間に抑えます。上図の例では通常バックアップとは別に60 分おきにプログレッシブバックアップを行っています。


 データベースが損傷しデータベースがダウンした場合、プログレッシブバックアップにより最大 60 分前の状態に戻ってデータベース業務を再開できるようになります。

 ちなみに、プログレッシブバックアップの間隔は 1 分~99分の間で設定できます。


 それでは、プログレッシブバックアップの設定方法と動作確認、データベースの復旧方法について見ていくことにします。


 通常バックアップのスケジュールの考え方と設定方法については、以下の記事をご覧ください。
 前回の記事: データベースのバックアップ方法


本記事の内容は、当方の動作検証結果にもとづくものになっております。
プログレッシブバックアップ機能を検討されている場合は、事前に動作テストを十分に行い、お客様の自己責任で導入していただけますよう、お願いいたします。

プログレッシブ・バックアップの設定方法


 今回は、FileMaker Server 13 を使ったプログレッシブバックアップ機能をご紹介します。
 FileMaker Server 12 でも基本機能は同じですので、設定画面の情報を読み替えてご利用いただけると思います。

 FileMaker 社で公開されているプログレッシブバックアップの日本語ヘルプには誤訳が含まれているため、英語ヘルプをもとに解説していきます。

1.  FileMaker Server Admin Console にログインし、左ペインの「データベースサーバー」をクリックして「フォルダ」タブを選択します。

 そして、画面下部の「プログレッシブバックアップを有効にする」チェックボックスにチェックを付けると、次のようなメッセージが表示されます。



2. 「保存間隔」と、バックアップフォルダへの「パス」を指定します。

 社内の業務方針に応じて妥当な保存間隔を決定する必要がありますが、とりあえず今回は 60 分を設定しておきます。

 プログレッシブバックアップフォルダは、ここでは G: ドライブのバックアップ用フォルダへのパスを設定してみることにします。

 以下が、これらの条件を設定しおわったところです。



データベース運用中のディスクドライブと、プログレッシブバックアップ用のディスクドライブを分散させることにより、FileMaker Server のパフォーマンスが向上します。


3. “保存”ボタンをクリックした直後は、プログレッシブバックアップ用のフォルダには、以下の 3 つのフォルダが自動生成されます。


  • Changes_FMS ― 変更点が記述された .flx 形式のファイル
  • Copies_FMS ― 前回のプログレッシブバックアップ実行時点のデータベースのコピー
  • InProgress_FMS ― 蓄積された更新点が反映されるまで使用される暫定的なデータベースのコピー
重要:これらの 3 つのフォルダは、ユーザには直接無関係のフォルダとなりますので、中身を変更したり、消去したりしないようにしてください。

 設定後しばらくの間は、公開中のすべてのデータベースがこのプログレッシブバックアップ用フォルダの中にバックアップされますので、公開データベースの数や容量によっては、準備が整うまで時間がかかることがあります。


 InProgress_FMS フォルダは、初回のプログレッシブバックアップに成功すると消去され、その代わりに、タイムスタンプ付きの二種類のフォルダが生成されます。



FileMaker Server のプログレッシブバックアップでは、これらの二種類のバックアップコピーが生成されますので、必要に応じてどちらかの状態に復旧させることができます。


 上記では、スクリーンショットを撮る目的でバックアップの間隔を 1分に変更してフォルダを作成したために、05-15-14-37 と 05-15-14-38 という 1 分間の開きがあるフォルダが作成されていますが、間隔を 60 分にすれば、一時間の開きのあるフォルダが作成されることになります。


プログレッシブ・バックアップからのデータベース復旧方法

1. FileMaker Server Admin Console を使って、復旧させたいデータべ―スを閉じます。
 データベースの閉じ方は、以下の画像をご覧ください。



2. 1. で閉じたデータベースを消去します。



3. 前述の「プログレッシブバックアップの設定方法」の手順 3. で作成された、タイムスタンプ付きのフォルダのうち、復旧させたい時点のフォルダを開き、その中から対象となるデータベースファイルを特定して、FileMaker Server の公開データベースフォルダにコピーします。



 上記は、タイムスタンプが 2014-05-15-1511 のフォルダから、FMServer_Sample.fmp12 ファイルを特定したところです。


このフォルダは、定期的に FileMaker Server からアクセスされる性質のものですので、ファイルを特定したら、そのファイルをすぐにデータベースサーバの方にコピーしてください。

IncrementalBackup フォルダの中では、絶対に直接ファイルを開かないようにしてください。

4. 3. でデータベース公開用フォルダに配置したファイルを開きます。



 復旧操作は以上です。
 これによって、データベースファイルの状態が、2014-05-15-1511 時点でのプログレッシブバックアップ状態に戻りました。


【参照データのみ保存しているオブジェクトフィールドのデータはどうなるのか】

 英語版のヘルプによると、オブジェクトフィールドのデータ格納オプションより、「ファイルの参照データのみ保存」で参照先のみを保存している場合は、その実データは、タイムスタンプ付のフォルダの中に生成される RC_Data_FMS というサブフォルダの中にバックアップされるそうですが、当方の実験ではバックアップされていないようです。

 この点については、日を改めて検証したいと思います。


以上

(亀)



関連記事:
データベースのバックアップ方法


参考記事:
プログレッシブバックアップの設定とバックアップからの復元
Setting up, and restoring from, progressive backup (英語)



【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者:中級、5時間×1日)

2014-05-13

データベースのバックアップ方法


バックアップの重要性


 FileMakerにかぎらず、データベースを運用するうえで日々のバックアップ作業はとてもとても重要です。理由はデータベースが以下のような状況で破損するからです。

 データベースはいつかは必ず破損する!壊れる!ものと思ってバックアップ道に精進しましょう。

  • ユーザによる強制シャットダウン、システム稼働中の電源コード抜き
  • ハードディスクの寿命・故障
  • 電源障害、停電
  • 落雷、地震
  • 怪奇現象(なんの前触れもなく突然壊れる)

 戦略的、かつ定期的にバックアップを行うことにより、データベース破壊時にも最小限のコストで業務を再開できます。

※本稿で使用しているバックアップソフトウェアは FileMaker Server です。 


バックアップスケジュールの考え方


 データベースが破損すると、そのデータベースが関連するすべての社内業務はストップしてしまいます。
 このため、バックアップは最低毎日1回はお取り下さい。バックアップはデータベース管理に関わる者の責務です。

 バックアップがあれば、たとえば火曜日にデータベースが破損しても、月曜日のバックアップを使用し、月曜~火曜の間に更新したデータを再入力することにより業務を再開できるようになります。
 データの一部は再入力できないかもしれませんが、全データを失うよりは遥かにマシです。

 それでは以下の順に作業を進めていきます。


1. バックアップ用のディスクを用意します。

 FileMakerのデータベースファイルが保存されているディスクとは別の物理ディスクを用意してください。
 同一のディスクを使用すると、ディスクが物理的に破損したときにバックアップも一緒に破損してしまうからです。

 バックアップディスクには、外付のハードディスクを使用するのが良いと思いますが、 iSCSIドライブを使用するのも手です。iSCSIドライブであればサーバが起動できなくなっても、他のサーバでiSCSIディスクをマウントできます。 iSCSIドライブとスタンバイサーバがあれば、サーバがデータセンターにあるような場合、管理者はサーバ所在地に行かなくても復旧を行うことができます。

注:
  • FileMaker Serverスケジュールでは、NAS などのネットワークドライブにはバックアップを取れません。 
  • ネットワークドライブにバックアップを取るには、FileMaker Server でローカルディスクに一旦バックアップを行い、その後タスクスケジューラ等で NAS にバックアップを行うバッチを実行させると良いです。

 ここでは、外付けハードディスクにドライブレター F: を割り当てたものを想定します。


2. 日々のバックアップ戦略を考えます。

 バックアップを考えるにあたり、まず以下の2点を考えます。
  1. 頻度
  2. 上書 or 追記

 データ復旧性のことだけ考えるのであれば、1分に1回、常に追記する(以前のバックアップを上書きしない)のが最良でしょうが、頻繁なフルバックアップは実行速度の低下や停止を招きますし、また毎回追記していてはディスク等のバックアップメディアの費用もかかさみます。

 データ復旧性、システムパフォーマンスへの影響、金銭的コストなど、バックアップに関わる様々な事項を検討して、その企業における最適解を得るのがバックアップ戦略です。

 以下、バックアップ戦略の一例です。

  • バックアップは月曜日~日曜日まで毎日個別のバックアップ用ディレクトリに取る
  • 月曜~土曜は前週同曜日分を上書きバックアップする
  • 日曜日は永久保存用に 追記バックアップする(上書しない)


 これを1カ月の表にすると、次のようになります。

上書上書上書上書上書上書永久
上書上書上書上書上書上書永久
上書上書上書上書上書上書永久
上書上書上書上書上書上書永久



【日次バックアップのスケジュール】

 上記のバックアップ戦略に基づき、外付ディスク(F:)に月~土曜用のバックアップフォルダを作成します。



A. 手動による日次バックアップ


 FileMaker Server をお持ちでない方は、毎日の業務終了後に FileMaker データベースを完全に終了させてから、FileMaker データベースの入っているフォルダをそれぞれの正しいバックアップフォルダに正確にコピーしてください。


B. FileMaker Server を使った日次バックアップ

以下では、FileMaker Server 12 を使用し、これらフォルダに対して月~土曜用の上書きバックアップを設定していきます。

 スケジュールアシスタントの、1. タスクの選択~ 3. データベース選択までの操作はここでは省略しますが、業務に合った内容のものを選択してください。


1. たとえば、月曜日のバックアップフォルダ設定は次のとおりとなります。

FileMaker Server の仕様上、ネットワークドライブをバックアップ先に指定することはできません。

 一週間に一度上書きバックアップさせるため、フォルダに保持させるバックアップ数を 1 つに設定しているところに注目してください。



2. バックアップスケジュールを設定します。
 
 月曜日のフォルダに毎週バックアップさせるために、頻度を毎週にします。
 スケジュールは月曜日ですね。

 この例では、一日一回バックアップを取るようにしています。
 バックアップの開始時刻は業務条件によりますが、毎日の終業時間後に取るようにすると、翌日トラブルに見舞われてデータベースが使えなくなったときにも作業を再開しやすいかもしれません。


【応用編】

 日々大量のデータを扱う業務の場合は、朝、昼、晩と 3 回バックアップを取った方が、万が一のデータロスが少なくてすみますので、頻度を決めてバックアップを取るようにするとよいでしょう。
 たとえば以下のように設定すると、7 時間おきにバックアップを取るようにするため、一日で 3 回バックアップが実行されます。



 このような場合は、前の画面に戻り、バックアップの保持数を 3 に変更しておけば、朝、昼、晩と 3 種類のバックアップが 3 種類のフォルダに作成されます。


#ユーザから文句を言われたくなければ、システムがフル稼働する時間帯にバックアップを実行するのは止めましょう。 早朝、昼休、深夜、おやつの時間など、システムの稼働率が低い時間帯を見計らって、こっそりバックアップしましょう。


3. この要領で、月曜日~土曜日までの 6 日分のバックアップ設定をすると、以下のようなリストになります。




 これでバックアップスケジュールを有効にすれば、月~土曜の毎日、バックアップが定時に実行されるようになります。


【永久バックアップのスケジュール】

 日曜日のデータを永久バックアップする方法をご紹介します。

1. 永久バックアップ用には、月~土曜のバックアップディスク(F:)とは別に外部ハードディスクドライブ(または iSCISI)ディスクを用意し、ドライブレターに G: を割り当てました。

 月~土曜と日曜日のバックアップで、2つの外部ディスクを用意するのは、ディスク障害のリスクを分散するためです。


2. G: ドライブの中に日曜日永久バックアップ用のフォルダを一つ作成します。
 たとえば、以下のようになります。



A. 手動による永久バックアップ


 FileMaker Server をお持ちでない方は、日曜日の業務終了後に FileMaker データベースを完全に終了させてから、FileMaker データベースの入っているフォルダを永久バックアップ用のドライブ(例: G: ドライブ)の正しい永久バックアップフォルダに正確にコピーし、フォルダ名に日付を追加してください(例:俺のバックアップ150706、俺のバックアップ150713、俺のバックアップ150720.…)。

 このようにすることにより、日曜日の日付のついたバックアップフォルダを、ディスク容量が一杯になるまで永続的に蓄積していきます。

B. FileMaker Server を使った永久バックアップ


 次に、Windows 版の FileMaker Server 12 を使ってバックアップスケジュールを設定する方法をご紹介します。

スケジュールアシスタントの、1. タスクの選択~ 3. データベース選択までの操作はここでは省略しますが、業務に合った内容のものを選択してください。


1. 日曜日の永久バックアップフォルダ設定は、たとえば次のとおりとなります。

FileMaker Server の仕様上、ネットワークドライブをバックアップ先に指定することはできません。


 バックアップフォルダが G: ドライブの 7日(永久)になっていますね。
 また、永久バックアップは追記型で増やしていきますので、「保持するバックアップの最大値」を最大の 99 に設定します。




 これにより、99 個のバックアップまでは追記型でバックアップフォルダが自動生成されます。

追記できるのが 99 回までなら、その後はどうすんの?

 100回目以降は古いバックアップフォルダから順次上書きされてしまいますから、99 週≒約 2 年を一区切りとして、その後はどうするのか検討しておく必要があります。

 99週を過ぎると、古いバックアップフォルダから順に上書きされていきますから、当然上書きされた分は使用できなくなります。
 そのときは、バックアップディレクトリを変更するか、ハードディスクを交換します。

 ハードディスクは2年壊れず使えればラッキー!と考え、99回を区切りに新しいものに交換するのは、とても良いと思います。


ディスク容量とデータ増も考慮せよ

 データベースの容量は把握していますか?
 1月にデータがどのくらい増えるか把握していますか?
 そのハードディスクで2年間、週1回の追記バックアップ99回分を保持できますか?



2. バックアップスケジュールを設定します。

 スケジュールの指定方法は、日次バックアップと同様ですが、バックアップの頻度は 1 回にします。
 これにより、日曜日(永久)のバックアップは、一週間に一度追記作成されるようになります。


C. FileMaker Server と外部プログラムを併用した永久バックアップ


 FileMaker Server によって毎週作成される日曜日のバックアップフォルダを、外部メディアやネットワークディレクトリに自動コピーするには、以下の方法があります。

  •  指定フォルダをバックアップできるソフトウェアを使い、毎週日曜日の深夜に外部メディアに追記型で世代管理できるようにスケジュールを組む。
  •  コマンドバッチファイル、vbs などのスクリプトを使って永久バックアップフォルダの外部メディアへのコピー条件を指定し、タスクスケジューラに登録して毎週日曜日の深夜に実行されるように設定する。


最後に… 上記で管理者のバックアップは作業は終わりでしょうか? とんでもありません。 管理者は1日1回、設定したバックアップスケジュールが正しく実行されているかどうか、FileMaker Server のコンソール画面等で確認してください。 また、週に一度位は、作成されたバックアップが実際に起動できるか試してみてください。 この確認作業は、バックアップ戦略策定や設定作業以上に重要です。 なぜって、バックアップが実際にできていなければ、立派なバックアップ戦略も無意味ですから。


(亀)


<おまけ> 地震、雷、火事、オヤジ、太陽フレアは?

 建物が被雷した場合、電源の入っているすべてのハードディスクやストレージデバイスが破壊される可能性があります。
 地震、火事、テロではオフィス内のすべてのディスク、オフラインのメディアも焼失/消失する可能性があります。

 定期的にクラウドなどの遠隔地のストレージへのバックアップや、支店支社・銀行貸金庫へのデータの保管を検討してください。

 少し前になりますが、大規模な太陽フレアが起こる、との風説があり(NASAも言っていたので風説ではないかも)、筆者も結構マジメに悩んだことがあります。
 調べてみると、他にも悩んでる人はいました。
 太陽フレア対策として、週に1度、ディスクやメディアにバックアップして、それを電磁波シールド袋で包み金庫に保管とか、本気で考えてる人もいます。

 まぁ、そいつの出番が来る時は、業務継続以前に、現代文明全体が危機に陥っていると思いますが……


関連記事:
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方


【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者:中級、5時間×1日)