복구 테스트란 무엇입니까? 예를 들어

회복 테스트란 무엇인가요?

복구 테스트 복구 테스트는 소프트웨어 또는 하드웨어 충돌, 네트워크 오류와 같은 장애 발생 후 소프트웨어가 복구될 수 있는 능력을 검증하는 소프트웨어 테스트 기법입니다. 복구 테스트의 목적은 재해 또는 무결성 손실 후에도 소프트웨어 작업이 지속될 수 있는지 여부를 확인하는 것입니다. 복구 테스트는 소프트웨어를 무결성이 유지되었던 시점으로 되돌리고, 장애 발생 시점까지의 트랜잭션을 다시 처리하는 방식으로 진행됩니다.

소프트웨어 엔지니어링에서 복구 가능성 테스트는 일종의 테스트 유형입니다. 비기능 테스트 — 이는 확장성이나 보안과 같이 특정 기능이나 사용자 동작과 관련되지 않은 측면을 다룹니다. 전문 테스터가 테스트를 수행하며, 사전에 충분한 백업 데이터를 안전한 장소에 보관합니다.

복구 테스트 예

두 가지 시나리오를 통해 이 기법의 가장 간단한 형태를 보여줍니다. 각 시나리오에서는 의도적으로 오류를 발생시킨 후, 애플리케이션이 다시 작동하는 모습을 관찰합니다.

• 네트워크 중단: 애플리케이션이 네트워크에서 데이터를 수신하는 동안 연결 케이블을 뽑습니다. 잠시 후 케이블을 다시 연결하고 연결이 끊어졌던 지점부터 애플리케이션이 데이터를 계속 수신할 수 있는지 분석합니다.
• 세션 복원: 브라우저에 특정 개수의 세션이 열려 있는 상태에서 시스템을 재시작하고, 브라우저가 모든 세션을 복구하는지 확인하십시오.

아래 그림은 같은 개념을 시각적으로 표현한 것입니다.

복구에 소요되는 시간은 다음에 따라 달라집니다.

• 재시작 지점 수
• 애플리케이션이 보유한 데이터 용량
• 회복 활동을 수행하는 사람들의 훈련 및 기술, 그리고 회복에 사용할 수 있는 도구

여러 오류가 발생했을 경우, 복구 테스트는 한꺼번에 모두 수행하기보다는 구조화된 방식으로, 즉 한 부분씩 순차적으로 수행해야 합니다.

복구 프로세스의 수명주기

테스트 케이스를 설계하기 전에 복구 테스트가 어디에 개입하는지 파악하는 것이 도움이 됩니다. 복구 프로세스의 수명 주기는 다섯 단계로 구성됩니다.

1. 정상 작동
2. 재해발생
3. 작업 중단 및 실패
4. 복구 프로세스를 통한 재해 정리
5. 모든 프로세스와 정보를 재구성하여 전체 시스템을 정상 작동 상태로 되돌립니다.

아래 흐름도는 다섯 단계를 순서대로 보여줍니다.

이제 이 다섯 단계를 자세히 살펴보겠습니다.

1. 정상 작동. 공통의 목표를 달성하기 위해 통합된 하드웨어, 소프트웨어 및 펌웨어 시스템은 정해진 기간 내에 중단 없이 설계된 작업을 수행합니다.
2. 재난 발생. 소프트웨어 오작동, 입력 오류로 인한 오작동, 하드웨어 고장으로 인한 충돌, 화재, 도난 또는 파업으로 인한 손상 등 다양한 원인으로 인해 서비스 중단이 발생할 수 있습니다.
3. 혼란과 실패. 이는 가장 고통스러운 단계로, 사업 손실, 관계 악화, 기회 상실, 노동 시간 낭비, 그리고 필연적으로 금전적 손실과 기업 이미지 손실로 이어집니다. 재해 복구 계획은 이러한 단계의 피해를 최소화하는 데 도움이 됩니다.
4. 재난 복구. 백업 계획과 위험 완화 프로세스가 이미 마련되어 있다면 복구에 드는 시간과 노력을 크게 줄일 수 있습니다. 각자의 역할이 사전에 정의된 전담팀은 책임 소재를 명확히 하고 장기간의 업무 중단을 방지합니다.
5. 재건. 이 과정은 모든 폴더와 구성 파일을 재구축하기 위해 여러 차례의 작업 세션을 필요로 할 수 있습니다. 올바른 복구를 위해서는 적절한 문서화와 명확하게 정의된 재구축 프로세스가 필수적입니다.

복원 전략

