이것이 LVM 스냅 샷 작동 방식입니까?

LVM 스냅 샷의 작동 방식을 파악하여 파일 서버에서 구현할 수 있지만 Google에서 기본 백업 시스템에 사용하는 대신 작동 방식을 설명하는 항목을 찾는 데 어려움을 겪고 있습니다.

내가 읽은 것에서 다음과 같이 작동한다고 생각합니다.

• 기본 파티션과 파티션에없는 많은 할당되지 않은 여유 공간이있는 LVM이 있습니다.
• 그런 다음 스냅 샷을 만들어 새 논리 볼륨에 마운트합니다. 스냅 샷에는 변경 사항이 있으므로 첫 번째 스냅 샷은 전체 사본이됩니다. 맞습니까?
• 그리고 다음 날에 다른 스냅 샷 (이 파티션의 크기가 클 필요는 없음)을 만들어 마운트하십시오.
• 어떻게 든 LVM은 스냅 샷을 추적하고 기본 볼륨에 변경되지 않은 비트를 저장하지 않습니다.
• 그런 다음 충분한 스냅 샷이 있고 첫 번째 스냅 샷을 제거하기로 결정합니다. 이것이 어떻게 작동하는지 또는 그것이 다음 스냅 샷에 어떻게 영향을 줄지 모르겠습니다.

내가 틀린 곳에서 누군가 나를 교정 할 수 있습니까? 기껏해야 구글에서 아무것도 찾을 수 없습니다.

vgdiplay

obu1 : / home / jail / home / qps / backup / D # vgdisplay
  --- 볼륨 그룹 ---
  VG 이름 파일 서버
  시스템 ID
  lvm2 형식
  메타 데이터 영역 1
  메타 데이터 시퀀스 번호 3
  VG Access 읽기 / 쓰기
  VG 상태 크기 조정 가능
  MAX LV 0
  Cur LV 2
  LV 2 열기
  최대 PV 0
  Cur PV 1
  PV 1 막
  VG 크기 931.51 GB
  PE 크기 4.00 MB
  총 PE 238467
  Alloc PE / 크기 238336 / 931.00 GB
  무료 PE / 크기 131 / 524.00 MB
  VG UUID qSGaG1-SQYO-D2bm-ohDf-d4eG-oGCY-4jOegU

LVM-HOWTO 의 스냅 샷 섹션을 보지 않으 셨습니까?

LVM 스냅 샷은 기본 "쓰기시 복사"스냅 샷 솔루션입니다. 스냅 샷은 LVM에 파일 시스템의 현재 상태에 대한 "포인터"를 제공하고 스냅 샷 이후의 변경 사항을 지정된 영역에 쓰도록 요청하는 것 이상입니다.

LVM 스냅 샷은 다른 볼륨이 아닌 스냅 샷의 대상이되는 볼륨을 호스팅하는 볼륨 그룹 내에서 "라이브"합니다. "... 파티션이 아니라 많은 할당되지 않은 여유 공간이 많다"는 말은 볼륨 그룹 외부의 스냅 샷이 스냅 샷의 대상이되고 "정확하지 않다"고 생각하는 것처럼 들립니다. 볼륨 그룹은 하드 디스크 파티션에 있으며 볼륨은 스냅 샷 및 해당 볼륨 그룹에서 라이브로 촬영 한 모든 p 샷에 종속됩니다.

LVM 스냅 샷이 사용되는 일반적인 방법은 장기 저장소가 아니라 파일 시스템의 일관된 "사진"을 가져 와서 백업을 수행하는 것입니다. 백업이 완료되면 스냅 샷이 삭제됩니다.

LVM 스냅 샷을 생성 할 때 스냅 샷이 활성화 된 동안 변경 한 내용을 저장할 공간을 지정합니다. 지정한 공간보다 더 많은 변경 사항이 있으면 스냅 샷을위한 공간을 사용할 수 없게되고 버려야합니다. (a) 스냅 샷이 채워져 사용할 수 없게되고 (b) 스냅 샷이 활성화되어있는 동안 시스템 성능에 영향을 미치므로 작업 속도가 느려지므로 스냅 샷을 남기고 싶지 않습니다.

편집하다:

Microsoft Volume Shadow Copy Services와 LVM 스냅 샷의 기능은 크게 다르지 않습니다. Microsoft의 솔루션은 좀 더 포괄적입니다 (일반적으로 Microsoft의 경우와 마찬가지로 도구 및 제품은 종종 한 가지 문제에 초점을 맞추는 것보다 꽤 큰 문제를 해결하려고합니다).

VSS는 스냅 샷 및 소프트웨어 기반 스냅 샷을 지원하는 하드웨어 장치에 대한 지원을 단일 API로 통합하는보다 포괄적 인 솔루션입니다. 또한 VSS에는 스냅 샷 API를 통해 애플리케이션을 정지시킬 수있는 API가 있습니다. 반면 LVM 스냅 샷은 스냅 샷에만 관심이 있습니다. 모든 정지 애플리케이션은 문제입니다 (데이터베이스를 "백업"상태로 만드는 등).

