June 24, 2016

DAOS環境でのBackupからのMail復元時の注意点

テーマ:Technique
皆さんの環境でも、添付ファイルの容量削減効果があるからと、DAOS(Domino Attachment Object Store)を利用されている場合もあるのではないかと思います。

昔あったSCOS(Single Copy Object Storeでしたっけ?)も同じような仕組みです。

ファイル容量の削減に貢献し、Diskの節約が出来るのは良いことなのですが、これにより逆に運用が複雑になります。

DAOSに至っては、SCOS時代に比べTransaction Loggingを有効にしなければならないことは皆さんご存知の通りです。

DAOSやSCOSを使わない環境であれば、Backup ToolでBackupされたDBを単純にClientやTest ServerなどにRestoreして、内容を確認することができますが、DAOSやSCOSを使った環境ではそうはいきません。

運用上、良くあるのが、Mail文書を消してしまったので、Backupから元に戻して欲しいというUserの我儘です。
Soft Deletionが有効になっている環境であれば、Defaultで48時間以内であればUserでも元に戻すことが出来るのですが、そういうUserに限って何も考えずにゴミ箱を空にしてしまったりしています。
Mail DBがQuotaに達して、Mailが送信できなくなり、必死でMail DBの整理をしていたのだろうというのは良くわかりますが、作業は落ち着いてやって欲しいものです。
中には、昨日Mailの整理をしていたが、間違えてその日に来た新着Mailを消してしまったから戻して欲しいという要求もありますが、運用で取得しているBackupは夜間に1回なので、当日に当日のMailを削除したのを戻してくれと言われても無理な訳です。

少し話がそれましたが、こういうBackupからMailを戻して欲しいというUserの要望があった場合、通常の環境ならいとも簡単なのですが、DAOS/SCOS環境はそうではないのです。

SCOSは今は使われていないので、DAOS環境に絞ってお話ししましょう。

DAOS環境の場合、Mail DBとDAOSの添付ファイルのフォルダー(File System)は別で、別々にBackupされています。
Mail DBの文書内の添付ファイルは、DAOSに保管されたFileへのPointer情報を持っているだけですので、Mail DBだけをNotes Clientや別のServerにRestoreしても、Mail文書を開く際にDAOSに格納された添付ファイルが参照できないため、文書が開けない状態になるのです。
DAOSに格納されたAttachment Objectが削除されていない前提であれば、元DBのあったServerにRestoreすれば正常に文書が開けます。
DAOSからAttachment Object自体が無くなっていた場合は、もっと面倒なことになります。

では、ここではDAOSにAttachment Objectが残っていた場合(比較的簡単な場合)を考えてみましょう。

BackupからMail DBを元のDBに配置しないと、DAOSに格納されたObjectが参照できない訳ですから、本番のDBとBackupから戻したDBが同一Server上に同居することになります。

賢明な皆さんなら、直ぐに気が付くと思いますが、DominoはDBをReplica IDで同一の物と判断している関係上、同一Server上に同一Replica IDのDBが存在すると何が起こるか分からないのです。
他のServerとReplicaやCluster Replicaを行っている環境では、同じReplica IDのDBがServer上に存在すると、どちらのDBとReplicaするか分からない状態になります。
実際にやってみると分かりますが、OS CopyでServerに戻した後、DominoがそのDBを握り、Replicaを行ったことがReplication Historyから確認できるでしょう。

では、このような場合、どうすれば良いのでしょうか?

先ずは、BackupからDomino配下以外のWork領域にRestoreしたDBをNotes ClientのData領域にOS Copyして、Replication Settingを変更し、一時的にReplicaを禁止する設定を行うことです。
これで、Replicationは行えなくなります。
次に、Notes Clientも環境によってはReplicationをしている場合がありますので、この時点でDesktopのDB ICONやReplica Entryがあれば消してしまい、DB自体をNotes ClientのData Folder以外に退避することです。
そのあとで、このMail DBが元あったServerの本番のMail DBが入ったFolderとは別のFolderにOS Copyで配置します。
この時点で、load fixupでOS Copyで戻したMail DBをFixupしておくのが良いでしょう。
これでやっとServerに戻すことができ、Notes ClientからAccessして必要なMail文書をCopyして本番のMail DBにCopyした後にBackupから戻したMail DBを削除すれば作業が完了する訳です。

DAOSが有効になっていない場合と比べると、かなり煩雑な操作になることがお分かり頂けるでしょう。

更に、これはDAOSが有効な環境に限ったことではありませんが、Soft Deletionが有効になった環境で、Userさんから、数日前に文書を削除したのだが、今日ゴミ箱を空にしてしまったが、必要なMail文書があったので、戻したいという要望があった場合です。
Mail文書を削除した日が分かっていれば、Defaultではその日時から48時間はゴミ箱に残っているハズなので、Mail文書した日の夜間に取得されたBackup FileをRestoreすれば良いわけです。
ところが、文書を削除してからSoft Deletion有効期限(Defaultで48時間)以上経ったMail DBをServerに戻すと、確認するまでにゴミ箱の文書が削除されてしまう可能性が高いです。
これも困る訳ですが、もう1日前を戻せば良いという意見もあるかもしれませんが、削除したMailが削除した日に届いていた場合、ゴミ箱から復活させるしか方法はないのです。
この場合は、BackupをNotes ClientにOS Copyしてから、DB PropertyのSoft Deletionの有効期限を目いっぱい伸ばした後で処理する必要があります。
DAOSが有効な環境では、Backupを戻す先が元のServerに限られるため、DAOSが無効な環境よりも面倒なことになることは確かです。

こうやって考えていくと、Diskを節約しようとかという考えを捨てた方が賢明かも知れない訳です。
今時、Diskはかなり安価になっている訳で、運用を複雑にしてミスを招きかねない運用をすると、運用コストが上がり、人件費が一番高いという状態にもなりかねないのです。

単に目先のことだけを考えず、総合的に考えて機能を導入するかどうかを判断すべきだと思います。
 
いいね!した人  |  コメント(0)  |  リブログ(0)

いわまんさんの読者になろう

ブログの更新情報が受け取れて、アクセスが簡単になります

最近の画像つき記事
 もっと見る >>

コメント

[コメントをする]

コメント投稿

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。