Dovecot で IMAP の INBOX が空に見える場合、最初に確認すべきなのは、メールファイルそのものが消えたのか、それとも Dovecot のインデックスやキャッシュの不整合で見えなくなっているのかです。ここを分けずに作業すると、復旧操作と破壊的な削除操作を取り違えやすくなります。
Maildir 形式では、メールの実体は cur/ や new/ 配下のファイルとして残ります。一方で、Dovecot は IMAP の UID、フラグ、一覧表示、検索などを扱うためにインデックスを持ちます。そのため、Maildir の実体が残っていても、Dovecot 側の認識が壊れると INBOX が空に見えることがあります。
この記事では、Dovecot で INBOX が空に見える時に、Maildir、Dovecot index、doveadm force-resync の関係を整理し、どの順番で確認して復旧するかをまとめます。
書籍
Postfix 詳解 MTA の理解とメールサーバーの構築・運用
Postfix を中心にメールサーバーの構築と運用を確認したい場合の参考書籍です。Dovecot と組み合わせたメール基盤を理解する補助として使えます。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
症状を分けて見る
今回のような事象では、メールクライアントから見ると INBOX が空に見えます。しかし、サブフォルダは正常に見える、配送は続いている、Maildir 配下にメールファイルが残っている、という状態であれば、メールデータ全体の消失とは限りません。
- IMAP クライアントでは INBOX が空に見える
- サブフォルダは正常に表示される
- Maildir の
cur/やnew/にはメールファイルが残っている - Postfix などからの配送は止まっていない
- Webmail、別クライアント、
doveadmの見え方が食い違う
この時点で重要なのは、メール実体、Dovecot の認識、IMAP クライアント側のキャッシュを分けることです。INBOX が空に見えるという現象だけで、すぐに Maildir を削除したり、メールボックスを作り直したりするべきではありません。
Maildir と Dovecot index の関係
Maildir は、メールを 1 通 1 ファイルとして保存する形式です。一般的には tmp/、new/、cur/ というディレクトリを持ち、配送直後のメールや既読扱いのメールがファイルとして置かれます。
Dovecot は、そのメール実体を直接毎回読み直すだけではありません。IMAP で効率よく一覧表示し、UID やフラグを扱うために、dovecot.index、dovecot.index.cache、dovecot.index.log、dovecot-uidlist などのメタデータを使います。
| 要素 | 役割 | 確認する意味 |
|---|---|---|
Maildir の cur/ / new/ | メール実体 | ここにメールが残っていれば、少なくともファイルとしての実体は残っている |
dovecot-uidlist | IMAP UID と Maildir ファイル名の対応 | UID の不整合や再同期時の見え方に関係する |
dovecot.index | メールボックスのインデックス | 一覧表示や状態管理に使われる |
dovecot.index.cache | キャッシュ情報 | 破損しても再構築できる場合がある |
dovecot.index.log | インデックス更新ログ | インデックス更新の履歴に関係する |
実務上は、Maildir のメール実体を正とし、Dovecot index はそれを扱うためのメタデータとして見ます。もちろん UID やフラグも運用上は重要ですが、まずはメールファイルそのものが存在するかを確認することが切り分けの起点になります。
Maildir = メール実体
Dovecot index = IMAP 用のメタデータ / キャッシュ
INBOX が空に見える = 実体欠損とは限らない復旧前に確認すること
doveadm force-resync を実行する前に、Maildir の場所とメール実体を確認します。Dovecot では mail_path や mail_location に相当する設定、ユーザーごとの home、namespace の設定によって実際の保存場所が変わります。
doveconf -n | grep -E 'mail_location|mail_driver|mail_path|mail_index_path|namespace'
doveadm user <user>
doveadm mailbox list -u <user>
doveadm mailbox status -u <user> messages INBOX次に、Dovecot が見ている Maildir 配下にメールファイルが残っているかを確認します。パスは環境に合わせて読み替えてください。
ls -la ~/Maildir/
ls -la ~/Maildir/cur/ | head
ls -la ~/Maildir/new/ | head
find ~/Maildir/cur ~/Maildir/new -type f | headここで Maildir 配下にもメールがない場合、force-resync では復旧できません。その場合は、配送経路、バックアップ、削除操作、ストレージ障害を確認する別の問題になります。
force-resync で INBOX を再同期する
Maildir の実体が残っており、Dovecot 側の認識だけがおかしいと考えられる場合は、doveadm force-resync で対象メールボックスを再同期します。公式ドキュメントでも、Dovecot がメールボックスの問題を自動解決できない場合に使う管理コマンドとして説明されています。
doveadm force-resync -u <user> INBOX複数ユーザーで同じ症状が出ている場合でも、いきなり全ユーザーへ実行するのではなく、まず 1 ユーザー、1 メールボックスで確認します。-A のような全ユーザー対象の実行は影響範囲が広いため、原因と対象範囲を確認してからにします。
doveadm force-resync -u user@example.com INBOX
journalctl -u dovecot.service -n 100 --no-pager
doveadm mailbox status -u user@example.com messages INBOXforce-resync は何を直す操作なのか
force-resync は、消えたメールをどこからか復元するコマンドではありません。メールボックスの状態を再確認し、Dovecot 側のメタデータや認識を実体に合わせ直すための操作です。
| 処理 | 意味 | 注意点 |
|---|---|---|
| メールボックスの再スキャン | Maildir の実体を Dovecot が再確認する | 実体がなければ復元はできない |
| インデックスの再構築 | 壊れたメタデータやキャッシュを作り直す | 大量メールでは時間がかかる |
| UID / フラグの再評価 | IMAP クライアント側の再同期が発生する可能性がある | 既読状態や同期状態の見え方に注意する |
つまり、操作の主眼はメールファイルの復元ではなく、Dovecot がメールボックスをどう認識しているかの再同期です。この違いを押さえておくと、バックアップから戻すべき場面と、インデックス再同期で済む場面を分けやすくなります。
インデックスを直接削除する前に考えること
Dovecot のトラブルシュートでは、dovecot.index* を削除して再作成させる方法が語られることがあります。ただし、最初の選択肢として手で削除するより、まず doveadm force-resync や doveadm mailbox status で状態を見た方が安全です。
インデックスファイルを直接触る場合は、Dovecot が対象メールボックスを開いていない状態、バックアップ、対象ユーザー、対象メールボックスを確認する必要があります。特に共有メールボックスや大量メール環境では、影響範囲を小さくしてから作業します。
再発する場合に見るところ
一度だけの不整合であれば、再同期で解消することがあります。しかし、同じユーザーや同じメールボックスで繰り返す場合は、インデックスが壊れる背景を調べる必要があります。
| 観点 | 確認内容 |
|---|---|
| ストレージ | ディスク障害、I/O エラー、容量不足、NFS など共有ストレージの挙動 |
| 権限 | Maildir と index の所有者、グループ、パーミッション |
| 外部操作 | Dovecot 以外のプロセスが Maildir を直接変更していないか |
| バックアップ / 同期 | rsync やバックアップ処理が中途半端な状態を作っていないか |
| 配送経路 | Postfix、LMTP、LDA から Dovecot への配送経路が想定通りか |
| クライアント | IMAP クライアント側のローカルキャッシュや同期失敗ではないか |
特に Maildir を外部から直接移動・同期している環境では、メール実体、Dovecot index、UID の対応がずれやすくなります。Dovecot が管理しているメールボックスを、別プロセスがどの粒度で触っているかを確認することが重要です。
確認順序
Dovecot で INBOX が空に見える場合は、次の順番で確認すると原因を分けやすくなります。
- IMAP クライアントだけの表示問題か、複数クライアントで再現するか確認する
doveconf -nとdoveadm userで Dovecot が見ている Maildir の場所を確認する- Maildir の
cur/とnew/にメール実体が残っているか確認する doveadm mailbox statusで Dovecot 側の認識を確認する- 実体が残っているなら
doveadm force-resync -u <user> INBOXを実行する - 復旧後にログ、ストレージ、権限、外部同期、配送経路を確認する
まとめ
Dovecot で INBOX が空に見える場合でも、Maildir の cur/ や new/ にメール実体が残っていれば、データ欠損ではなく Dovecot index の不整合として切り分けられることがあります。
この時に重要なのは、メール実体、Dovecot のメタデータ、IMAP クライアント側の表示を分けて見ることです。doveadm force-resync はメールを復元する魔法ではなく、メールボックスの認識を実体に合わせ直すための管理コマンドです。
まず Maildir の実体と Dovecot の設定を確認し、対象ユーザーと対象メールボックスを絞ったうえで再同期する。これが、INBOX が空に見える時の安全な復旧手順になります。
参考情報
関連する記事
あわせて読みたい：
関連記事
自宅サーバー用ハードウェアをどう選ぶか – 小型ベアボーンで KVM 基盤を作る
竹中平蔵氏の所得制限付きベーシックインカムは何が危ういのか – 社会保障削減と自己責任論を分けて考える
OPEX / CAPEX とは何か – IT インフラとクラウド費用を資産か費用かで考える
自宅サーバー運用の歴史と進化 – Red Hat Linux からマイクロデータセンターまで
設計書に残すべきは項目ではなく判断である – 粒度、理由、実体をつなぐ文書設計
2024 年の自宅システム設計テーマ – デュアルスタック、仮想化、構成管理
SRE とは何か – SLI / SLO、エラーバジェット、トイルから理解する
リソース予測・トラフィック予測とは何か – キャパシティ管理として設計する