Evan이 말했듯이 LVM 스냅 샷은 COW (Copy-On-Write) 스냅 샷 솔루션의 한 예입니다. 작동 방식은 Evan이 암시 한 것과는 약간 다르지만 전체적으로는 다릅니다.

스냅 샷이없는 LVM 볼륨이있는 경우 예상대로 볼륨에 쓰기가 수행됩니다. 블록이 변경되었습니다.

스냅 샷을 생성하자마자 LVM은 블록 풀을 생성합니다. 이 풀에는 볼륨의 LVM 메타 데이터 전체 사본도 포함됩니다. inode 업데이트와 같은 주 볼륨에 쓰기가 수행되면 덮어 쓰는 블록이이 새 풀에 복사되고 새 블록이 주 볼륨에 쓰여집니다. 이것이 '기록 중 복사'입니다. 이로 인해 스냅 샷 생성 시점과 기본 볼륨의 현재 상태 사이에서 변경되는 데이터가 많을수록 해당 스냅 샷 풀에서 더 많은 공간을 사용하게됩니다.

스냅 샷을 마운트 할 때 스냅 샷을 작성할 때 기록 된 메타 데이터를 사용하면 볼륨의 변경된 블록 (또는 상위 레벨 스냅 샷)에 스냅 샷 풀 블록을 맵핑 할 수 있습니다. 이러한 방식으로 특정 블록에 대한 액세스가 이루어지면 LVM은 어떤 블록 액세스를 알고 있습니다. 해당 볼륨의 파일 시스템에 관한 한 스냅 샷은 없습니다.

James는이 시스템의 결함 중 하나를 지적했습니다. 동일한 볼륨의 여러 스냅 샷이있는 경우 기본 볼륨의 블록에 쓸 때마다 모든 단일 스냅 샷에서 쓰기가 트리거 될 수 있습니다. 각 스냅 샷은 자체적으로 변경된 블록 풀을 유지하기 때문입니다. 또한 긴 스냅 샷 트리의 경우 스냅 샷에 액세스하면 서버에서 약간의 계산을 수행하여 액세스에 필요한 정확한 블록이 무엇인지 파악할 수 있습니다.

스냅 샷을 폐기 할 때 LVM은 스냅 샷 풀을 삭제하고 필요에 따라 스냅 샷 트리를 업데이트합니다. 삭제 된 스냅 샷이 스냅 샷 트리의 일부인 경우 일부 블록이 하위 레벨 스냅 샷으로 복사됩니다. 가장 낮은 스냅 샷이거나 유일한 스냅 샷 인 경우 풀이 삭제되고 작업이 매우 빠릅니다.

일부 파일 시스템은 파일 시스템 내 스냅 샷을 제공하며 ZFS 및 BTRFS는 잘 알려진 두 가지입니다. 파일 시스템 자체가 변경 / 변경되지 않은 매핑을 관리하지만 비슷하게 작동합니다. 일관성을 유지하기 위해 전체 스냅 샷 제품군을 fsck 할 수 있기 때문에이 방법을 사용하는 것이 더 좋습니다. 이는 바로 LVM으로 수행 할 수없는 작업입니다.

Linux를 사용하는지 HP-UX를 사용하고 있는지 지정하지 않습니다. HP-UX에서 논리 볼륨을 작성하고 다른 논리 볼륨의 스냅 샷으로 마운트합니다. Linux에서는 논리 볼륨을 스냅 샷 볼륨으로 만듭니다.

HP-UX에서 스냅 샷 제거는 볼륨을 마운트 해제하여 수행됩니다. Linux에서는 논리 볼륨을 제거하기 위해 lvremove를 사용하여 수행됩니다.

어쨌든 변경 사항은 스냅 샷에 저장된 유일한 것입니다. 스냅 샷을 사용할 수있는 시간이 길어질수록 더 많은 변경 사항이 저장됩니다. 크기가 적절하지 않거나 릴리스되지 않으면 채워질 수 있습니다.

스냅 샷 볼륨의 디스크 액세스 속도는 일반 볼륨보다 느립니다. 당신은 그것을 고려해야합니다.

LVM 스냅 샷은 비효율적이며 스냅 샷이 많을수록 시스템 속도가 느려집니다.

우리가 사용하는 것으로 xfs 만 지원하며 xfs_freeze는 파일 시스템에 대한 새로운 액세스를 중단하고 디스크에서 안정적인 이미지를 생성 할 수 있습니다.

쓰기시 복사 가 사용되므로 디스크 공간이 효율적으로 사용됩니다.

스냅 샷을위한 여유 공간이있는 논리 볼륨에 파일 시스템을 작성했습니다.

이것은 FAQ의 예입니다