원래 블록 수준에서 LVM2 LV의 임시 불변성을 어떻게 보장합니까?

원래 블록 수준에서 LVM2 LV의 임시 불변성을 어떻게 보장합니까?

ext4로 포맷된 RAID5 LV가 완전히 차지하는 7개의 디스크 VG가 있는 Azure VM(Ubuntu 20.04)을 상속했습니다.

백업을 수행해야 하며 Azure Backup을 사용하여 VG가 포함된 Azure 디스크의 스냅샷을 생성하고 싶습니다.

Azure 디스크 스냅샷은 특정 시점에 일관성이 없으므로 파일 시스템 무결성 및 LVM 메타데이터 이유로 인해 백업이 실행되는 동안 스토리지를 고정해야 합니다. 내 작업량은 감당할 수 있습니다. 원시 디스크 블록을 일시적으로 변경할 수 없게 만드는 가장 좋은 방법을 찾으려고 노력 중입니다.

fsfreeze- 파일 시스템 동결, 스냅샷 촬영, 해동 후 스냅샷으로 전환하는 방법을 테스트했습니다.

제한된 테스트에서 이것은 잘 작동합니다. "복구된" 디스크를 다시 교체할 때 LVM에 대해 끔찍한 점은 보이지 않지만 너무 많은 테스트만 수행할 수 있습니다.만약에내 디스크 메타데이터가 일관되지 않아 찾을 수 없는 경우가 1% 있습니다.

너무 높은 수준에서 활동을 잠그는 것이 걱정됩니다. 활성 상태에서는 파일 시스템 작업이 발생하지 않지만 FIFREEZE ioctl이로 인해 LVM이 메타데이터 업데이트, RAID 관련 활동과 같은 모든 종류의 낮은 수준 작업을 수행하지 못하게 됩니까?

dmsetup suspend /dev/mapper/my-lvol그런 다음 이것을 시도했습니다.느끼다더 나은 솔루션을 원합니다.

테스트 설정:

fsfreeze

  1. echo 3 > /proc/sys/vm/drop_caches
  2. sync ; sync(오래된 습관은 쉽게 죽습니다 :)
  3. fsfreeze -f /export
  4. dd if=/dev/mapper/my-lvol of=/dev/null status=progress

완료될 때까지 실행합니다 dd. 고정된 파일 시스템을 통해 액세스하지 않기 때문에 이것이 작동한다는 것을 인정하지만, Azure 디스크가 변경되지 않았다고 가정할 때 LVM이 여전히 낮은 수준에서 작업을 수행할 수 있는지 궁금합니다.

dmsetup suspend

  1. echo 3 > /proc/sys/vm/drop_caches
  2. sync ; sync
  3. dmsetup suspend /dev/mapper/my-lvol
  4. dd if=/dev/mapper/my-lvol of=/dev/null status=progress

dd일시 정지가 있는 한 차단됩니다. 아직 접근할 수 있는 dd장비가 있지만 어느 정도는 그럴 것으로 예상했습니다.rmetarimage

dmsetup옵션을 사용하면 보류 중인 작업 syslog 경고가 표시됩니다 jbd2. 스택 추적은 로그 트랜잭션( jbd2_journal_commit_transaction())을 커밋하려고 시도하고 있음을 보여 주며, 이는 모두 LV가진짜하지만 일관되지 않은 상태에서 파일 시스템의 스냅샷을 찍고 있고 스냅샷으로 롤백할 경우 로그를 재생해야 할 수도 있다는 점도 걱정됩니다. 우리의 RPO는 일부 롤백을 허용하지만 이상적으로는 이러한 위험을 제거하는 솔루션을 설계하고 싶습니다.

내가 포기한 옵션

  1. 파일 기반 백업: 가능하지만 처음에는 고정된 스냅샷보다 설정 및 관리가 더 복잡해 보입니다!
  2. LV를 임시로 스냅샷하고 백업합니다. VG가 가득 차서 디스크를 더 추가하거나 VG 크기를 조정하고 싶지 않습니다.

질문

여기에 어떤 의견이라도 보내 주시면 정말 감사하겠습니다. 보시다시피, Linux 파일 시스템/블록 IO에 대한 나의 이해는 한계에 있습니다(어쩌면 그 이상일 수도 있음).

  1. 전반적으로, 고정/일시 중지가 일관된 특정 시점 스냅샷을 얻기 위한 실행 가능한 솔루션처럼 보입니까?
  2. 아직 충분히 깊이 있지 않습니까? jdb2트랜잭션을 작성할 수 없기 때문에 더 낮은 수준에서 메타데이터 업데이트를 수행할 수 있거나 계속 수행할 lvm수 있습니까?dm

고마워요, 팀

관련 정보