그러나 귀하의 솔루션은 비교적 적합한 것 같습니다.

• rsnapshot스크립트가 블록 장치에 대한 지식을 가정하지 않는지 확인하십시오 . 이상적으로는 손상을 방지하기 위해 UUID 또는 레이블로 파일 시스템을 지정하는 것이 가장 좋습니다.
• 시간 초과를 추가합니다. 이렇게 하면 우리가 인식하지 못하는 문제가 발생하거나 스크립트가 완료되지 않는 문제가 발생하는 경우 무한정 계속되는 대신 오류로 처리할 수 있습니다.
• 마지막에 "언제든지 오류가 발생하면 사용자에게 이메일을 보내고 드라이브를 마운트 해제하십시오"라고 명시합니다. 드라이브를 마운트 해제할 수 없거나 마운트 해제에 실패하면 어떻게 됩니까? 이메일이 실패하면 어떻게 되나요? 시스템에 안전 장치를 구축하십시오.
• 기본 보안의 경우 UUID는 괜찮지만(공격자가 UUID를 알 수 없는 경우) 보안에 더 관심이 있는 경우 MBR의 코드 영역(바이트 0-440)에 일부 데이터를 쓰는 것을 고려하고 처음에 백업하기 전에 스크립트를 확인하세요. 이 방법은 모호하기 때문에 다른 방법보다 더 안전하지만 이 경우에는 사용하기 더 쉬운 우수한 방법이 없습니다. 그러나 확실히 알고 싶다면 디스크에 저장된 암호화 인증서를 분석하여 드라이브가 인증되었는지 확인할 수 있습니다. udev드라이브가 감지 되면 스크립트는 해당 키를 사용하여 인증서를 해독합니다. 인증서에는 드라이브의 일련 번호, 모델, 용량 등과 같은 드라이브와 관련된 매개변수가 포함되어 있습니다. 그런 다음 암호화된 인증서에서 추출된 매개변수는 드라이브를 분석할 때 표시되는 매개변수와 비교됩니다. 매개변수가 일치하면 드라이브가 실제인 것으로 결정되고, 그렇지 않으면 드라이브가 거부되고 스크립트가 종료됩니다.

이 범위에 속하는 일부 기존 Linux 솔루션이 있지만 특정 요구 사항에 따라 다른 프로그램의 소스 코드를 조작하여 원하는 작업을 수행하는 것보다 사용자 정의 솔루션을 만드는 것이 더 나을 것이라고 생각합니다.

MBR의 코드 영역(그런 다음 검사할 수 있음)에 임의의 데이터를 쓰려면 비슷한 작업을 수행합니다 dd if=/dev/urandom of=/dev/sdX bs=440 count=1.