Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
데이터ㆍ분석 / 보안

데이터 복구가 백업보다 오래 걸리는 5가지 이유

W. Curtis Preston | Network World 2022.05.03
데이터 복구 속도가 백업 속도보다 느리다는 데 놀라는 사람들이 많지만 알고 보면 전혀 놀라운 일이 아니다. 오히려 이 시간 차이를 백업 계획에 반영해야 한다. 복구 속도가 일반적으로 백업보다 느린 데는 몇 가지 이유가 있다.
 
 ⓒ Getty Images Bank
 

RAID 쓰기 페널티

대부분의 현대 디스크 어레이는 패리티(parity) 기반의 독립 디스크 중복 어레이(RAID)인 RAID 레벨 3~6을 사용해 구축한다. 그 외에 이레이저 코딩(erasure coding)을 사용하는 방법도 있는데 직면하는 어려움은 패리티 기반 RAID와 비슷하다.

패리티 기반 RAID는 어레이에 데이터를 쓸 때 패리티 정보를 계산해야 한다. 같은 어레이에서 데이터를 읽을 때는 이 계산이 불필요하다. 그래서 쓰기보다 읽기 속도가 훨씬 더 빠르다. RAID 레벨 또는 이레이저 코딩에 사용된 설정에 따라서 쓰기 성능 페널티는 미미할 수도, 상당히 클 수도 있다. 어쨌든 이와 같은 어레이에서 얼마간의 쓰기 패널티는 필연적이므로 각자의 환경에서 어느 정도인지 확인해야 한다.
 

쓰기 시 복사(copy-on-write) 스냅샷

쓰기 시 복사 스냅샷을 사용하는 어레이와 NAS 파일러에도 쓰기 페널티와 비슷한 개념이 적용된다. 쓰기 시 복사 스냅샷을 생성한다는 것은 간단히 비유하면 참조 지점으로 삼을 막대기를 땅에 꽂는 것과 같다. 스냅샷이 처음 생성될 때는 거의 아무런 I/O도 일어나지 않고 모든 무거운 작업은 그 뒤에 실행된다. 스냅샷을 위해 저장해야 하는 블록을 쓰기가 덮어쓰려고 시도할 경우 먼저 해당 블록을 스냅샷 영역으로 복사한 후 쓰기가 허용된다(그래서 '쓰기 시 복사'라고 함)

이 현상은 RAID 쓰기 페널티와 마찬가지로 쓰기에서만 발생한다. 특정 볼륨에 보관 중인 스냅샷의 수에 따라 스냅샷 페널티 역시 상당히 커질 수 있다. 스냅샷이 많을수록 각 쓰기가 진행되기에 앞서 개별 블록을 복사해야 할 가능성도 커진다. 따라서 쓰기 시 복사 볼륨에 스냅샷의 수가 많을수록 새 데이터를 쓸 때의 성능은 저하된다.
 

파일 시스템 안에 쓰기

그다음 쓰기 페널티는 파일 시스템 안에 쓸 때, 특히 이 파일 시스템이 수많은 파일로 혼잡한 상황일 때 발생한다. 파일을 복구하는 경우 파일 시스템은 먼저 이 데이터를 복원할 파일을 만들어야 한다. 파일 생성은 파일의 크기와 관계없이 시간이 소요되는 별도의 작업이다. 복구할 파일일 수백만 개에 이르는 경우 이 파일 생성에 드는 시간이 복원 자체보다 더 길 수 있다.
 

트랜잭션 로그 과부하

관계형 데이터베이스에는 데이터베이스에 대한 모든 변경을 기록 추적하는 트랜잭션 로그가 있다. 데이터베이스가 트랜잭션 로그에 트랜잭션을 빠르게 기록하는 성능은 대부분의 데이터베이스 설계에서 일반적으로 신경 써야 할 부분은 아니다. 그러나 대규모 복원은 일상적인 경우에 비해 훨씬 더 많은 수의 초당 트랜잭션을 생성할 수 있고 이에 따라 트랜잭션 로그에 대한 부하가 평상시보다 훨씬 더 커질 수 있다. 따라서 트랜잭션 로그가 복구 속도를 저하할 수 있다.
 

