FS의 특정 디렉터리에 파일을 쓰는 응용 프로그램이 있습니다. 시스템은 어떤 상황에서도 작성된 파일 하나도 잃지 않습니다.
불량 블록이나 블록 비트맵 차이와 같은 하드 드라이브 문제에 직면하면 새 파일이나 기존 파일도 손상될 수 있지만 rsync백업은 .tar제대로 작동하며 파일을 열려고 할 때만 파일에 질문이 있다는 것을 알게 됩니다.
파일이 일단 손상되면 파일이 손상되었는지 알 수 있는 방법이 필요합니다. 더 나아가 파일이 손상되기 전에 디스크에 문제가 있는지 알 수 있는 방법이 필요합니다.
각 파일의 해시를 파일로 보관하고 매일 확인하고 싶지만 지금보다 시간이 더 걸릴 것 같습니다. 또 다른 아이디어는 이러한 파일을 SGDB에 넣는 것인데, 이 문제를 해결하는 더 좋은 방법이 있는지 궁금합니다.
나는 뭔가를 놓치고 있다고 확신하지만 눈이 멀었습니다.
시스템: Debian 6및 Debian 7 32bit( 64bit응용 프로그램은 여러 위치에 설치됩니다). 모든 시스템은 ext4(더 신뢰할 수 있는 다른 시스템이 있습니까?)
답변1
섹터가 손상되기 직전이거나 손상되었을 때 쉽게 감지할 수 있었다면 지금쯤 해당 섹터가 파일 시스템에 통합되었을 것입니다. 오류의 특성상 일반적으로 침묵 상태로 유지됩니다. 체크섬을 수행할 수 있는 파일 시스템이 필요합니다. GNU/Linux에서는 BTRFS가 좋은 옵션이 될 수 있습니다. 온라인으로 확인해보니 Debian 6에서 지원이 도입된 것 같습니다.
기본적으로 체크섬 + raid(어떤 형태)가 필요합니다. 파일 시스템은 RAID 설정에 최소 2개의 레그가 있는 경우에만 자동 수정이 가능합니다. 두 번째 다리가 없으면 검증 가능한 문서의 좋은 사본을 찾을 곳이 없습니다. 다행스럽게도 동일한 디스크(또는 사용 가능한 논리 볼륨)에 있는 두 개의 서로 다른 파티션을 사용하여 RAID1 배열을 생성할 수 있습니다.
분명히 동일한 디스크에 두 경우 전체 디스크 오류로부터 보호되지는 않지만 섹터 오류로부터 보호됩니다. 실패한 섹터를 시뮬레이션하는 것은 SE의 답변에 투자하는 것보다 더 많은 작업일 수 있지만이 남자(테스트는 24:30에 시작됩니다.) 당신을 위한 데모입니다.
기본적으로 BTRFS는 파일을 불투명하게 복원하며 사용자 공간은 어떤 일이 발생했는지 알 수 없습니다. 이를 사용하여 btrfs scrub오류를 감지할 수 있습니다. cronjob에서 실행하고 로컬 계정 중 하나로 이메일을 보내도록 할 수 있습니다. 그런 다음 /etc/aliases명령 출력이 실제 이메일 계정으로 전달되도록 설정할 수 있습니다 .
답변2
SMART 모니터링 도구를 설치하고 구성할 수 있습니다. Debian에서는 이 패키지를 이라고 합니다 smartmontools. 이는 디스크 오류로부터 보호하지는 않지만 디스크 오류의 가능한 원인을 식별하는 데 도움이 됩니다.
패키지 설치에는 구성이 없으므로 먼저 파일에서 SMART 모니터링을 활성화해야 합니다 /etc/default/smartmontools.
# uncomment to start smartd on system startup
start_smartd=yes
그런 다음 구성 파일을 편집합니다 /etc/smartd.conf.
# The word DEVICESCAN will cause any remaining lines in this
# configuration file to be ignored [...]
# [...] Most users should comment out DEVICESCAN and explicitly
# list the devices that they wish to monitor.
#DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner
# Short test nightly, Long test on Sunday mornings; append "-m [email protected]" to email errors
/dev/sda -a -s (S/../.././02|L/../../6/03)
/dev/sdb -a -s (S/../.././04|L/../../6/05)
/dev/sdc -a -s (S/../.././06|L/../../6/07)
# /dev/sdd -a -s (S/../.././06|L/../../6/07) -m [email protected]
마지막으로 모니터링 하위 시스템을 시작합니다 invoke-rc.d smartmontools start.
아주 좋은 답변도 있습니다고가용성 소프트웨어 RAID 1 서버에서 smartd(smartmontools의)를 사용하여 디스크 상태 모니터링
답변3
디스크가 언제 어디서 손상될지 예측할 수 없으므로 손상된 복사본이 백업을 덮어쓰는 것을 방지하는 가장 쉬운 방법은 순환 백업을 수행하는 것입니다.
따라서 기본적으로 매일 다른 위치에 백업할 수 있습니다. 디스크 오류를 발견하고 복구에 사용할 수 있는 백업이 여러 개 있는 경우 마지막 백업도 손상된 백업으로 덮어써졌습니다.
cron및를 사용하는 것은 간단한 작업이어야 하며 rysnc이 목적을 위한 여러 스크립트가 있습니다.
답변4
이런 종류의 보안은아니요파일 시스템 위에 처음부터 구현해 보세요. 대신 시스템을 재구성하고 ZFS를 사용하는 것이 좋습니다. ZFS를 사용하면 모든 일관성이 파일 시스템 수준에서 처리되므로 체크섬 등을 추적하거나 모든 액세스 또는 파일에 액세스하는 모든 도구에서 파일 상태를 명시적으로 확인할 필요가 없습니다.