백업 시나리오에서 rsnapshot에 비해 btrfs 스냅샷을 사용하면 어떤 이점이 있습니까? [닫기]

btrfs는 기존 파일 시스템보다 속도를 느리게 만드는 많은 기능(예: 오류 감지 및 수정, 투명한 압축, 스냅샷, 하위 볼륨 등)을 갖춘 기록 중 복사 파일 시스템입니다.

그러나 btrfs 스냅샷은 매우 가벼우며 만드는 데 시간이 거의 걸리지 않습니다. (또는)을 사용하는 것은 btrfs send ... | btrfs receive보낸 사람과 받는 사람 파일을 비교해야 하는 또는 또는 다른 방법을 사용하는 것보다 훨씬 빠릅니다 btrfs send | ssh remote_host btrfs receive.rsyncrsnapshot

한 스냅샷과 다른 스냅샷 간의 정확한 차이점이 알려져 있으므로(스냅샷에 내재되어 있음) 변경된 블록을 연속 바이너리 스트림으로 수신자에게 보낼 수 있으므로 스냅샷을 보낼 때 이러한 파일 비교가 필요하지 않습니다. - 비교할 필요가 없습니다. 파일 타임스탬프 또는 내용.

즉, 전체 파일 시스템 성능은 느려지지만 백업 속도도 느려집니다.많은서둘러요.

제가 사용하고 있는 zfs것은 btrfs스냅샷과 보내기/받기 메커니즘이 매우 유사하다는 것입니다. 백업에서 백업 rsync으로 전환했을 때 zfs send증분 백업 실행 시간이 몇 시간에서 몇 분으로 단축되었습니다.

나는 로컬 네트워크의 모든 컴퓨터를 주 파일 서버의 "백업" 풀에 백업합니다. rsynccron이 다음 날 백업을 트리거할 때까지 백업은 완료되지 않습니다. 여러 백업이 항상 실행되면서 서버 성능이 형편없었고 사용 가능한 상태로 되돌리려면 지속적인 수동 개입(주로 rsync 프로세스 종료)이 필요했습니다. 사용 가능한 파일 서버 로 전환하는 것과 zfs send사용할 수 없는 파일 서버 로 전환하는 것의 차이점 이제는 그것에 대해 거의 생각할 필요가 없습니다. 그냥 작동합니다. 최대 1~2년 동안 백업 풀에서 오래된 스냅샷을 제거합니다(백업 중인 호스트에서는 스냅샷을 적극적으로 자동 만료하지만 백업 풀에서는 덜 적극적으로). 이를 허용하는 경우 백업 풀이 필요할 수 있습니다. 오랫동안 백만 또는 두 개의 스냅샷을 촬영했습니다.

현재 설정을 대체할 수 있는지 여부에 대해서는 두 개의 btrfs 풀이 있는 btrfs 테스트 VM을 생성하고 스냅샷을 찍어 한 풀에서 다른 풀로 보내는 것이 좋습니다. 또는 여러 테스트 가상 머신을 통해 btrfs send통과 할 수 있습니다 ssh.

btrfs 스냅샷 및 btrfs 보내기/받기 작동 방식에 매우 익숙해지고 익숙해질 때까지는 전환을 권장하지 않습니다.

실제로 ZFS VM도 일부 만들어서 차이를 느껴보세요.

가상 머신은 사용 여부를 결정하기 전에 새로운 것을 시험해 보는 데 적합합니다. 문서를 읽는 것은 필수적이지만, 어떤 것이 어떻게 작동하는지 정말로 이해하고 싶다면 손을 더럽히는 것만큼 좋은 것은 없습니다.

---

그런데 작업 부하에 따라 투명한 압축은 btrfs 또는 ZFS와 같은 파일 시스템을 사용하는 것과 ext4 또는 xfs와 같은 보다 전통적인 파일 시스템을 사용하는 것 사이의 성능 저하를 상당 부분 상쇄할 수 있습니다.

• fs 성능이 유일하거나 가장 중요한 것이라면 사용하십시오 xfs. 지금까지는 이것이 확실한 승자입니다.

