백업에서 복원할 때 postfix가 mailq에서 메시지를 다시 보내는 것을 방지하는 방법(다시 시작하기 전에 삭제할 수 있습니까?)

백업에서 복원할 때 postfix가 mailq에서 메시지를 다시 보내는 것을 방지하는 방법(다시 시작하기 전에 삭제할 수 있습니까?)

저는 btrfs subvolume 루트 파일 시스템을 갖춘 소규모 애플리케이션 서버(Raspberry Pi)를 실행하고 있습니다. 서버에는 postfix애플리케이션에서 보낸 이메일을 캡처하여 기본 서버로 전달하는 간단한 구현이 있습니다. 따라서 어떤 이유로든 기본 메일 서버가 종료되거나 액세스할 수 없는 경우에도 애플리케이션에서 생성된 이메일은 손실되지 않습니다. 이러한 이메일은 기업 고객에게 전송됩니다.

btrfs subvolume애플리케이션 자체는 있는 그대로 독립적으로 실행됩니다 /var/log. 내가 이렇게 말하는 이유는 btrfs subvolume snapshot실행 중인 루트 파일 시스템을 백업하기 위해 정기적으로 사용하기 때문입니다. 이는 tar'ed안전 보관을 위해 다른 컴퓨터에 저장됩니다. 주요 rootfs 변경이 매우 드물게 발생하기 때문에 현재는 이 작업을 매주 수행하지만 매월로 돌아갈 수도 있습니다.

저는 소규모 기업을 위해 이 애플리케이션 서버를 원격으로 유지관리하고 있습니다.

이 Raspberry Pi의 가장 큰 오류는 손상된 SD 카드입니다. 집의 메인 메일 서버 역할을 하는 Raspberry Pi에서 이런 일이 발생했습니다. 모든 것을 백업했음에도 불구하고 제대로 복원하는 데 며칠이 걸렸습니다. 그래서 저는 가동 중지 시간을 최소화하면서 이 응용 프로그램 서버에서 이러한 오류를 복구하는 방법을 다시 생각하고 있습니다.

이 서버에 장애가 발생하면 사무실 관리자는 미리 준비된 예비 SD 카드를 구해 장애가 발생한 SD 카드를 교체할 수 있을 것이라고 확신합니다. ssh작은 "가상" 파일 시스템을 루트로 사용하고 최종 rootfs의 압축을 풀 때 이 새 루트로 부팅하도록 업데이트하면 충분합니다 /boot/cmdline.txt(이 시점에서 연결을 끊었다가 다시 연결해야 합니다).

유일한 문제는 원시 tar 백업을 수행할 때 접미사 mailq가 비어 있지 않을 수 있다는 것입니다. 나는 postfix 시작의 마지막 재부팅 단계에서 대기열이 비어 있지 않다는 사실을 알아차리고 잠재적으로 일주일(또는 심지어 한 달) 된 백업에서 이메일을 보내는 것을 원하지 않습니다.

이 질문에 대한 모든 토론에서 질문자는 를 사용하라는 지시를 받았지만 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 {} \;

관련 정보