Office7の動作確認のついでに、新機能の「システムタスク」による「バックアップと最適化」と、それにより作成されたバックアップデータを使ったリストアを検証してみました。

なお、検証は VMware 上で稼動させた Red Hat Linux に Office7 の試用版をインストールした状態で行っています。
「作業の流れ」をみることを目的としていますので、実環境データを用いた所要時間や復元データの整合性等は検証外としています。
（あと、説明が大変なのである程度のLinuxの知識がある前提で書きます）

【参考URL：Office7 管理者マニュアル「データの保守（バックアップと最適化）」】
http://kantan.cybozu.co.jp/office7/...

まず、バックアップ用のディレクトリが必要のため保存先を作成しておきます。

> mkdir /home/backup # バックアップ用のディレクトリを作成する。
> chown apache /home/backup # httpd ユーザー（apache）が書き込めるようにする。

それと、システムタスクのスケジュールプロセスが起動しているか確認します。

> /etc/rc.d/init.d/ofss_cbag status
または
> ps -ef | grep sched

Office7 にログインして、「システム管理」の「システムタスク」から「システムタスクの一覧」を開きます。
最適化と合わせてバックアップができるため、ここでは「データベースの最適化」のみで設定を行っています。

システムタスク名の「データベースの最適化」を開いて、以下を設定します。（検証として設定した内容です）

（１） 繰り返し条件 ： 毎日
（２） 開始時刻 ： （検証の為、5分後とした）
（３） バックアップ ： 「最適化前にバックアップを実行する」をチェックする。
（４） バックアップ先 ： /home/backup
（５） バックアップ世代数 ： 5世代

このタスクを何度か実行したところ、/home/backup に「cbbackup（世代名）」のディレクトリが作成されました。
ちなみに「世代名」は、「yyyymmddhhmmss」形式ですね。

バックアップと最適化がうまく動いたところで、今度はリストアを試してみます。

冒頭でリンクした参考URLの指示に従い、上書きコピーしてみます。
（本当に「上書き」でいいのかは少し疑問ですが）

> /etc/rc.d/init.d/ofss_cbag stop # スケジュールを停止する。
> /etc/rc.d/init.d/httpd stop # httpd を停止する。
> cd /var/www/html/cbag/cb5 # 「cb5」ディレクトリに移動する。
> cp -fR /home/backup/cbbackup（最新の世代）/* . # バックアップデータを上書きコピーする。（アスタリスクとピリオドの見落しに注意！！）
> /etc/rc.d/init.d/httpd start

ここで正常にリストアされたか Office7 の動作とデータを確認します。
問題がなければ、忘れずに停止したスケジュールを戻しておきます。

> /etc/rc.d/init.d/ofss_cbag start

さて、はじめに言っておきますが、上記のリストア方法では問題がありました。
その問題について後述します。

リストア後、Office7 の動作には問題ありませんでしたが、再度タスクを実行したところログファイルに以下のエラーが書き込まれて実行できませんでした。

Error : Failed to copy, cannot open source [/var/www/html/cbag/cb5/data/address.odb.mrr] : cause[5]
Error : Failed to backup [/var/www/html/cbag/cb5/data/address.odb.mrr]
Error : Failed to copy datas

「address.odb.mrr って何？」と調べたところ、「.mrr ファイルは自動修復のためのファイル」みたいです。

詳しく調べたところ、.mrr ファイルは常に存在するファイルではないため、最適化中に作成される等の一時的なファイルのようです。
（検証環境では）これが3回に1、2回の頻度で同時にバックアップされていました。

ここで問題となるのは、.mrr ファイルは「data」ディレクトリ以下にあるファイルと同じ容量があります。
簡単に言ってしまうと、.mrr ファイルが含まれることで約2倍の容量でバックアップされてしまうということです。

まぁ、「バグかな？」とは思いつつ、あっさり話を進めますが。

エラーとなった原因は、/var/www/html/cbag/cb5/data には、.mrr ファイルが存在しない（一時的なファイルのため消える）ため、root 権限で cp コマンドを実行したことでファイルの所有者が apache ではなく root となっていたためでした。

そのため、上書きコピー時の作業を

> cp -fpR /home/backup/cbbackup（最新の世代）/* . # 「pオプション」を付ける

とすることでエラーはなくなります。（最初からこれを使うべきでしたが）

これで、検証は終わりですが、検証中に気になったので参考までに。

スケジュールプロセスの「sched」は、毎分で実行されているようで何もなくても「sched.log」に約47バイトの以下のようなログが書き込まれていました。

yy/mm/dd hh:mm:ss [0000] [N]: get events (0).

「sched.ini」をみるかぎり、ローテートはされるようですが、デフォルト（か、サイボウズさんの設定仕様かは分かりませんが）では、最大で約10Mバイトの容量となるようです。
「システムタスク」を「実行しない」としても、「sched」プロセスは停止されず毎分約47バイトづつログが書き込まれますので、そのままだと意味もない10Mバイトのログファイルが延々と書かれ続けるかもしれません。