복구팀은 운영을 정상화하기 위해 중요한 코드와 데이터를 복구하는 자체 전략을 가지고 있어야 합니다. 이 전략은 각 조직이 관리하는 시스템의 중요도에 따라 고유하며, 중요 시스템의 경우 다음과 같은 몇 가지 선택 사항으로 귀결됩니다.

1. 단일 백업 또는 여러 백업
2. 여러 백업을 한 곳에 저장하거나, 여러 곳에 저장할 수 있습니다.
3. 온라인 백업 또는 오프라인 백업
4. 백업은 정책에 따라 자동으로 실행되거나 수동으로 실행될 수 있습니다.
5. 독립적인 복원팀 또는 작업을 수행하는 개발팀

각 선택에는 비용 요소가 있으며, 여러 백업을 사용할 경우 더 많은 물리적 자원을 소비하거나 별도의 팀이 필요할 수 있습니다. 의존성 또한 중요합니다. 기업은 단일 공급업체에 보관하는 코드와 데이터를 통해 취약점에 노출될 수 있으며, 대규모 백업은 이러한 위험을 더욱 가중시킵니다. AWS 정전 사태로 인해 유명 소비자 서비스들이 동시에 중단되는 경우가 반복적으로 발생했습니다. 이러한 상황에서는 독립적인 복구 능력이 매우 중요합니다.

복구 테스트 수행 방법

전략이 정해졌으니, 다음 질문은 테스트 자체를 어떻게 설정할 것인가입니다. 복구 테스트를 수행할 때 다음 사항들을 고려해야 합니다.

• 실제 배포 환경과 최대한 유사한 테스트 환경을 구축하십시오. 인터페이스, 프로토콜, 펌웨어, 하드웨어 및 소프트웨어는 프로덕션 환경과 동일해야 합니다.
• 철저한 테스트는 시간과 비용이 많이 소요될 수 있지만, 동일한 구성으로 완벽한 점검을 수행하는 것은 여전히 ​​중요합니다.
• 가능하다면, 특히 백업을 생성한 컴퓨터와 다른 컴퓨터에 복원하는 경우, 최종적으로 복원할 하드웨어에서 테스트하십시오.
• 일부 백업 시스템에서는 하드 드라이브의 크기가 백업을 가져온 드라이브의 크기와 정확히 동일할 것으로 예상합니다.
• 노후화 관리: 드라이브 기술은 빠르게 발전하므로 오래된 드라이브는 새 드라이브와 호환되지 않을 수 있습니다. 복원을 통해 가상 머신 가상화 소프트웨어는 디스크 크기를 포함하여 기존 하드웨어를 모방할 수 있으므로 도움이 됩니다.
• 온라인 백업 시스템도 테스트 대상에서 예외는 아닙니다. 대부분의 제공업체는 내결함성 스토리지를 통해 미디어 문제로부터 사용자를 보호하므로 오류가 발생하더라도 늦게 드러납니다.
• 온라인 백업 시스템은 매우 안정적이지만, 복원 과정에서 복구, 보안 또는 암호화에 문제가 없는지 확인하기 위해 테스트를 거쳐야 합니다.

회복 훈련은 경기 전반에 걸쳐 진행되기 때문에 이러한 훈련은 보통 다른 훈련과 함께 계획됩니다. 시스템 테스트 단위 수준이 아니라.

복원 후 테스트 절차

데이터 복원은 절반의 과정일 뿐입니다. 복원된 데이터가 실제로 사용 가능한지 검증해야 합니다. 대부분의 대기업은 독립적인 감사 기관에 의뢰하여 정기적으로 복구 훈련을 실시합니다. 포괄적인 재해 복구 계획을 수립하고 테스트하는 데에는 상당한 비용이 소요되므로, 소규모 조직은 백업 및 오프사이트 저장소에 의존하는 경우가 많습니다.

폴더와 파일 복원이 완료되면 다음 검사를 통해 복원이 제대로 되었는지 확인합니다.

• 손상된 문서 폴더의 이름을 변경하여 복원된 사본과 혼동되지 않도록 하십시오.
• 복원된 폴더의 파일 수를 세고, 그 수를 원래 폴더의 파일 수와 비교하십시오.
• 평소에 사용하는 애플리케이션으로 몇 개의 파일을 열고, 데이터가 평소처럼 탐색 및 업데이트되는지 확인하십시오.
• 사진, 파일 등 다양한 유형의 파일을 여러 개 엽니다. MP3크고 작은 여러 문서들이 있습니다.
• 대부분의 파일 및 디렉터리 비교 유틸리티를 사용하십시오. 운영체제 제공하십시오.

자주 묻는 질문