파나마 운영자 · KYC 없음 · Monero6개월 −28% 연간 −50% · 선불

운영 및 복구

의존하기 전에 탈출을 리허설하세요.

이식성은 복원 리허설로 검증할 사항입니다. 전체 애플리케이션을 인벤토리화하고, 원본과 독립적인 복구 가능한 사본을 준비하며, 이전을 예약하기 전에 격리된 대상에서 재구축하세요. 내보낸 데이터베이스만으로는 서비스가 다른 곳에서 실행될 수 있음을 입증하지 못합니다.

검토됨 · Hosmio 리소스

시작하기 전에

일회용 대상을 선택하고 테스트 범위를 문서화하세요. 애플리케이션 코드, 필요한 소프트웨어 버전 및 승인된 백업 자료에 대한 접근을 확인하세요. 의도적으로 테스트할 때까지 아웃바운드 알림, 예약 작업 및 외부 쓰기를 비활성화하여 대상을 프로덕션과 분리하세요.

01

무엇을 이전하고 무엇을 재생성해야 하는지 나열하세요.

런타임, 데이터베이스, 업로드된 파일, 구성, 예약 작업, 인증서, DNS 소유권 및 외부 통합을 포함하세요. 각 종속성을 누가 통제하는지, 현재 VPS를 사용할 수 없을 때 접근을 어떻게 복구할 수 있는지 기록하세요. 파일 복사가 아닌 대체가 필요한 공급업체별 기능을 식별하세요.

예상 버전과 확장을 기록하세요. 오늘 최신 버전을 가져오는 설치 명령은 운영 중인 애플리케이션을 재생성하지 못할 수 있습니다. 자격 증명에는 보호된 비밀 저장소를 참조하세요. 복구 계획은 비밀을 계획 자체에 넣지 않고 권한 있는 사람이 어떻게 검색하는지 설명해야 합니다.

02

데이터를 인식하는 내보내기 및 복원 방법을 선택하세요.

PostgreSQL에서 pg_dump를 사용한 논리적 내보내기는 하나의 데이터베이스를 다루지만, 역할과 같은 전역 객체는 별도로 처리해야 합니다. 이 도구는 클라이언트가 지원하는 것보다 최신 주 버전의 서버를 덤프하는 것을 거부합니다. 공식 문서는 또한 pg_dump를 보편적인 정규 프로덕션 백업 전략으로 취급하는 것에 대해 주의를 당부합니다. PostgreSQL: pg_dump ↗

운영자와 함께 애플리케이션 및 복구 요구에 적합한 방법을 선택하십시오. 내보내기가 생략하는 항목과 파일이 데이터베이스 참조와 어떻게 일관성을 유지하는지 기록하십시오. 명령이 성공적으로 반환되는 것은 유용한 첫 번째 확인일 뿐, 완전한 애플리케이션이 보존되었다는 증거는 아닙니다.

03

명시적으로 분리된 대상으로 복원하세요.

복원 전에 아카이브와 대상을 검사하십시오. PostgreSQL 아카이브 복원은 pg_restore를 사용합니다; 기존 객체를 정리하는 옵션은 데이터를 제거할 수 있으며, 기본 동작은 SQL 오류 후에도 계속될 수 있습니다. 모든 객체가 복원되었다고 가정하지 말고 오류 처리를 계획하고 결과를 검사하십시오. PostgreSQL: pg_restore ↗ 이름이 익숙하다는 이유만으로 프로덕션 데이터베이스에 대해 튜토리얼을 실행하지 마십시오.

파일 백업의 경우, 의도한 스냅샷과 빈 테스트 대상을 선택하십시오. Restic은 복원이 기존 파일을 덮어쓸 수 있음을 문서화합니다; 중단된 덮어쓰기는 부분적인 결과를 남길 수 있습니다. restic: 백업에서 복원 ↗ 연습 노트에 소스 스냅샷과 대상 경로를 기록하십시오. 이는 방법 선택 지침이며, Hosmio VPS에 대해 실행되거나 검증된 명령이 아닙니다.

04

사용자 작업과 숨겨진 부작용을 확인하세요.

예시적 종료 리허설 승인 시트
확인보관할 증거결과
애플리케이션이 문서화된 버전으로 시작됨버전 인벤토리 및 시작 결과아직 테스트되지 않음
대표 레코드와 파일이 일치함합성 레코드 및 첨부 파일 확인아직 테스트되지 않음
권한이 올바르게 작동함두 개의 테스트 역할 및 예상 접근아직 테스트되지 않음
작업이 중복 외부 작업을 보내지 않음아웃바운드 작업 비활성화 또는 통제된 테스트아직 테스트되지 않음
대체 운영자가 노트를 따를 수 있음독립적 워크스루 및 격차아직 테스트되지 않음

가능한 한 합성 계정과 무해한 테스트 레코드를 사용하십시오. 성공적인 읽기뿐만 아니라 접근 경계도 검증하십시오. 시작하지만 잘못된 권한을 부여하는 애플리케이션은 성공적인 복구가 아닙니다. 실패한 확인은 담당자와 함께 기록에 남겨 시정하십시오.

05

새 쓰기가 결정을 바꾸는 시점을 계획하세요.

리허설은 향후 이동의 순서를 알려주어야 합니다: 최종 일관성 단계, 대상 확인, 트래픽 전환, 승인 결정 및 이전 서비스 해지. 누가 작업을 중지하거나 되돌릴 수 있는지 결정하십시오. 대상이 새 쓰기를 수락한 경우, 사용자를 이전 복사본으로 되돌리면 해당 쓰기가 손실되거나 분할될 수 있습니다; 롤백에는 DNS 변경만이 아니라 데이터 계획이 필요합니다.

예산에 중복을 허용하십시오. 두 번째 서버, 독립 스토리지, 트래픽 요금, 라이선스 및 운영자 시간이 필요할 수 있습니다. 공급업체가 VPS를 일할 계산한다거나 선불 자금이 환불 가능하다고 가정하지 마십시오. Hosmio의 공개된 기간 가격은 선불 조건을 설명하며, 마이그레이션이나 환불 서비스를 정의하지 않습니다.

06

다른 운영자가 사용할 수 있는 증거를 남기세요.

연습 날짜, 버전, 복사본 식별자, 대상, 소요 노력 및 결과는 연습이 실제로 수행된 후에만 기록하십시오. 그 전까지는 '계획됨' 또는 '테스트되지 않음'을 사용하십시오. 승인 시트를 복구 노트와 함께 보관하고 독립적 재구축을 여전히 방해하는 종속성을 나열하십시오.

리허설이 실패하면 격차를 분류하십시오: 누락된 데이터, 호환되지 않는 소프트웨어, 사용할 수 없는 자격 증명, 외부 종속성 또는 불명확한 절차. 가장 작은 차단 문제를 해결한 다음 영향을 받은 확인을 반복하십시오. 중요한 작업이 테스트되지 않은 상태에서 애플리케이션을 이식 가능하다고 말하지 마십시오.

계획을 다음에 연결하십시오: 명명된 운영 책임클라이언트의 변경 승인 프로세스. 의도된 결과는 문서화된 범위 내에서 복구할 수 있는 능력을 입증하는 것이지, 무중단을 약속하거나 마이그레이션을 자동으로 제공하는 것이 아닙니다.