스냅샷 복구방식의 이해

스냅샷^Snapshot은 즉각적인 복구를 위해 전체 시스템의 가상 복사본을 만들어서 그 복사본을 원본에 덮어씌우는 방식이다. 잘 설계된 스냅샷 기반 복구 시스템은 매우 큰 볼륨을 몇 분만에 복구시킬 수 있으며 불과 몇 분전의 시점으로도 복구가 가능하다. 반면에 전통적인 방식으로 볼륨을 복원할 경우에는 최소 하루정도의 데이터를 잃고 많은 시간이 걸린다.

두 가지 방식

스냅샷을 만드는 데에는 쓰기 시 복사(Copy-on-write)와 쓰기 시 리디렉션(Redirect-on-write)의 2가지 방법이 있다. 이 2가지 방법은 시스템 성능에 큰 영향을 미치고 스냅샷을 보관하는 기간에도 영향을 끼친다.

모든 스냅샷에는 물리적 복사본이 아닌 가상 복사본이라는 공통된 특징을 공유한다. 보호되는 엔티티(볼륨)에 에러가 발생하면 스냅샷 하나로는 소용이 없다. 따라서 미디어 장애에 대한 보호를 보장받고싶다면 스냅샷을 다른 기기에 백업하거나 복제하는 것은 필수이다(사실상 가상복사본이 아닌 물리복사본을 만드는 것과 동일하다).

쓰기 시 복사 (Copy-on-write)

쓰기 시 복사 시스템은 새 데이터로 블록을 덮어씌우기 전에 블록을 복제한다. 기본적으로 볼륨 내의 블록을 변경해야하는 경우 시스템은 블록을 덮어씌우기 전에 별도의 스냅샷 영역으로 블록을 복사한다. 이 때 RWW로 총 3개의 I/O작업을 수행한다. 블록을 덮어쓰기 전에 읽고(R), 다른 위치에 쓰고(W), 이후 새 데이터를 쓴다(W).

쓰기 시 리디렉션 (Redirect-on-write)

쓰기 시 리디렉션 시스템은 포인터를 사용해 모든 보호되는 엔티티를 나타낸다. 스토리지 시스템에서 블록과 연결된 포인터를 다른 블록으로 리디렉션하고 그 곳으로 데이터를 쓴다. 스냅샷 시스템에서는 특정 스냅샷을 구성하는 모든 블록 위치의 레코드를 유지하는데, 이 때 이것이 사실상 블록 위치에 해당하는 포인터 목록이라고 볼 수 있다. 특정 스냅샷에 액세스하고자 하는 프로세스는 이러한 포인터를 이용해 원래 위치에 블록을 가져올 수 있고 일부 블록이 교체되어 다른 포인터로 표시된다고 해도 스냅샷 프로세스와 아무런 관련이 없다(따라서 스냅샷 읽기에서 계산 오버헤드를 유발하지 않음).

쓰기 시 리디렉션은 쓰기 시 복사에 비해 I/O 작업을 2배가량 줄일 수 있으며(W <=> RWW) 부가적인 계산 오버헤드 또한 없애준다. 이것과 여러가지 이유로 쓰기 시 복사(Copy-on-write) 스냅샷은 일반적으로 백업을 위한 임시 소스로 사용한다.