스냅샷은 특정 시점을 나타내는 표현이며, 보호 수준은 구현에 따라 결정됩니다. 백업 전략은 의도적인 보존, 접근 분리, 테스트된 복구를 추가합니다. 일부 스냅샷은 백업이고, 다른 것들은 원본 스토리지에 의존합니다. 삭제, 침해 또는 기본 환경 손실에서 무엇이 살아남는지 물으십시오.
이름을 붙이기 전에 복사본을 설명하십시오.
스냅샷이라는 단어는 특정 시점이 표현되었음을 알려줄 뿐, 복구 가능한 데이터가 어디에 보관되는지 또는 누가 삭제할 수 있는지는 알려주지 않습니다. 원본 스토리지의 파일 시스템 스냅샷과 제공자 관리 블록 스냅샷은 장애 경계가 다를 수 있습니다. 레이블을 보편적 약속으로 취급하지 말고 구현부터 시작하십시오.
AWS는 EBS 스냅샷을 볼륨의 증분 특정 시점 백업으로 문서화합니다. 이는 특정 구현이며, 모든 스냅샷 옵션이 같은 방식으로 동작한다는 증거가 아닙니다. 어떤 서비스든 복원이 원본 볼륨에 의존하는지, 복사본이 기본 장애 도메인을 벗어나는지, 원본이 제거되면 어떻게 되는지 물으십시오.
살아남아야 할 것으로 예상하는 장애를 비교하십시오.
업데이트 후 빠른 롤백과 계정 손실 후 복구는 다른 문제입니다. 로컬 스냅샷은 첫 번째에는 편리할 수 있지만 두 번째에는 분리가 거의 없을 수 있습니다. 독립적인 복사본은 스토리지, 접근, 삭제 경로가 대비하는 사고로부터 충분히 분리된 경우에만 보호를 추가할 수 있습니다.
장애와 필요한 결과를 기록하십시오. 이 예시적 비교는 의사 결정 보조 도구이며 SwissOctet의 기능 목록이 아닙니다. 한 기술이 항상 우월하다는 주장보다 복사본과 통제에 대한 질문을 장려합니다. 실제 결과는 구성과 운영자가 문서화한 복구 프로세스에 달려 있습니다.
| 시나리오 | 스냅샷에 대한 질문 | 백업에 대한 질문 |
|---|---|---|
| 잘못된 애플리케이션 업데이트 | 의도한 시점으로 돌아갈 수 있습니까? | 사용 가능한 복원에 얼마나 걸립니까? |
| 기본 디스크 손실 | 복사본이 해당 디스크에 의존합니까? | 새 스토리지에 복원할 수 있습니까? |
| 관리 계정 침해 | 이 계정이 모든 복사본을 삭제할 수 있습니까? | 삭제 권한이 분리되어 있습니까? |
| 몇 주 후 발견된 오류 | 해당 시점이 여전히 보존되어 있습니까? | 보존 기간이 발견 지연을 포괄합니까? |
애플리케이션 일관성을 확인하십시오.
디스크는 애플리케이션이 파일을 변경하는 동안에도 파일을 캡처할 수 있습니다. 소프트웨어와 스냅샷 프로세스에 따라 결과는 조정된 애플리케이션 상태가 아니라 충돌 일관성 상태를 나타낼 수 있습니다. 읽을 수 있는 파일이 데이터베이스와 관련 업로드가 일치한다는 의미라고 가정하지 마십시오. 애플리케이션 또는 데이터베이스가 문서화한 백업 방법을 사용하십시오.
PostgreSQL의 연속 아카이빙 설계는 차이를 잘 보여줍니다. 복구에는 적절한 기본 백업과 필요한 write-ahead log 파일의 연속 시퀀스가 필요합니다. 데이터베이스가 실행 중일 때 무심코 복사한 디렉터리는 동등한 절차가 아닙니다. 애플리케이션이 데이터베이스 외부에도 파일을 저장한다면 두 데이터셋을 함께 복구하는 방법을 계획하십시오.
보존을 복구 창으로 취급하십시오.
보존 기간은 오류가 발견되지 않은 채 얼마나 오래 남을 수 있는지를 고려해야 합니다. 10일 창은 한 달 후 발견된 실수로 인한 삭제에 도움이 되지 않습니다. 모든 복사본을 무기한 보관하면 비용, 민감 데이터 노출 증가, 불명확한 삭제 정책이라는 다른 문제가 생깁니다. 구체적인 운영 및 데이터 처리 요구사항에 따라 보존 기간을 선택하십시오.
복구 지점에 애플리케이션 버전, 완료된 작업 시간 등 유용한 맥락을 표시하되 비밀 정보는 포함하지 마십시오. 좋은 상태와 손상된 상태를 구분할 수 있을 만큼 충분한 이력을 유지하십시오. 정리하기 전에 선택한 시스템이 공유 또는 증분 데이터를 어떻게 처리하는지 확인하십시오. 레이블이 지정된 지점 삭제가 단순한 독립 파일 삭제와 일치하지 않을 수 있습니다.
성공한 작업과 검증된 데이터를 분리하십시오.
백업 도구가 성공을 보고한다는 것은 해당 규칙에 따라 프로세스가 완료되었음을 확인할 뿐입니다. 모든 중요한 애플리케이션 데이터가 선택되었는지, 저장된 모든 바이트가 온전한지, 새 서버가 결과를 사용할 수 있는지를 자동으로 증명하지는 않습니다. 이들은 서로 다른 확인입니다. 운영 계획에 저장소 상태, 선택 검토, 대표 복원을 포함하십시오.
Restic은 기본 저장소 검사와 저장된 팩 데이터를 읽는 검증의 차이를 문서화합니다. 전체 데이터 읽기 검사는 더 많은 시간과 대역폭을 소비할 수 있습니다. 이 예시는 계획 요점을 구체화합니다. 검증이 실제로 무엇을 읽는지 결정하고 작업을 예산에 반영하십시오. check라는 이름의 모든 명령이 같은 범위를 가진다고 가정하지 말고 도구 문서를 사용하십시오.
작지만 완전한 복구를 테스트하십시오.
데이터베이스, 업로드된 이미지, 구성이 있는 출판물을 상상해 보십시오. 세 가지 모두를 비공개 테스트 환경으로 복원한 다음 기사를 열고 첨부 파일을 확인하십시오. 연습 중에는 예약 메일, 결제, 게시 통합을 비활성화하십시오. 임의의 텍스트 파일 하나만 테스트하면 애플리케이션을 유용하게 만드는 관계를 놓치게 됩니다.
필요한 시간을 측정하고 어떤 자격 증명, 패키지 버전 또는 외부 의존성이 누락되었는지 기록하십시오. 복구된 파일의 내용뿐 아니라 권한도 검토하십시오. 복구 연습에서는 데이터는 존재하지만 이를 사용하는 데 필요한 지침이나 접근 권한이 운영 계획과 함께 보존된 적이 없다는 사실을 자주 발견합니다.
선택적 백업을 특정 서비스로 읽으십시오.
SwissOctet을 구성할 때 해당 패밀리의 정확한 백업 옵션과 보존 기간을 확인하십시오. 어떤 볼륨과 애플리케이션 데이터를 포함하는지, 복구가 셀프서비스인지, 기본 구성이 변경되면 어떻게 되는지 물으십시오. 옵션 레이블만으로는 독립 복사본, 불변 저장소 또는 데이터베이스 일관성 복구 지점이 확립되지 않습니다.
워크로드에 맞는 곳에는 스냅샷을 사용하고, 스냅샷이 포괄하지 못하는 장애를 위해 더 넓은 백업 전략을 유지하십시오. 중요한 데이터에 대한 독립적인 복구 경로를 기록하고, 복사본을 지울 수 있는 자격 증명을 보호하며, 절차를 테스트하십시오. 가장 강력한 선택은 가장 안심되는 이름이 아니라 정의한 시나리오에서 살아남는 선택입니다.
실용 체크리스트.
- 복구 가능한 데이터가 어디에 있는지 식별하십시오.
- 복사본이 살아남아야 할 장애를 나열하십시오.
- 애플리케이션이 지원하는 일관성 방법을 사용하십시오.
- 발견 창에 맞게 보존 기간을 선택하십시오.
- 삭제 권한을 별도로 보호하십시오.
- 완전한 애플리케이션을 격리 환경에서 복원하십시오.
중요한 세부 사항.
스냅샷은 절대 백업이 아닙니까?+
일부 스냅샷 구현은 백업입니다. 유용한 구분은 레이블이 아니라 스토리지 의존성, 보존, 접근 모델, 테스트된 복구입니다.
성공적인 무결성 검사가 애플리케이션이 작동함을 증명합니까?+
그 검사가 포괄하는 범위만 증명합니다. 애플리케이션 복원, 구성, 권한, 데이터 관계를 별도로 테스트하십시오.
백업을 같은 서버에 보관해야 합니까?+
같은 서버의 복사본은 제한적인 실수에는 도움이 될 수 있지만 중요한 장애를 공유합니다. 중요한 데이터는 살아남으려는 장애 경계 밖의 복구 경로가 필요합니다.
출처로 이동하세요.
이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요.
- Amazon EBS: 스냅샷 docs.aws.amazon.com
- PostgreSQL: 연속 아카이빙 및 특정 시점 복구 www.postgresql.org
- Restic: 저장소 작업 및 무결성 검사 restic.readthedocs.io
SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다.