［メール・サーバー障害編］検証用のサーバーに切り替えタイムリミット回避！そして後日談：ITpro（情報元のブックマーク数）
ステージング用のサーバとかあんまり置かないと思いますが、重要なサーバの場合、開発→検証→本番とステージングを踏んで本番に持って行ったりしますね。障害時に検証サーバを本番に置き換えて使うってのもひとつの手ってことですね。
「ステージング（環境検証）用のサーバーに切り替えましょう」
［メール・サーバー障害編］検証用のサーバーに切り替えタイムリミット回避！そして後日談 | 日経 xTECH（クロステック）
私たちは責任者に提案した。
「ステージング用のサーバーであれば，障害が起こっているサーバーと環境が同じです。翌朝までに正常に稼働する可能性は高いでしょう。それに，昼ごろには障害が起こっているメール・サーバーのリストアが完了する予定ですが，リストアによってメール・サーバーが復旧する保証はありません」
このステージング用のサーバーを本番環境に適用し，タイムリミットである翌朝のバッチ処理の実行時刻になった。新しく接続したメール・サーバーは処理結果のメールを正常に受信し，監視担当者によっていつもの朝と同様に業務は進められていった。
IMAPを採用すると色々なところでメールが読めるし、WebMailでも一元管理が可能ですから便利ですよねぇ。
筆者らは改めてこのメール・サーバーの目的を考え，本当にIMAPが必要であるのか検討した。このメール・サーバーで最も重要な機能は，受信すべきメールを受信すべき時間に受信できることである。過去の受信メールを保持し続けることはそれほど重要ではない。関係者のヒアリングも行った上で，結局今回構築するメール・サーバーは，IMAPではなくPOP3を採用することになった。
［メール・サーバー障害編］検証用のサーバーに切り替えタイムリミット回避！そして後日談（2ページ目） | 日経 xTECH（クロステック）
メール・サーバーに大量のメールを残さないことでバックアップ対象データは少なくて済むため，リストアにかかる時間も短くなる。また，過去のメールは必要に応じて各監視用PCに残しておけば，メール・サーバー障害時にも過去のメールの復元に要する手間が必要なくなる。これらの対策によって，新たに策定されたバックアップ計画とリストア手順は，非常に簡便で作業に要する時間も短いものとなった。
