백업은 있는데 왜 복구가 안 되는가

백업 관련 화면을 열어 보면 대개 안심하게 됩니다. 어제도, 그저께도, 지난주 내내 작업이 초록색 성공으로 찍혀 있기 때문입니다. 그런데 그 화면이 답해 주는 것은 “복사본이 만들어졌는가”이지 “그 복사본으로 되살릴 수 있는가”가 아닙니다. 두 질문은 붙어 있는 것처럼 보이지만, 실제로 복구가 필요한 순간에 갈라집니다.

이 글은 불안을 파는 글이 아니라, 백업을 믿는 근거를 확인 가능한 것으로 바꾸는 법에 관한 글입니다. 백업이 있는데도 복구가 막히는 자리는 사고가 아니라 구조로 정해져 있습니다. 그 자리들을 하나씩 짚고, 마지막에 실제로 되는지 미리 확인하는 방법까지 정리합니다.

”백업은 있으니 괜찮다”가 위험한 이유

백업이 존재한다는 사실과 복구가 된다는 사실 사이에는 여러 단계가 있습니다. 복사본을 만드는 일은 그 단계 중 첫 칸일 뿐이고, 정작 복구가 필요한 순간에는 첫 칸 이후의 조건들이 한꺼번에 요구됩니다.

• 되돌리려는 시점이 아직 남아 있는가
• 복사본이 참조하는 다른 리소스와 암호화 키에 접근할 수 있는가
• 복구된 리소스로 연결을 다시 이을 준비가 돼 있는가
• 원본이 있던 곳이 통째로 사라져도 백업은 다른 곳에 남는가

이 조건들은 백업 작업이 성공했는지와 무관하게 평소에는 드러나지 않습니다. 확인하지 않으면 모든 것이 정상으로 보이고, 확인이 필요한 순간은 이미 늦은 순간입니다. 그래서 백업 화면의 초록색은 “복구가 된다”가 아니라 “복사는 됐다”로 읽는 편이 정확합니다.

아래에서 복구가 막히는 자리를 네 갈래로 나눠 봅니다. 실제 상황에서는 이 중 여럿이 겹쳐서 나타나는 경우가 많습니다.

원인 1. 보존 기간 밖의 시점

되돌리려는 순간이 이미 지나 사라졌을 수 있습니다. 백업에는 대개 보존 기간이라는 창이 있고, 그 창을 벗어난 시점으로는 되돌릴 수 없습니다.

Amazon RDS의 자동 백업을 예로 들면, 설정된 보존 기간 안에서만 특정 시점으로 복구할 수 있습니다. AWS Backup의 연속 백업과 특정 시점 복구도 마찬가지로 지정된 창 안의 시점만 대상으로 삼습니다. 창의 길이는 서비스와 설정마다 다르므로 이 글에서 특정 일수를 단정하지는 않습니다. 정확한 값은 각 서비스의 설정 화면에서 확인하시는 편이 맞습니다.

문제는 이 창이 두 방향에서 조용히 어긋난다는 점입니다.

• 손상을 늦게 발견한 경우 — 데이터가 잘못된 것을 며칠 뒤에 알아차렸는데, 정상이던 시점이 이미 창 밖으로 밀려나 있으면 되돌릴 지점 자체가 없습니다. 보존 기간은 “사고가 얼마나 오래 숨어 있을 수 있는가”까지 견딜 만큼 잡아야 의미가 있습니다.
• 규제나 계약이 요구하는 보존과 다른 경우 — 운영 복구용 보존 기간과 법·계약이 요구하는 장기 보관은 목적이 다릅니다. 하나로 뭉쳐 두면 한쪽 기준에 맞추다 다른 쪽이 부족해집니다.

보존 기간은 뒤에 나오는 다른 원인들과 달리 설정으로 비교적 단순하게 조정되는 축입니다. 다만 그렇기 때문에 “기간만 늘리면 복구가 해결된다”는 오해로 이어지기 쉽습니다. 기간은 여러 축 중 하나일 뿐입니다.

원인 2. 숨은 의존성

복구가 막히는 가장 흔하고 까다로운 자리입니다. 백업 하나는 홀로 존재하지 않고, 다른 리소스와 키에 기대어 있습니다. 그 기댄 상대 중 하나가 사라지면 백업이 멀쩡해도 복구는 멈춥니다.

대표적인 의존성은 다음과 같습니다.

