2014-05-19

FileMaker IWP と SQL-Server 2000 によるソフトハウス用ライセンス販売管理システム

 ユーザに特定のブラウザを強制できない状況、不特定多数のユーザがアクセスする環境では WebDirect を使用できないため、IWP(インスタントWeb)が有用ですが、現状として WebDirect が限られたブラウザのみしかサポートしない状況で、IWP(またはその機能)の提供を打ち切っちゃう FileMaker ってなんなの……。

  さて、小社では自社ソフトウェアのユーザ管理用に Microsoft SQL-Server 2000(以下、Ms-sql)とASPをしたシステムを開発し長らく運用してきておりますが、1 年半ほど前にフロントエンド部を Active Server Page から FileMakerに 置き換えた、ということは以前、本Blogでご紹介いたしました。

 この前システムは10年以上ユーザ情報と製品サポートの記録用に運用してきましたが、昨年 5 月『売上猫くん Standard R5』をリリースしたのを機に一念発起し、ソフトウェアライセンスのWeb販売機能追加を含め、大幅に機能を拡張することにしました。


開発環境

MS SQL-Server 2000 (同左)
MS SQL-Server Management Studio Ver 9 (同左)
FileMaker Pro Server 12 Advanced (FileMaker Pro Server 11 Advanced)
FileMaker Pro 12 Advaned(FileMaker Pro 11 Advanced)
注:( )内は、前回開発時の環境

※なぜいまさらMs-sql 2000なのか?

な ぜ前世紀の遺物の Ms-sql 2000 を使い続けるのか?というと、FM が公式にはサポートしていないSQLデータソースを操作できるのか試してみたい、という好奇心からです。
 ちなみに、FM12 が公式にサポートしている Ms-sql は2005と2008のみ。 前回、Ms-sql 2000→2008 へのアップグレードは簡単にできることを確認していますので、問題が発生時したらアップグレードするつもりでしたが、現在まで問題なく運用できております。

注:FM13 が公式にサポートしている SQL データソースはこちらになりますが、例によって旧版 SQL データソースはいとも簡単にリストから外されているのであった……
 

FileMaker 13 でもはやサポートされなくなった IWP をいまさら使う理由は次のとおり。

  1. PHPに比べ非常に短期間で開発が可能
  2. 必要最低限の機能で満足できる(JavaScriptなどを使用したゴージャスなインタフェイスは要らない)
  3. ヘビーなトラフィックが発生しない
  4. 何かあればサーバを再起動できる程度の余裕がある
上記 1. が IWP 採用の最大のメリットで、今回の開発では30人日程でカットオーバーできました。

※なぜWebDirect(WD)ではないのか?

  1. ブラウザの互換性が低い(不特定多数がWebアクセスする環境では使えない)
  2. ハードウェア/ソフトウェアのコスト
WDは¥100万~数百万の投資が普通にできる企業がイントラネットで利用するってことで。


ライセンス販売管理システムの仕様

仕様は以下のとおり。

No AP 機能名 内容/仕様
1 FM カスタマ管理 カスタマ(顧客)管理、Webログイン用アカウント管理
2 FM ライセンス管理 ・複数ライセンス管理(同一カスタマが複数の製品を所有することを想定、メール/葉書等の重複送信を防ぐ)
・入金確認後、Webでカスタマが登録した情報を元に、ユーザ(ライセンス)情報の登録/更新を行う。同時に、製品情報(製品用パスワード)等を登録完了通知メールとして送信
3 FM メール送信 ユーザを検索し、対象ユーザにアップグレード等の情報を一括送信。
4 FM 送信文章管理 メールで送信する文章を作成。ここで登録した内容をEvaluateし、ユーザ/商品毎の変数を評価(例:本文中に表示する宛名やアカウント情報をユーザ毎に変更する)
5 FM 送信履歴管理 ユーザ毎にメール/葉書などの送信履歴を保存
6 FM 葉書 アドレスが無効または不明でメールが送信されなかったユーザに対し、葉書(表裏面)を印刷する
7 FM サポート管理 ・サポート期間、インシデント消費状況を管理
・サポート内容を記録
8 FM 商品管理 ・複数商品対応
・同一商品の複数種類対応(例えば、『売上猫くん Standard R5』には、シングルユーザ版、マルチユーザ版、開発版の3種類がある)
・シリアルNo(ライセンスNo)生成
9 Iwp ログイン カスタマ毎に登録してあるアカウント情報をもとに認証
10 Iwp ユーザ情報更新 ユーザ情報の登録/更新/チェック
11 Iwp アカウント情報更新 アカウント/パスワードの登録/更新/チェック
12 Iwp 商品選択・購入 ・新規購入とアップグレード購入の両方に対応
・アップグレードというソフトウェア特有の販売形態に関連した各種制御(所有ライセンス数に基づくアップグレード)
13 Iwp 確認メール 注文確定後、カスタマに対して確認メールを送信
注:AP列の「FM」はFileMaker Pro 12/13で、「Iwp」はWebブラウザ がIWPにアクセスして利用するの意。


主な画面

FM で本アプリを起動時に表示される初期メニュー。
 [ClientMode]で「1:IWP」を選択すると、それ以降はブラウザの動作をシミュレート、デバッグはFMで行う。
図1 FileMakerクライアントで表示されるMenu画面


 カスタマが Web で入力した情報を基に、カスタマ画面上の情報が更新・作成される。
 ライセンスの購入・アップグレード履歴は、「購入履歴」タブに表示される。
 住所/電話等の情報は変更されうるので、カスタマ側で最新の情報を、購入履歴では購入時点の情報(ピンク部分)を保持する。

図2 FileMaker クライアントで表示されるカスタマ画面 ― 購入履歴タブ


 「サポート履歴」タブでは行ったサポート内容を入力・記録する。尚、このタブを開くと、ライセンス付属のサポートの有効期限を表示したサポート状況ウインドウが表示される。


図3 FileMaker クライアントで表示されるカスタマ画面 ― サポート履歴タブ


 メールの送信文章を入力。[送信内容]はEvaluate()されるので、フィールド名や変数を指定可。

図4 FileMaker クライアントで表示される送信文入力画面


 今回の開発の肝はソフトウェアライセンスのショッピング機能。
 下図はそのまた肝の購入申込画面(FireFox使用時)。

 登録ユーザがブラウザを使用しログインすると本画面が表示され、カスタマ情報とともに所有する[現有ライセンス]が画面左下に、その右側にアップグレード可 能な商品情報が表示される。
 “カゴへ”をクリックすると、その商品が買い物カゴに入り、「買い物カゴ」タブが表示される。
 「新規購入」タブでは(アッ プグレードではない)購入可能な商品が表示される。必要に応じてアカウント情報を含む「お客様情報」欄の情報を更新し、商品を買い物カゴに入れて“確認 画面へ”をクリックすると、FMServerは入力情報をチェックしエラーがなければ確認画面を表示する。
 確認画面で“注文を確定する”をクリックする と、FMServerはカスタマ情報を更新するとともに、購入確認メールをユーザに対して送信する。
 なお、既存カスタマの場合、アカウント名/パスワードを 変更して“注文を確定する”と即座にデータベースに反映される。
 
図5 ブラウザに表示されるアップグレード・新規申込画面

 IWP と侮るなかれ。
 結構なモノが構築可能なのです。

以上

(土屋)

追記:
ショッピングモジュールに加え、 CRM(Customers Relationship Management)モジュールのユーザサポート機能を公開。詳しくはこちら


【IWP関連記事】

【IWP関連の製品・サービス】

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日)