현재 저는 ext4를 기반으로 하는 매우 전통적인 백업 파일 시스템 구조를 가지고 있습니다. 백업이 수행될 때마다 backup-DATE새 폴더가 생성되고 파일이 재동기화됩니다(하드 링크를 생성하려면 rsync 옵션을 사용하십시오 --link-dest).
bitrot에 대해 읽었으므로 모든 파일을 투명하게 체크섬하고 싶습니다. 분명히 ext4는 이를 수행할 수 없지만 btrfs는 데이터 체크섬(내장 RAID1 모드도 포함)을 지원합니다. 먼저 btrfs를 RAID, 하위 볼륨 스냅샷, 전송/수신 등과 같은 고급 기능을 사용하지 않고 데이터 체크섬을 지원하는 "멍청한" 파일 시스템으로 사용하고 싶습니다.
그러나 그들의 위키는 백업 목적으로 파일 시스템에 대한 신뢰를 실제로 고무시키지는 않습니다.
"많은 분들이 안정적으로 사용하고 있지만 여전히 문제점이 발견되고 있습니다. 데이터를 백업해 두고 테스트해 보시고 사용하실 수 있도록 준비하시기 바랍니다." -시작하기
"btrfs는 안정적입니까? 긴 답변: [..] 무엇을 하든, 테스트를 거친 좋은 시스템 외부(및 외부) 백업을 유지하는 것이 좋습니다."자주하는 질문.
내 사용 사례는 오프라인 백업을 수행하는 것입니다. 따라서 디스크 사용량(시간 단위)이 매우 낮고 자주 연결/분리됩니다(eSATA 또는 USB 3.0). 안정적인 파일 시스템을 갖추는 것은 필수입니다. 정전, 비정상적인 종료 등의 측면에서 ext4보다 나쁘지는 않습니다.
btrfs를 백업용 파일 시스템으로 사용하는 것이 실제로 권장됩니까? btrfs를 덜 (또는 더) 적합하게 만들 수 있는 다른 속성이 있습니까?
답변1
너무 과한 생각인 것 같아서 짧은 답변만 드리겠습니다.
메인 커널 위키를 읽으면btrfs(하위)명령, 다음 두 가지 명령이 있음을 알 수 있습니다.
- "백업"을 만드세요:
btrfs-send - 그리고다시 덮다:
btrfs-restore
만일의 경우에 대비해 백업이 아니라 스냅샷 파일 시스템이라는 의미이며, 필요할 경우 백업이 아닌 "유연한" 상태로 롤백하는 것이 아이디어입니다.
따라서 아니요, 백업으로 사용하지 말고 테스트하고 돌아올 수 있는 버전이 지정된 파일 시스템으로 사용하십시오. 그것에 의존하지 마십시오.
답변2
최근에 최신 커널 4.10.0에서 btrfs 파일 시스템을 사용하는 데 문제가 발생했습니다. TRIM이 어딘가에 올바르게 구현되지 않은 것 같고 AFAIK가 하위 볼륨의 인덱스 번호와 관련되어 있기 때문에 virtualbox VM에서 파일 시스템이 손상되었습니다. VMware로 전환한 후에도 파일 시스템이 여전히 손상되어 있으며 놀랍게도 btrfs check오류를 찾아 수정할 수 없습니다. 마침내 ext4로 다시 전환했습니다.
좋은 점은 데이터를 잃지 않았다는 것입니다. btrfs는 적어도 읽기 측면에서는 항상 일관된 것처럼 보이지만, 프로덕션 준비 상태와는 거리가 멀다는 것을 보여줍니다.
어쨌든 서버에서는 중복 제거를 위한 암소 복제 기능이 필요하기 때문에(정확히 귀하의 사용 사례) 이를 백업 볼륨으로 사용하고 있습니다. 기존 파일 시스템에 비해 데이터가 너무 큽니다.
고쳐 쓰다
내 서버에는 여전히 파일 시스템이 있지만(위 참조) 여기에 게시한 후 파일 시스템이 손상되었습니다. 지금은 700G라는 대용량의 읽기전용 백업볼륨을 가지고 있는데 사용하려고 하면 tar|tar... 최신 커널 버전에서는 시간이 부족하여 감당할 수 있는지는 확인하지 못했습니다. 실제 문제는 쓰기 가능한 볼륨을 마운트하고 해당 볼륨을 읽기 전용으로 다시 마운트한 후 약 2초 후에 발생하는 "트랜잭션 중단"입니다. 원래 원인은 아마도 btrfs-convert몇 년 전 이 책을 만들 때 사용했던 버전의 손상된 버전이었을 것이며 , btrfs check적어도 현재 버전에서는 여전히 제한된 기능 세트일 것입니다.찾다볼륨이 손상되면 트랜잭션이 중단되거나 파일 시스템이 정상이라는 것 이외의 다른 문제가 반복적으로 발생합니다.
업데이트 2
Python 스크립트(OSS 중복 제거 도구 기반)를 사용하여 모든 것을 새 볼륨에 복사하여 마침내 문제를 해결할 수 있었습니다. 체크섬을 기반으로 대상 파일 시스템의 파일 풀과 작동하고 거기에서 소 링크를 생성합니다. 이 반효율적인 프로세스는 2일이 걸렸지만 새로운 깨끗한 btrfs 기반 파일 시스템을 갖게 되었고 모든 데이터가 복원되었습니다. 원한다면 코드를 게시하세요. 하지만 완벽하고 사용하기 쉬우며 오류 방지 도구를 기대하지는 마세요.