altair의 프로젝트 일기
LTO6 드라이브, 백업, 그리고 아카이빙에 관해서 본문
LTO


이번에 LTO6 드라이브와 테이프들을 중고로 구매해 사용해보았다. 굉장한 밀도로 저장하는 데이터 저장 매체를 경험하는 것도 흥미로운 일이었지만, 그 안에 여러 데이터들을 저장해보며 데이터 저장에 대한 생각을 정리하는 기회가 되었다. 특히, 매우 큰 용량을 저장할 수 있지만 retrieve가 굉장히 느린(극단적으로 느린 테이프의 랜덤 탐색 속도 뿐만 아니라 직접 손으로 테이프를 찾아 넣어야 한다) 매체에 어떤 데이터를 저장해야 하는지 많은 고민을 하게 되었다.
그럼에도 추가적인 저장소가 필요하다면 LTO보다는 HDD(NAS) 쪽을 고민하지 않을까 싶다. 다음과 같은 이유다.
- 초기 비용: HDD는 훨씬 범용적인 방법(SATA, SAS)으로 연결 가능하다. 이는 결국 저렴한 초기 구축 비용으로 이어진다.
- 가격 대비 용량: LTO는 분명 HDD보다 높은 용량 밀도를 자랑하지만, 그게 비용적 메리트를 가지려면 용량 밀도로 인한 이익이 위의 초기 비용을 넘어서야 한다. 최신 LTO드라이브는 어마어마하게 비싸므로 개인 단위 데이터로는 그 지점을 넘을 수 없으며, 저렴한 옛날 LTO(4~6)는 HDD와 가격 대비 용량이 크게 다르지 않다. HDD 또한 용량 밀도가 충분히 높아졌다.
- 관리: 테이프는 의외로 온습도 관리가 필요하다. 그리고 고장나면 바로 알 수 있는 HDD와 다르게 오프라인 저장 매체이므로 조용히 죽어도 알 방법이 없다.
굳이 HDD보다 LTO를 사용해야 한다면 다음과 같은 이유가 있을 것 같다.
- 전기세: LTO 테이프는 기록된 이후로 전력을 사용하지 않는다. HDD가 많아지면 생각보다 꽤 많은 전력을 소모한다.
- 영상 데이터가 많음: 영상 데이터는 그 특성 상 한 번 파일로 만들어지면 데이터가 변하지 않고, 다른 종류의 파일보다 압도적으로 큰 용량을 차지한다. 어떻게보면 LTO에 저장하기에 최적의 데이터라고 생각한다.
LTO6 테이프에 여러 데이터들을 기록해보며 많은 생각이 들었다. 특히 데이터 저장에 관한 생각을 정리해보고자 한다.
백업의 역설