• 이미지가 참조하는 스냅샷 — Amazon EBS 스냅샷은 증분 방식으로 저장되지만, 각 스냅샷은 볼륨을 새로 복원하는 데 필요한 정보를 스스로 담고 있어 한 스냅샷을 지워도 나머지 스냅샷의 복원 능력은 그대로 유지됩니다. 의존성이 문제가 되는 것은 그 위에 얹힌 관계입니다. 서버 이미지(AMI)는 특정 스냅샷들에 기대어 만들어지는데, 어떤 AMI가 참조하는 스냅샷이 지워지면 그 이미지로는 더 이상 인스턴스를 띄우지 못하게 됩니다. “쓰지 않는 오래된 스냅샷”처럼 보이던 것이 실은 어떤 이미지의 복원 경로였던 경우가 여기에 해당합니다.
• 암호화 키 — 백업을 암호화했다면 복구 시점에 그 키에 접근할 수 있어야 합니다. 키가 삭제됐거나, 키에 대한 권한이 회수됐거나, 다른 계정·리전에서 복구하려는데 그쪽에서 키를 쓸 수 없으면 복사본은 있어도 열리지 않습니다.
• 주변 구성 — 데이터베이스를 복구할 때는 데이터만 있으면 되는 것이 아니라, 접속을 허용하는 보안 그룹, 파라미터 그룹, 서브넷 그룹 같은 주변 구성이 함께 맞아야 정상적으로 뜹니다. 이들이 사라졌거나 달라져 있으면 복구된 리소스가 떠도 연결이 되지 않습니다.

의존성 문제의 성질은 하나가 막으면 전체가 막힌다는 점입니다. 백업 데이터가 대부분 온전해도 참조 사슬 한 곳이 끊겨 있으면 복구는 그 지점에서 멈춥니다. 부분적으로 되살아나는 것이 아니라 되거나 안 되거나이고, 그 끊김은 백업 작업의 성공 표시에 전혀 나타나지 않습니다. 비용을 줄이려고 오래된 스냅샷을 정리하거나 쓰지 않는 키를 지우는 평범한 운영 작업이, 실은 어떤 이미지의 복원 경로나 암호화된 백업을 여는 열쇠를 조용히 끊고 있는 경우가 여기에 속합니다.

원인 3. 복구는 새 리소스를 만든다

이 자리는 “백업은 됐는데 서비스는 여전히 안 돌아온다”는 상황의 가장 흔한 원인인데, 의외로 잘 설명되지 않습니다.

많은 복구는 원본을 제자리에서 고치는 것이 아니라, 새 리소스를 새로 띄우는 방식으로 동작합니다. RDS의 특정 시점 복구가 대표적입니다. 이 복구는 원본 인스턴스를 그대로 둔 채 새 DB 인스턴스를 만들어 그 시점의 데이터를 올립니다. 원본이 보존되는 것은 안전한 설계이지만, 그만큼 다음이 함께 따라옵니다.

• 새 인스턴스는 새 접속 주소(엔드포인트) 를 갖습니다. 애플리케이션은 여전히 옛 주소를 바라보고 있습니다.
• DNS 레코드, 애플리케이션 설정, 연결 문자열을 새 리소스로 옮기는 절차가 별도로 필요합니다.
• 새 리소스에는 보안 그룹·파라미터 그룹 같은 구성이 자동으로 따라오지 않을 수 있어, 지정해 주지 않으면 접속이 막힙니다.

즉 복구 작업이 “성공”으로 끝나도, 연결을 새 리소스로 넘기는 마지막 단계를 빠뜨리면 데이터는 되살아났지만 서비스는 복구 전 상태에 그대로 머물러 있습니다. 복구 계획에는 “무엇을 되살릴 것인가”만이 아니라 “되살린 것으로 어떻게 갈아탈 것인가”가 반드시 함께 적혀 있어야 합니다. 실제로 이 갈아타는 단계에서 시간이 가장 많이 소요되는 경우가 잦습니다.

원인 4. 백업이 있는 곳이 원본과 같다

백업이 원본과 같은 계정, 같은 리전에만 있으면, 그 계정이나 리전이 통째로 문제가 되는 상황에서 원본과 백업을 함께 잃습니다. 백업의 목적이 “원본이 사라졌을 때 대비”인데, 원본과 운명을 같이하는 자리에 두면 그 목적이 성립하지 않습니다.

