VPS上のFileMaker ServerのバックアップをDropbox経由で取得する

#はじめに
最近はAWSを始めとしたクラウドサービスが充実していますので、FileMaker Serverをクラウドサービス上で展開する事例も増えています。

AWS EC2など、スナップショットをスケジューリングできるサービスであれば問題は少ないのですが、一部のVPSなどではスケジューリング機能が貧弱であったり、あるいは無かったりして、データベースのバックアップを取る環境が充分でないことがあります。

FileMaker Serverの標準機能ではバックアップを取る際に、保存先に選択できるのはローカルボリュームのみですので、VPSに接続できない障害が発生した時にバックアップが取得できない事故が発生する可能性があります。

このため、何らかの手段でVPS等のクラウドサービス外にバックアップを自動で取得する環境を構築する必要があります。

実際にこういった事例に遭遇し、対処法を構築したメモです。

#実現手法

予め、FileMaker ServerでVPSのディスク上に逐次バックアップを取るスケジュールを設定しておき、バックアップが取得できていることを確認します。用途や運用規模等によりますが、１日ごと：３０日分、１時間毎：２４時間分程度を目安に設定をしておけば障害発生時に困ることは少ないかと思います。後述するバッチファイルの運用上、それぞれ[everyday][everytime]と名付けたディレクトリ下に保存されるように設定します。

##Dropboxの使用

幸い、LAN内でファイルサーバーとして使用していたIODATAのNASには、[Dropboxのアカウントに接続できる機能](http://www.iodata.jp/ssp/nas/biznas/dropbox.htm)があったので

**VPS<->Dropbox<->LAN(NAS)**

という方法でバックアップを取ることにしました。Dropboxを経由することで、サーバー上でファイルの変更（追加／削除／更新）が発生した場合、随時NASとDropbox.comのクラウドに同期されるようになりますので、「VPS」「NAS」「クラウド」の３重バックアップが取れます。

NASにバックアップが同期されるので、「n日前のデータベースのレコードを参照する」必要がある際にリモート接続でVPSサーバーに接続してバックアップを持ってくる手間が省けます。何らかの検証時に大量のファイルを遡って参照する事態になった場合、ローカルネットワークにコピーが予め保存されているのといないのでは、ストレスの発生に大きく差が出ます。

また、NASが設置されているLAN側に固定IPやポート開放などの手間が必要ないので、セキュリティやコスト面でも利点があります。あと、何と言っても**2GBまでは無料である**という点は運用コストの面で大きな利点です。

Dropboxフォルダにバックアップの保存先を指定すればとりあえずの目的は果たせるのですが、問題はDropboxの無料枠の上限が2GBであるという点です。
2GBを超えた時点以降のファイルは同期の対象から外れるため、バックアップ漏れが発生することになります。

前述の「１日ごと：３０日分、１時間毎：２４時間分」を保存する場合、常時30*24=720ファイルが保存されてることになるので、１ファイルあたり2.5MB程度が上限ということになります。FileMakerのデータベースファイルはデータベースとレイアウト等のインターフェイスやスクリプト、それにデータベースの索引なども全て１ファイルに保存されますので、ファイル容量が大きくなりがちで、小規模なデータベースでも2.5MB程度はあっという間に超えてしまいがちです。また、Serverを運用していれば、複数のファイルをホストしているのが一般的ですので、１ファイルに許されるファイルサイズは更に少なくなるでしょう。

いずれにしても生のFileMakerデータベースファイルをDropbox（の無料枠）で保存するのは非現実的ですので、圧縮ファイルとして保存することにし、また、Dropboxフォルダへのバックアップのコピー作業は自動化したいところですので、タスクにバッチファイルを割り当てることにします。

##7zipで圧縮するバッチファイルを作成

圧縮形式にはいろいろ有りますが、

- 圧縮率が高いこと
- コマンドプロンプト（バッチファイル）から利用できること
- 無料であること

これらの条件を満たす形式として、[7zip](https://sevenzip.osdn.jp/)があります。7z形式で圧縮率を最大にしてfmp12ファイルを圧縮すると、大体10％～50％程度圧縮できる傾向にありますので、非常に強力です。

どうせバッチファイルを作成するならば、更新頻度が高くない割にファイル容量が大きいファイル（例：郵便番号マスタファイル）や、データベースのクローンなど、Dropboxで「毎日」「毎時」のバックアップを取るまでもないファイルは圧縮前に削除（ただし、最新版は常に保持する）したほうが容量削減につながりますので、次のようにバッチファイルを記述します。圧縮対象外のマスタファイル等は、サーバーにホストさせる際に[common]フォルダを作成し、そちらにホストさせるようにします。

```bat:everytime.bat
rem FileMaker Serverバックアップフォルダ（毎時）に移動
cd "C:\Program Files\FileMaker\FileMaker Server\Data\Backups\everytime"

rem クローンフォルダ(cloned) とマスタファイル等の入ったフォルダ(common）の内容をDropboxにコピー後、削除
for /R /D %%d in (cloned*) do xcopy "%%d" C:\Users\Administrator\Dropbox\cloned\ /S /Y /C /Q
for /R /D %%d in (cloned*) do rmdir /s /q "%%d"

for /R /D %%d in (common*) do xcopy "%%d" C:\Users\Administrator\Dropbox\common\ /S /Y /C /Q
for /R /D %%d in (common*) do rmdir /s /q "%%d"

rem すでに存在する*.7zファイルを削除
del /q *.7z

rem 直下にあるフォルダごとに7zファイルに圧縮
for /d %%X in (*) do 7z a "%%X.7z" "%%X\"  -mmt=on -mx=9

rem Dropboxフォルダに同期コピー
robocopy ./ C:\Users\Administrator\Dropbox\everyday\  *.7z /purge
```

```bat:everyday.bat
rem FileMaker Serverバックアップフォルダ（毎日）に移動
cd "C:\Program Files\FileMaker\FileMaker Server\Data\Backups\everyday"

rem クローンフォルダ(cloned) とマスタファイル等の入ったフォルダ(common）の内容をDropboxにコピー後、削除
for /R /D %%d in (cloned*) do rmdir /s /q "%%d"
for /R /D %%d in (common*) do rmdir /s /q "%%d"

rem すでに存在する*.7zファイルを削除
del /q *.7z

rem 直下にあるフォルダごとに7zファイルに圧縮
for /d %%X in (*) do 7z a "%%X.7z" "%%X\"  -mmt=on -mx=9

rem Dropboxフォルダに同期コピー
robocopy ./ C:\Users\Administrator\Dropbox\everyday\  *.7z /purge
```

２つのバッチファイル、「everyday.bat」「everytime.bat」を作成しました。その名の通り、「毎日」「毎時」のバックアップフォルダに対してコマンドを実行します。everytime.batのみxcopyを実行するfor文が入っています。これにより、[common][cloned]フォルダの最新の内容がDropboxに保存されます。また、[common][cloned]フォルダ削除後にディレクトリ単位で7zに圧縮し、robocopyでDropboxフォルダにコピーします。圧縮前に既存の7zファイルを削除し、robocopyコマンドのオプションに`/purge`を設定することで、FileMaker Serverで設定した世代と同一の7zファイルが保持されます。

この２つのバッチファイルをバックアップスケジュールと同様にタスクに割り当てることで、VPSが生きている限りLAN内のNASにバックアップが保存されますので、サーバー管理者の負担が軽減されます。