btrfs는 백업 파일 시스템으로 적합합니까?

지금은 ext4 위에 꽤 전통적인 백업 파일 시스템 구조가 있습니다. 백업을 만들 때마다 backup-DATErsync의 --link-dest옵션을 사용하여 만든 하드 링크와 함께 파일이 rsync 되는 새 폴더 가 만들어집니다 .

Bitrot에 대해 읽었으므로 모든 파일에 대한 체크섬을 투명하게 만들고 싶습니다. 분명히 ext4는 그렇게 할 수 없지만 btrfs는 데이터 체크섬 (및 내장 RAID1 모드)을 지원합니다. 우선 btrfsRAID, 하위 볼륨 스냅 샷, 보내기 / 받기 등과 같은 고급 기능을 사용하지 않고 데이터 체크섬을 지원하는 "덤"파일 시스템 으로 사용 하고 싶습니다 .

그러나 위키는 백업 목적으로 파일 시스템에 대한 확신을 심어주지 않습니다.

"많은 사람들이이 파일을 안정적으로 사용하지만 여전히 문제가 발견되고 있습니다. 데이터 백업을 유지하고 테스트하고 사용할 준비가되어 있어야합니다." - 시작하기

"Btrfs가 안정적입니까? 긴 대답 : [..] 무엇을 하든지 테스트를 거친 시스템 외부 (및 오프 사이트) 백업을 유지하는 것이 좋습니다." - 자주 묻는 질문 .

내 유스 케이스는 오프라인 백업을하는 것입니다. 이러한 이유로 디스크는 거의 사용하지 않고 (시간 단위로) 자주 연결 / 분리됩니다 (eSATA 또는 USB 3.0). 안정적인 파일 시스템을 갖추는 것이 필수적입니다. ext4 wrt보다 나빠서는 안됩니다. 정전, 부정한 종료 등

백업 목적으로 btrfs를 파일 시스템으로 사용하는 것이 실제로 권장됩니까? btrfs의 다른 특성이 적어 적합하지 않을 수 있습니까?

나는 이것이 과잉 생각되고 있기 때문에 짧은 대답을 제공 할 것입니다.

btrfs (sub-) 명령 에 대한 기본 커널 위키를 읽으면 다음 과 같은 두 가지 명령이 있습니다.

1. "백업"만들기 :btrfs-send
2. 및 복원 :btrfs-restore

다만, 이는 백업이 아니라 (필요한 경우 백업이 아니라 "유연한"롤백이라는 개념으로) 스냅 샷 파일 시스템이되도록 설계되었음을 의미합니다.

따라서 백업으로 사용하지 마십시오. 파일을 테스트하고 되돌아 갈 수있는 버전이 지정된 파일 시스템으로 사용하십시오. 그것에 의존하지 마십시오.

최근에 최신 커널 4.10.0에서 btrfs 파일 시스템에 문제가있었습니다. TRIM이 어딘가에 올바르게 구현되지 않은 것처럼 보이기 때문에 가상 시스템 VM에서 파일 시스템이 손상되었으며 AFAIK는 하위 볼륨의 색인 번호와 관련이 있습니다. VMware로 전환 한 후에도 파일 시스템이 여전히 손상되어 놀랍게도 btrfs check오류를 찾아서 고칠 수 없었습니다. 마지막으로 ext4로 다시 전환했습니다.

좋은 점 : 데이터를 잃지 않았습니다. btrfs는 적어도 읽기에는 항상 일관성이있는 것처럼 보이지만 여전히 프로덕션 준비 상태와는 거리가 멀었습니다.

어쨌든 서버에서는 중복 제거를 위해 암소 복사 기능이 필요하기 때문에 여전히 백업 볼륨으로 사용하고 있습니다 (정확히 사용 사례). 기존 파일 시스템에 비해 데이터 크기가 너무 큽니다.

최신 정보

여전히 서버에 파일 시스템이 있지만 (위 참조) 여기에 게시 한 직후에 문제가 발생했습니다. 이제 700G의 큰 읽기 전용 백업 볼륨을 사용하여 ext4에서 ~ 7TB로 확장하여을 사용하여 모든 것을 복사하려고하면 ~ 7TB로 확장됩니다 tar|tar. 시간이 부족하여 최신 커널 버전으로 처리 할 수 ​​있는지 아직 확인하지 않았습니다. 실제 문제는 "트랜잭션 중단"으로, 쓰기 가능 마운트 후 ~ 2 초가 걸리고 볼륨은 읽기 전용으로 다시 마운트됩니다. 원래 원인은 아마도이 btrfs-convert볼륨을 만들 때 몇 년 전에 사용한 깨진 버전 일 것입니다. 그리고 여전히 거래 중단으로 이어질 수있는 볼륨의 모든 손상 btrfs check을 찾을 수 있어야 하는 전류의 제한된 기능 세트입니다. 또는 내 파일 시스템이 정상이라고 말하는 대신 다른 문제가 있습니다.