AWS는 이 위험을 줄이는 두 가지 축을 제공합니다.

• 교차 리전 복사 — 백업을 다른 리전으로 복사해 두면 한 리전에 국한된 사고에서 다른 리전의 복사본으로 복구할 수 있습니다. 다만 한 가지 함정이 있습니다. EBS 스냅샷의 경우, 원본과 다른 암호화 키로 리전 복사를 하면 그 복사본은 증분이 아니라 전체 복사가 되어, 저장 시간과 비용이 더 들 수 있습니다. 교차 리전을 설계할 때 키 구성을 함께 정해야 하는 이유입니다.
• 교차 계정 복사 — 백업을 다른 계정으로 복사해 두면, 원본 계정 자체가 침해되거나 권한이 잘못돼 리소스가 삭제되는 상황에서도 별도 계정에 남은 복사본으로 복구할 수 있습니다. 계정 단위의 사고나 랜섬웨어를 상정할수록 이 격리가 중요해집니다.

여기서도 앞서 나온 의존성 문제가 겹칩니다. 다른 리전·계정에서 복구하려면 그쪽에서 암호화 키를 쓸 수 있어야 하고, 필요한 권한이 미리 부여돼 있어야 합니다. “복사본은 다른 곳에 있는데 그 곳에서 열 수 없는” 상태가 생기지 않도록, 격리와 접근 권한을 한 쌍으로 함께 설계해야 합니다.

기준이 없으면 성공도 없다 — RTO·RPO

지금까지의 원인들을 점검하려면 먼저 “복구 성공”의 기준이 있어야 합니다. 그 기준을 정하는 두 값이 RTO와 RPO입니다.

• RTO(복구 목표 시간) — 사고가 난 뒤 서비스를 얼마나 빨리 되돌려야 하는가.
• RPO(복구 목표 시점) — 되돌렸을 때 어느 시점까지의 데이터가 살아 있어야 하는가. 바꿔 말하면 얼마만큼의 최근 데이터 손실까지 감당할 수 있는가입니다.

중요한 점은 이 두 값이 AWS가 정해 주거나 보장해 주는 값이 아니라는 것입니다. AWS Well-Architected 프레임워크는 재해 복구 목표를 조직이 정의하는 값으로 설명합니다. 어떤 데이터가 몇 분의 손실도 허용되지 않는지, 어떤 시스템은 반나절 멈춰도 되는지는 서비스의 성격과 사업적 판단에 달려 있고, 그 판단은 조직의 몫입니다.

RTO·RPO를 정하지 않은 상태에서는 복구가 “성공했다”고 말할 근거가 없습니다. 세 시간 만에 되살렸는데 그것이 빠른 것인지 느린 것인지, 어제 자정 시점으로 돌아갔는데 그 손실이 감당 가능한지 판단할 기준이 없기 때문입니다. 그래서 기준을 정하는 일이 백업 구성보다 앞섭니다. 목표가 정해져야 그 목표를 지금 구조가 지킬 수 있는지 검증할 수 있습니다.

되는지 미리 확인하기 — 복구 테스트

앞의 원인들은 모두 한 가지 공통점이 있습니다. 실제로 복구를 해 보기 전에는 드러나지 않는다는 점입니다. 보존 창이 어긋났는지, 의존성이 끊겼는지, 연결을 갈아탈 절차가 빠졌는지, 다른 계정에서 키를 열 수 있는지는 백업 화면을 아무리 들여다봐도 알 수 없고, 복구를 실행해 봐야 확인됩니다.

그래서 복구 테스트는 선택이 아니라 백업 운영의 일부입니다. AWS Backup은 이를 자동화하는 복구 테스트 기능을 제공합니다. 일정에 따라 백업으로 실제 복구를 실행하고, 복구가 완료되는지 확인한 뒤 정리하는 흐름을 사람이 매번 기억하지 않아도 되게 해 줍니다.

테스트를 설계할 때 함께 볼 점이 있습니다.

