소규모 팀에서 재해 복구는 대개 아무도 열어 본 적 없는 문서 안의 한 줄로 끝납니다. 백업은 켜져 있습니다, 라는 문장입니다. 그 문장은 사실이지만 어떤 질문에도 답이 되지 못합니다. 되찾은 데이터가 얼마나 오래된 것인지, 복원에 얼마나 걸리는지, 지금까지 누가 한 번이라도 끝까지 복원을 해 본 적이 있는지에 대해 아무것도 말해 주지 않기 때문입니다.

백업을 가지고 있다는 사실과 실제로 복구할 수 있다는 사실 사이의 간격에서 대부분의 장애는 심각한 사고로 바뀝니다. 존재하고, 최신이며, 한 번도 복원해 본 적 없는 백업은 아직 가설일 뿐입니다. 그리고 그 가설을 처음 검증하는 순간은 가설이 틀렸다는 사실을 알기에 가장 나쁜 순간입니다.

두 개의 숫자가 의견을 계획으로 바꿉니다. 데이터를 얼마나 잃어도 감당할 수 있고, 얼마나 오래 멈춰 있어도 감당할 수 있습니까? 그것이 바로 여러분의 복구 시점 목표와 복구 시간 목표입니다. 사업 쪽에서 누군가 이 두 숫자를 말하기 전까지, 백업 주기에 대한 모든 기술적 논쟁은 결론이 나지 않습니다. 무엇에 비추어 옳고 그름을 따질 기준 자체가 없기 때문입니다.

RPO와 RTO를 쉬운 말로

복구 시점 목표, 즉 RPO는 잃어도 되는 데이터의 양입니다. 야간 백업만 돌린다면 RPO는 24시간이 됩니다. 오후 17시에 장애가 나면 전날 밤 이후에 쌓인 모든 데이터가 사라진다는 뜻입니다. 그것이 받아들일 수 없는 수준이라면 백업 일정 자체가 잘못된 것이고, 다른 영역에서 아무리 공을 들여도 이 손실은 메워지지 않습니다.

복구 시간 목표, 즉 RTO는 멈춰 있어도 되는 시간입니다. 여기에는 모든 단계가 들어갑니다. 장애를 알아차리고, 결정을 내리고, 자원을 확보하고, 복원하고, 검증하고, 트래픽을 다시 돌리는 일까지 전부 포함됩니다. 많은 팀이 복원 단계만 계산하고 나머지 다섯 단계를 잊어버리며, 실제 복구가 예상보다 몇 배씩 오래 걸리는 이유가 정확히 여기에 있습니다.

두 지표 모두 기술적 결정이 아니라 사업적 결정이며, 기준을 조일수록 비용이 늘어납니다. RPO를 5분으로 잡으면 지속적인 복제가 필요합니다. RTO를 1시간으로 잡으면 자동으로 다시 구축되는 인프라가 필요합니다. 압박이 심한 상황에서 한 시간 안에 서버를 손으로 설정할 사람은 아무도 없기 때문입니다.

생산적인 대화는 결국 맞바꿈에 관한 대화입니다. 각 수준을 달성하는 데 비용이 얼마나 드는지 사업 쪽에 알려 주고 직접 고르게 하십시오. 엔지니어링 안에서 숫자를 정해 놓고, 그 숫자가 한 번도 언급된 적 없는 기대치와 맞아떨어지기를 바라는 방식보다 훨씬 낫습니다.

시험하지 않은 백업은 백업이 아닙니다

정말 아픈 실패는 백업이 없어서 생기는 경우가 드뭅니다. 대부분은 정작 필요한 순간에 쓸 수 없는 것으로 드러난 백업 때문에 생깁니다.

흔한 원인은 다음과 같고, 하나같이 복원해 봐야만 드러납니다. 아무도 실패만큼 성공을 들여다보지 않아서 작업이 몇 주째 조용히 실패하고 있습니다. 덤프가 스키마는 담았지만 데이터는 담지 못했거나, 누군가 예전에 제외 목록에 올려 둔 탓에 일부 테이블만 담겼습니다. 파일은 암호화되어 있는데 그 키가 하필 죽어 버린 바로 그 장비에 저장되어 있습니다. 백업이 자신이 보호해야 할 대상과 같은 계정이나 같은 리전에 놓여 있습니다.

