私はbtrfs subvolume ルートファイルシステムを備えた小規模アプリケーションサーバー（Raspberry Pi）を実行しています。サーバーには、postfixアプリケーションから送信された電子メールをキャプチャしてプライマリサーバーに転送する簡単な実装があります。したがって、何らかの理由でプライマリメールサーバーがシャットダウンまたはアクセスできない場合でも、アプリケーションによって生成された電子メールは失われません。これらの電子メールは企業の顧客に送信されます。
btrfs subvolumeアプリケーション自体はそのまま独立して実行されます/var/log。私が言う理由は、btrfs subvolume snapshot実行中のルートファイルシステムをバックアップするために定期的に使用するためです。これはtar'ed安全な保管のために別のコンピュータに保存されます。主なrootfsの変更は非常にまれであるため、現在はこのタスクを毎週実行しますが、毎月に戻ることもできます。
私は小規模企業のためにこのアプリケーションサーバーをリモートで管理しています。
このRaspberry Piの最大のエラーは破損したSDカードです。自宅のメインメールサーバーとして機能するRaspberry Piでこれが起こりました。すべてをバックアップしたにもかかわらず、正しく復元するのに数日かかりました。だから私はダウンタイムを最小限に抑えながら、このアプリケーションサーバーからこれらのエラーを回復する方法を考え直しています。
このサーバーに障害が発生した場合、オフィス管理者は事前に準備された予備のSDカードを入手して、障害が発生したSDカードを交換できると確信しています。ssh小さな「仮想」ファイルシステムをrootとして使用し、最終rootfsを解凍するときにこの新しいrootで起動するように更新するだけで十分です/boot/cmdline.txt（この時点で接続を切断して再接続する必要があります）。
唯一の問題は、raw tarバックアップを実行するとサフィックスmailqが空でない可能性があることです。私はpostfix起動の最後の再起動段階でキューが空ではないことに気づき、潜在的に1週間（または1ヶ月）のバックアップから電子メールを送信したくありません。
この質問に関するすべての議論で、質問者はを使用するように指示されましたが、postsuper -d ALL実行中のシステムで利用可能になったときは遅すぎ、待機中のメールがすでに送信されている可能性があります。再起動する前に、chroot新しいルートディレクトリに行ってそこから実行できると思いましたが、postsuperこれまでの最も簡単な方法はファイルを削除することですが、どのファイルなのかわかりません。
この問題を処理する最良の方法は何ですか？
答え1
答えを見つけて試してテストしましたが、うまくいくようです。
/var/spool/postfixデフォルトでは、メッセージが保存される一連のディレクトリがあります。その中のすべてのファイルを削除すると、デフォルトではキュー全体が消去されます。ルートファイルシステムがマウントされたとき（Raspberry Piにロードされる前）、_rootこれを実行するために使用するコードは次のとおりです。
_root/var/spool/postfix/{defer,bounce,maildrop,incoming,active,deferred,hold,flush} -type f -exec rm {} \;