• 복구만이 아니라 갈아타기까지 확인합니다. 리소스가 떴다는 것과 서비스가 그 리소스로 정상 동작한다는 것은 다릅니다. 가능하면 애플리케이션이 복구된 데이터에 실제로 붙어 동작하는지까지 확인합니다.
• 의존성이 바뀌면 다시 테스트합니다. 암호화 키, 권한, 주변 구성을 크게 바꾼 직후에는 이전 테스트 결과가 더 이상 유효하지 않습니다.
• 테스트는 보장이 아니라 검증입니다. 복구 테스트는 복구 가능성을 높이는 확인이지 절대적인 보장이 아닙니다. 다만 테스트를 하지 않는 것과 하는 것 사이의 차이는 큽니다. 하지 않으면 복구 여부를 사고 순간에 처음 확인하게 됩니다.

복구를 비용 관점에서만 정리하다 보면 요건을 놓치기 쉽습니다. 스냅샷과 보존 정책을 비용 기준으로 다루는 이야기는 AWS 비용 점검 체크리스트에서 다루는데, 그 글도 비용만으로 스냅샷을 정리하면 복구 요건을 조용히 깨뜨릴 수 있다는 데서 끝맺습니다. 비용과 복구는 같은 대상을 서로 다른 축으로 보는 문제이므로, 두 축을 함께 놓고 판단하시는 편이 안전합니다.

어디서부터 함께 봐야 하는가

복구는 혼자 점검할 수 있는 부분과, 구조가 얽혀 있어 함께 봐야 하는 부분이 갈립니다. 다음과 같은 상황이라면 내부 점검만으로는 사각지대가 남기 쉽습니다.

• 계정·리전이 여러 개로 나뉘어 있을 때 — 교차 계정·교차 리전 복구는 백업뿐 아니라 키와 권한이 여러 경계에 걸쳐 정확히 놓여야 동작합니다. 경계가 많아질수록 “어디선가 하나가 빠진” 상태를 스스로 발견하기 어려워집니다.
• 규제·계약상 보존 요건이 있을 때 — 운영 복구용 보존과 장기 보관 요건이 섞여 있으면, 한쪽 기준을 지키는 설정이 다른 쪽을 침해하지 않는지 함께 검토해야 합니다.
• 대규모 데이터베이스나 상태가 얽힌 시스템일 때 — 복구에 걸리는 시간과 갈아타는 절차가 길어질수록 RTO를 지키기 위한 사전 설계가 중요해집니다.
• 복구를 한 번도 실제로 해 본 적이 없을 때 — 이 경우 가장 먼저 필요한 것은 새 도구가 아니라, 지금 구조로 복구가 되는지 한 번 확인해 보는 일입니다.

복구는 사실 장애 대응의 마지막 단계입니다. 누가 먼저 확인하고 무엇을 기록으로 남기는지가 정리돼 있지 않으면 복구 단계에서 판단이 늦어지는데, 그 앞선 단계는 AWS 장애 대응의 역할과 기록에서 따로 다룹니다.

이 영역은 백업 상품을 새로 파는 문제가 아니라 운영 구조를 읽는 문제에 가깝습니다. 반복되는 장애나 구조적으로 막힌 지점을 먼저 규명하고 싶다면 AWS 장애·안정화 — 운영 구조 진단에서 단건으로 다루는 방식을 보실 수 있고, 백업과 모니터링을 상시로 맡기는 방식이 궁금하다면 AWS 관리 대행 서비스 범위에서 감시·점검·보고가 어떻게 나뉘어 있는지 확인해 보십시오.

다음 단계

백업이 있는지가 아니라 복구가 되는지를 확인하는 것이 순서상 먼저입니다. AWS 무료 점검은 계정 접근 권한을 먼저 요구하지 않고 짧은 상담으로 지금 구조에서 무엇부터 봐야 할지 정리해 드립니다. 백업·복구 구조의 빈칸이 어디인지부터 함께 짚을 수 있고, 정리된 내용은 이어서 맡기지 않으셔도 그대로 가져가실 수 있습니다.

복구가 이미 막힌 경험이 있거나 운영 구조에서 반복되는 문제가 의심된다면 AWS 장애·안정화 서비스를 먼저 보시고, 우리 환경에 맞춰 복구 가능성을 점검하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• Amazon RDS — 특정 시점으로 DB 인스턴스 복원
• AWS Backup — 연속 백업과 특정 시점 복구(PITR)
• Amazon EBS — 스냅샷의 증분 동작
• AWS Backup — 교차 리전 백업
• AWS Backup — 교차 계정 백업
• AWS Well-Architected 신뢰성 필라 — 재해 복구 목표(RTO·RPO)
• AWS Backup — 복구 테스트