마지막 항목은 예전보다 훨씬 무겁게 다뤄야 합니다. 운영 환경과 같은 곳에 있는 백업은 하드웨어 고장만 막아 줄 뿐 그 외에는 아무것도 막아 주지 못합니다. 계정 탈취에서도, 계정 수준의 실수 삭제에서도, 같은 자격 증명이 닿는 모든 것에 닿아 버리는 랜섬웨어에서도 살아남지 못합니다.

백업이 동작한다는 사실을 확인하는 유일한 방법은 실제로 복원해 보는 것입니다. 일정에 넣고, 최소한 분기에 한 번은 수행하고, 걸린 시간을 재십시오. 그렇게 측정한 시간이 문서에 적힌 숫자가 아니라 여러분의 진짜 RTO입니다.

재해 복구가 반드시 다뤄야 하는 것

데이터는 누구나 떠올리는 부분이고 오히려 느린 부분인 경우는 드뭅니다. 복구를 길게 늘어뜨리는 것은 거의 언제나 아무도 목록에 적어 두지 않은 항목들입니다.

데이터베이스는 모두가 기억합니다. 업로드된 파일은 어딘가 별도의 저장소에 있으며 아예 백업이 없는 경우가 흔합니다. 설정과 비밀 값은 운영 중인 장비 위에만 존재하는 일이 잦습니다. DNS와 인증서는 그것을 보관한 계정이 바로 잃어버린 대상일 때 빠르게 다시 만들 수 없습니다. 인프라 자체, 즉 서버와 네트워크와 규칙은 코드로 정의되어 있으면 금방 되살아나지만 클릭으로 만들어졌다면 고통스러울 만큼 느립니다.

그리고 이 모든 것이 어떻게 맞물리는지에 대한 지식은 소규모 팀에서 복구 시간을 결정하는 가장 큰 단일 요인입니다. 한 사람이 기억만으로 다시 세울 수 있는 시스템의 복구 시간은 그 사람이 연락되는지 여부와 같습니다. 그것은 계획이라고 부를 수 없습니다.

계획보다 목록을 먼저 쓰십시오. 대부분의 팀은 그 목록을 만드는 도중에 백업이 전혀 없는 구성 요소를 최소한 하나는 발견하며, 이런 방식으로 발견하는 편이 다른 방식보다 비교할 수 없이 저렴합니다.

한 장에 담기는 계획

사고가 진행되는 동안 긴 문서는 아무도 읽지 않습니다. 지친 사람이 새벽 세 시에 생각하지 않고도 따라갈 수 있는 수준을 목표로 삼으십시오.

계획에는 다음이 들어가야 합니다. 복구가 시작되었다고 누가 선언하는지가 필요합니다. 이 상황이 재해에 해당하는지 망설이는 시간은 지연의 가장 흔한 원인이기 때문입니다. 백업이 어디에 있고 어떻게 접근하는지도 필요하며, 여기에는 무너진 시스템에 의존하지 않는 자격 증명이 포함됩니다. 복원 절차는 순서대로, 즉흥적인 판단 없이 따라갈 수 있을 만큼 구체적으로 적어야 합니다. 성공 여부를 확인하는 방법도 필요한데, 사이트가 열리는 것 같다는 느낌이 아니라 구체적인 점검이어야 합니다. 그리고 내부와 외부에 각각 누구에게 알릴지도 적어야 합니다.

장애에서 살아남는 장소에 보관하십시오. 복구 대상 시스템 안에만 저장된 복구 계획은 반복해서 나타나는, 그리고 완전히 피할 수 있는 실수입니다.

같은 논리가 접근 권한에도 적용됩니다. 호스팅 계정의 자격 증명을 한 사람만 쥐고 있다면 여러분의 복구 시간은 그 사람이 전화를 받는지에 따라 정해집니다. 리눅스 서버 하드닝 가이드 에서 이 모든 것이 기대고 있는 접근 통제를 다룹니다.

완벽함이 아니라 적정함