• 스냅샷, 스냅샷 보내기/받기, 압축, ECC, 하위 볼륨 등이 필요한 경우 ZFS 또는 btrfs를 사용하세요.

• IMO, ZFS 대신 btrfs를 사용하는 유일한 실제 이유는 btrfs가 메인라인 Linux 커널에 있는 반면 ZFS는 CDDL과 GPL 간의 라이센스 충돌로 인해 결코 빛을 볼 수 없기 때문입니다. ZFS의 경우 커널 모듈을 컴파일하고 설치해야 합니다. 이는 zfs-dkms 모듈을 사용하면 매우 쉽습니다.

• Ubuntu를 사용하는 경우 즉시 ZFS를 사용할 수 있으며 라이선스 문제가 그렇게 큰 문제라고 생각하지 않습니다. IMO에서는 그에 대해 틀렸지만 Oracle이 고소할 가능성은 거의 없습니다.

• 또한 LUKS를 사용하고 있으므로 관심을 가질 만한 한 가지는 ZFS에 모든 데이터 세트(btrfs 용어의 "하위 볼륨". LVM 용어의 결합된 LV + 파일 시스템과 유사)를 암호화할 수 있는 옵션이 있다는 것입니다. 저는 LUKS나 ZFS로 암호화를 사용해 본 적이 없기 때문에 어떻게 비교되는지 말씀드릴 수 없습니다.

• 이제 ext4를 사용할 이유가 별로 없습니다. 단, 대부분의 배포판에서 이것이 기본값이라는 점만 빼면 말이죠. 장점도 없고 굳이 사용해야 할 이유도 없습니다.

• 마지막으로 ZFS 중복 제거의 유혹에 빠지지 마십시오. 이는 이론적으로는 좋은 생각처럼 들리지만 실제로는 중복 제거 테이블을 RAM에 보관해야 하므로 더 저렴한 드라이브에 대한 필요성을 줄이고 더 비싼 RAM으로 교체할 수 있음을 의미합니다. 일부 특별한 사용 사례(예: 수백 또는 수천 개의 동일한 가상 머신 이미지 실행)의 경우 이는 나쁜 거래입니다. RAM은 프로그램 실행이나 디스크 캐싱에 더 잘 사용됩니다.

나는 분명한 질문이 있다고 생각합니다 ...

RSnapshot의 이상적인 구성은 한 디스크에서 다른 디스크로 복사하는 것입니다. 따라서 데이터 디스크에 문제가 발생하면 별도의 백업에서 복원할 수 있습니다. 그리고 백업 볼륨(예: 다른 디스크)이 동일한 서버에 있을 필요가 없으며 네트워크 연결을 통해 RSnapshot을 수행할 수 있습니다.

btrfs는 모두 동일한 디스크나 볼륨에서 발생합니다. 모든 것이 fubar에서 발생하고 그게 전부라면 솔(sol)입니다. 모두 하나의 디스크에 있으면 좋지 않습니다. raid5 또는 raid6을 사용하는 것이 좋은 시작이지만, 화재, 홍수 또는 특정 위치의 기타 "재난"은 물론이고 raid로 보호할 수 없는 단순한 파일 시스템 손상에 여전히 취약합니다.

rsnapshot이 데이터 볼륨에서 데이터를 읽고 어떤 연결 방법을 통해 백업 볼륨에 데이터를 쓰는 데 걸리는 시간이 아니라 스냅샷 프로세스가 자동으로 발생하기 때문에 btrfs가 본질적으로 더 빠르다고 생각합니다. 백업 볼륨의 디스크에 배치됩니다. 별도의 디스크이지만 동일한 서버에 있으면 매우 빠를 수 있지만 RSnapshot이 네트워크를 통해 다른 곳으로 전송되면 상당한 손실이 발생할 수 있습니다.

Synology NAS를 사용하면 파일 시스템 선택으로 ext4 또는 btrfs를 제공하며 기본적으로 ext4가 더 빠르다고 말합니다. 나는 일반적으로 ext4가 btrfs보다 빠르다고 생각하지만, 중요한 것은 차이가 크든 없든 파일 시스템을 어떻게, 어떻게 사용할 것인지입니다.