백업의 개수(x)와 가용성(y)의 관계를 대강 그려보면 위와 같을 것이다. 아무리 많은 백업이 있다고 해도 100%의 가용성을 달성할 수는 없다. 두 HDD에 raid1을 적용하면 한 HDD 고장으로부터는 안전할 것이다. 그러나 고장난 HDD를 새 것으로 교체하고 데이터를 복사하는 도중에 다른 HDD 역시 고장난다면? (raid를 위한 HDD는 보통 한 번에 구매하고, 제조년월이 비슷한 경우가 많으므로, 고장 시기도 비슷할 확률이 높은 편이다) 이를 위해 raid5나 6를 구성한다면 안전할까? 모든 HDD는 한 곳에 몰려있고, 모든 데이터는 한 종류의 매체에 몰려있다. 다른 곳에 데이터 저장소를 두어 가용성을 확보하거나, 다른 매체에 데이터를 아카이빙하여 보관한다면 훨씬 안정적인 수준을 달성할 수 있다. 그러나 100%는 달성하지 못한다. 제논의 역설이다.
그래서 백업은 돈과 시간을 얼마나 투자할 수 있느냐에 관한 타협이 된다. 돈이 없던 군인 시절에는 HDD 단 하나에 데이터를 저장했지만, 지금은 ZFS와 Raid6, 오프사이트 백업 두 벌을 구성하고 있다. 회사에서는 그 어떤 상황에서도 내려가지 않는 DB와, HA가 실시간으로 수행되는 k8s 클러스터가 돌아가고 있다. 0%에서 50%으로 가용성을 올리는데는 두 배의 투자면 되지만 98%에서 99%, 99.5%에서 99.99995%로 끌어올리는데는 천문학적인 비용이 들어간다. 결국 타협인 것이다.
백업이란 무엇인가?
그렇다면 도대체 백업은 무엇일까? 데이터가 없어지지 않도록 하는 것뿐일까? 난 이 시점에서 백업과 아카이빙이 구분되어야 한다고 생각한다. 아카이빙은 특정 시점의 데이터(스냅샷)를 저장하는 것을 뜻한다. 때문에 데이터의 최신성보다 장기보존성을 우선한다.
예를 들면 조선왕조실록의 분산 저장은 백업이라기보다 아카이빙이다. 비록 최신 문서들은 아니지만(그럴 필요도 없고) 과거의 문서들이 소실되지 않도록 한 것이기 때문이다. 한편, MySQL의 master-slave 구성은 백업이다. master가 손실되어도 slave가 최신 데이터를 갖고 있으니 바로 master 대신 투입될 수 있기 때문이다.
방송국이나 치지직 스트리머가 영상을 저장해놓는 것은 아카이빙이다. 고객의 데이터를 여러 벌로 저장해놓는 것은 백업이다. 데이터를 관리할 때는 이 구분이 중요하다고 생각한다.
왜 백업과 아카이빙을 구분해야 하는가?
만약 특정 시점의 고객데이터를 영원히 보존 가능한 매체에 저장한다고 상상해보자. 그 데이터가 과연 의미가 있을까? 단 몇 시간만 지나도 그 데이터들은 가치를 잃어버리기 시작한다. 새 데이터들은 포함하지 않았기 때문이다. 사고가 일어나고 과거의 데이터로 복원해봤자 그 사이 간극은 영원히 매울 수 없다.
반대로, 방송국이 가장 최신 데이터를 여러 벌로 복사해놓는다면 의미가 있을까? 가장 최신의 데이터는 지금 방송하고 있는 화면 이미지일 것이고, 최신 데이터는 끊임없이 변하는 이미지파일에 불과할 것이다. 현재 방송 화면 이미지는 아무런 가치를 갖지 않는다. 오히려 과거 특정 시점의 방송화면의 나열이 훨씬 의미있는 데이터일 것이다. 언뜻보면 별 다를게 없어보이는 백업과 아카이빙은 이렇게 극명한 차이를 보인다.
그렇다면 각자의 데이터를 관리하는 데이터 관리자인 우리는 무엇을 해야 하는가?
관리하는 데이터에 대한 명확한 인식
평생 바뀌지 않을, 그러나 평생 보관해야 하는 가족사진들을 Raid6로 보관하는 것은 불필요한 짓이고, 작업하고 있는 문서 파일을 LTO 테이프에 기록하는 것 역시 미친 짓이다. 가장 먼저 자신이 관리하는 데이터가 어떤 종류인지 인지해야 한다. 물론 둘 다인 경우가 많겠지만.
나의 경우도 둘로 명확히 나눌 수 있었다. 어머니가 평생 찍어오신 사진들의 스캔 이미지들과 내 일기들, 중고등학교부터 쌓여온 문서, 이미지 데이터들이 한 부류이고, 다른 한쪽에는 토이 프로젝트의 소스코드, 주기적으로 백업되는 친구들의 게임서버 세이브 파일, LXC를 위한 템플릿들이 있었다. 전자의 데이터는 NAS와 아카이브 매체에 저장하면 된다. 영원히 바뀌지 않을 파일이니까. 후자는 RAID6 NAS와 Gitea, S3 등에 복사해 저장하면 된다. 데이터가 둘 중 어떤 곳에 속하는지 명확하게 분리할 수 있다면 비용을 효율적으로 투자할 수 있다.
개인의 차원에서 생각해보자. 내가 좋아하는 유튜버의 영상을 SSD나 HDD처럼 값비싼 저장소에 저장해야할지, 아니면 M-DISC나 테이프처럼 장기 보관용 저장소에 기록해야할지 고민하는 것은 의미가 없다. 유튜브에서 항상 접근할 수 있으며, 시간이 지나면 흥미조차 식어버리는 데이터를 내가 직접 저장하겠다는 결정 자체가 잘못된 것이다.
개인 데이터 10TB 중 가족 사진 같은 매우 중요한 데이터가 100GB 뿐이라면 단지 USB나 BD로 여러 곳에 분산 저장하는 것만으로도 충분한 안정성을 확보할 수 있다. 데이터 분류는 이렇게 저장 비용을 낮추어 결과적으로 데이터 안정성까지 증가시키곤 한다.
교훈
상병 시절 부대에서도 집에 있는 데이터에 접근하기 위해 라즈베리파이로 처음 NAS를 만들었다. 그 후 지금까지 많은 데이터들을 관리해보면서, 백업에 있어 가장 중요한 것은 데이터 저장 그 자체보다 데이터 분류라는 것을 깨달았다.
요새 데이터 관련 팀에서 정말 큰 데이터셋들을 마주하곤 하는데 그럴 때마다 그 뒷단에서 어떻게 그런걸 다 저장할지 궁금하곤 했다. 최근 DAN25에 참여해 스토리지 기술 관련 세션을 들었는데 나름의 궁금증이 풀리는 시간이었다. 앞으로는 데이터 저장뿐만 아니라 데이터 처리에 관한 기술(특히 하둡과 스파크)들도 공부하고 싶다는 마음이 들었다.
'IT > 서버' 카테고리의 다른 글
| K8s 와 VM, 그리고 Proxmox (0) | 2025.12.29 |
|---|---|
| Rocky Linux (or RHEL 계열) VM로 k8s 클러스터 구성하기 (0) | 2025.12.01 |
| 내부망 DNS + reverse proxy 구성하기 (0) | 2025.08.31 |
| Diary 프로젝트 일기 (6) - MySQL DB 다중화 (0) | 2025.05.18 |
| Diary 프로젝트 일기 (5) - 부하테스트 (0) | 2025.05.12 |