소규모 팀에 두 번째 리전의 핫 스탠바이는 필요하지 않습니다. 비용은 실제로 발생하고, 늘어난 복잡도는 그 자체로 새로운 고장 유형을 만들어 냅니다.

대부분의 소규모 팀에게 실제로 필요한 것은 훨씬 저렴합니다. 운영 환경이 사용할 수 없는 자격 증명으로 접근하는 별도 계정의 백업, 일정에 따라 시험하고 시간을 잰 복원, 발굴 작업 없이 다시 만들 수 있도록 코드로 정의된 인프라, 그리고 실제로 누군가 읽어 본 한 장짜리 계획이면 충분합니다.

이 조합은 하드웨어 고장, 실수로 인한 삭제, 계정 탈취, 랜섬웨어를 모두 덮으며 이것이 실제로 벌어지는 일의 대부분입니다. 그 이상은 다운타임을 조금 더 줄이는 데 얼마를 지불할 가치가 있는가에 대한 결정이고, 그 질문은 엔지니어링이 아니라 사업 쪽이 답해야 합니다.

Mecanik은 서버 보안 분석 과정에서 이 내용을 점검하고 직접 구축합니다. 첫 질문은 언제나 같으며 기술과는 상관이 없습니다. 얼마나 오래 멈춰 있을 수 있으며, 그 숫자는 누가 결정했습니까?

관련 게시물: 의미 있는 업타임 SLA , 소규모 팀을 위한 소프트웨어 공급망 보안 , 비즈니스 AI 에이전트: 비용과 실패 지점 그리고 영국 핀테크 소프트웨어 개발: FCA, 레일, 비용 .

자주 묻는 질문

RPO와 RTO는 무슨 뜻입니까? 복구 시점 목표는 잃어도 감당할 수 있는 데이터의 양이며, 따라서 야간 백업만 돌린다면 RPO는 24시간이 됩니다. 복구 시간 목표는 멈춰 있어도 감당할 수 있는 시간이며 장애를 알아차리고, 결정하고, 자원을 확보하고, 복원하고, 검증하고, 트래픽을 되돌리는 과정을 모두 포함합니다. 둘 다 사업적 결정이고, 둘 다 기준을 조일수록 비용이 커집니다.

시험하지 않은 백업이 왜 백업이 아닙니까? 고장의 양상이 복원할 때에만 드러나기 때문입니다. 아무도 실패만큼 성공을 지켜보지 않으면 작업은 몇 주째 조용히 실패하고, 덤프는 데이터 없이 스키마만 담거나 제외된 테이블을 빠뜨리며, 암호화 키는 죽어 버린 장비에 남아 있고, 복사본은 자신이 보호할 대상과 같은 계정에 놓여 있습니다. 분기마다 복원하고 시간을 재십시오.

백업은 어디에 보관해야 합니까? 운영 환경이 사용할 수 없는 자격 증명과 함께 별도의 계정이나 별도의 리전에 보관해야 합니다. 같은 환경에 있는 백업은 하드웨어 고장만 막아 줄 뿐 그 외에는 아무것도 막지 못합니다. 계정 탈취에서도, 계정 수준의 삭제에서도, 같은 자격 증명이 닿는 모든 것에 닿는 랜섬웨어에서도 살아남지 못합니다.

재해 복구에서 사람들이 빠뜨리는 것은 무엇입니까? 데이터베이스와 분리되어 저장된 업로드 파일, 운영 중인 장비에만 존재하는 설정과 비밀 값, 그 자체로 잃어버릴 수 있는 계정에 보관된 DNS와 인증서, 코드로 정의되지 않고 클릭으로 만들어진 인프라, 그리고 단 한 사람만 알고 있는, 전체가 어떻게 맞물리는지에 대한 지식입니다.

소규모 팀에 핫 스탠바이가 필요합니까? 대개 필요하지 않습니다. 비용은 실제로 발생하고 늘어난 복잡도는 그 자체의 고장 유형을 데려옵니다. 별도 계정의 백업, 시험하고 시간을 잰 복원, 코드로 정의된 인프라, 그리고 누군가 읽어 본 한 장짜리 계획이면 하드웨어 고장과 실수로 인한 삭제, 계정 탈취, 랜섬웨어까지 실제로 벌어지는 일의 대부분을 덮습니다.