백업 스트림 멀티플렉싱

복구가 백업보다 느린 마지막 이유는 바로 필요악인 멀티플렉싱이다. 그나마 다행은 멀티플렉싱 페널티는 테이프에서 바로 복원하는 경우에만 해당한다는 것이다. 백업 시스템이 디스크 기반이라면 이 문제는 발생하지 않는다. 사실 이것이 지난 20년 사이 많은 기업이 테이프를 버린 주요 이유다.

이 문제를 이해하려면 테이프 드라이브의 가장 큰 문제를 생각하면 된다. 바로 필요보다 훨씬 더 빠른 속도다. 현대의 스트리밍 테이프 드라이브는 보편적인 증분 백업 속보보다 10~20배 더 빠르다. 이 격차를 해결하기 위해 업계에서 고안한 방법이 여러 백업 스트림을 테이프 드라이브와 보조를 맞출 만큼 빠른 하나의 스트림으로 엮는 멀티플렉싱이다. 20년 전에 멀티플렉싱이 고안되었을 당시 대부분의 현업 종사자들은 다른 선택지는 없다고 생각했다. 성공적인 백업을 위해서는 테이프 드라이브의 특성에 맞추는 수밖에 없었기 때문이다.

멀티플렉싱된 테이프에서 복원할 때 백업 소프트웨어는 전체 테이프를 읽은 다음 필요한 스트림 하나를 제외한 나머지를 모두 버려야 한다. 멀티플렉싱 설정이 10이라면 테이프 드라이브는 10개의 스트림을 모두 읽고 그중 9개를 버려야 한다. 이는 복원 속도에 크게 영향을 미친다. 여기에 위의 쓰기 페널티 중 하나까지 추가되면 상황은 더 악화한다. 디스크 드라이브가 테이프 드라이브의 읽는 속도에 맞출 만큼 빠르게 데이터를 쓰지 못하면 테이프 드라이브는 디스크 드라이브가 따라올 수 있도록 멈췄다가 작동한다.
 

복구 지연을 점검하고 기대치 설정하기

각자 환경에서 복구 속도 페널티가 어느 정도인지 파악한 다음 이를 백업 설계에 반영하는 것이 중요하다. 다양한 유형의 데이터와 이 데이터를 복원할 다양한 유형의 시스템을 대상으로 복구 테스트를 해보자. 여기에는 데이터센터에서 사용 중인 모든 RAID 유형, 모든 대용량 파일 서버 등이 포함된다. 복구 속도가 어느 정도인지 확인한 다음 복구 속도를 더 빠르게 하기 위해 할 수 있는 일이 있는지 업체에 문의하면 된다.

할 수 있는 일이 없다면 대규모 복원에 대한 정확한 기대치를 설정한다. 중요한 파일 서버를 복원하는 데 소요되는 시간을 주제로 회의를 열어 관련 직원에게 오랜 시간이 걸리는 이유를 설명한다. 할 수 있는 일이 없다는 부분을 설명하는 데는 업체의 도움이 필요할 수도 있다. 각 상황에 따라 현실을 받아들이거나 완전히 다른 백업 기술로 전환하면 된다.

중요한 것은 복구가 필요해지기 훨씬 전에 이 모든 일을 해야 한다는 것이다. 금요일 밤 10시에 갑자기 이런 문제로 고민해야 하는 상황은 누구도 원치 않을 것이다. 지금 할 수 있는 최대한 많은 복원 테스트를 하면서 복원이 백업보다 얼마나 느린지를 확인하고 그에 따라 설계와 기대치를 적절히 조정해야 한다.
editor@itworld.co.kr
 Tags 복구 백업 데이터
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.