VPS 마이그레이션 체크리스트: 백업, DNS, TLS 및 롤백
셀프 호스팅 애플리케이션을 위한 실용적인 마이그레이션 순서: 인벤토리, 일관된 백업, 테스트된 대상, 제어된 쓰기, DNS 컷오버 및 복원 경로.
한눈에 보기
제어된 VPS 마이그레이션은 서비스와 데이터를 인벤토리하고, 일관된 백업을 생성하며, 복원된 대상을 검증하고, 호스트 이름 및 TLS 라우팅을 테스트하고, 최종 쓰기 및 DNS을 조정하며, 데이터 인식 롤백을 유지합니다. 어떤 체크리스트도 단독으로 제로 다운타임을 보장하지 않습니다.
이동하기 전에 애플리케이션 인벤토리 작성
애플리케이션이 작동하는 데 필요한 서비스, 버전, 포트, 예약된 작업, 데이터베이스, 업로드된 파일 및 구성을 나열하세요. 쓰기가 발생하는 위치와 의존하는 외부 서비스를 식별하세요. 복사된 웹 디렉터리는 데이터가 다른 곳에 있는 경우 완전한 마이그레이션이 아닙니다.
현재 DNS 이름, 활성 IPv4 및 IPv6 레코드, 인증서 갱신 방법 및 복구 접근 경로를 기록하세요. 비밀은 개인 배포 도구에 보관하세요. 비밀번호, 개인 키 또는 데이터베이스 덤프를 공개 문서 루트나 공유 마이그레이션 체크리스트에 넣지 마세요.
일관된 백업을 생성하고 복원을 입증하세요
쓰기가 계속되는 동안 임의 파일을 복사하기보다는 데이터베이스가 지원하는 백업 메커니즘을 사용하세요. SQLite의 경우, Online Backup API이 일관된 데이터베이스 스냅샷을 생성합니다. WAL 모드에서 WAL 파일은 지속적인 데이터베이스 상태에 참여하므로 주요 데이터베이스 파일만 복사하면 커밋된 변경이 누락될 수 있습니다.
일관된 데이터베이스 백업이 별도로 저장된 업로드, 큐 또는 파일과 자동으로 일관되는 것은 아닙니다. 애플리케이션과 캡처를 조정하세요. 별도의 테스트 위치로 복원하고 백업을 사용 가능한 것으로 취급하기 전에 레코드, 파일 참조 및 애플리케이션 동작을 확인하세요.
DNS을 변경하기 전에 대상을 준비하세요
새 서버에 의도한 사용자, 권한, 런타임 버전, 서비스 및 애플리케이션 디렉터리를 생성하세요. 테스트 백업을 적절한 경우 공개 웹 루트 외부의 대상 데이터 위치로 복원하세요. 애플리케이션을 실제로 실행할 서비스 계정을 사용하여 소유권과 접근을 확인하세요.
공유 서버에서 관련 없는 사이트를 보존하세요. 전용 문서 루트, 가상 호스트 및 런타임을 사용하고, 웹 서버 구성을 검증하며, 이 변경이 소유한 파일과 구성만 복원하는 롤백을 준비하세요.
새 서버에서 실제 호스트 이름 및 인증서 테스트
베어 IP 주소에 대한 브라우저 요청은 호스트 이름 기반 라우팅 또는 인증서 검증을 재현하지 않습니다. curl --resolve는 일반 호스트 이름 및 TLS 확인을 유지하면서 의도한 호스트 이름과 선택한 대상 IP를 사용하는 테스트를 허용합니다. HTTP 상태와 예상 애플리케이션 콘텐츠도 확인하세요. 예제는 문서 전용 값을 사용합니다; 자신의 검증된 도메인과 대상으로 교체하세요.
그 테스트가 통과하려면 유효한 인증서와 허용된 네트워크 경로가 이미 존재해야 합니다. 마이그레이션이 준비되었다고 말하기 위해 인증서 검증을 비활성화하지 마세요. DNS 기반 ACME 검증은 웹 서버 주소를 변경하지 않고 도메인을 검증할 수 있습니다; HTTP 기반 검증은 도달 가능성 요구 사항이 다릅니다. 초기 발급과 별도로 갱신을 테스트하세요.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/쓰기 제어 및 최종 동기화 계획 선택
짧은 유지 관리 기간 또는 다른 애플리케이션에 적합한 일관성 메커니즘을 예약하세요. 식별한 작성자를 중지하거나 리디렉션하고, 최종 일관된 데이터베이스 백업을 수행하며, 해당 가변 파일을 동기화하고 결과를 확인하세요. 큐 워커, 웹훅 및 cron 작업은 공개 인터페이스가 조용해 보여도 쓸 수 있습니다.
파일 동기화 전에 드라이 런을 사용하세요. 삭제 플래그를 추가하거나 전체 시스템 디렉터리를 지름길로 복사하지 마세요. 새 애플리케이션을 확인하고 쓰기에 대해 어떤 위치가 권위 있는지 확립할 때까지 이전 서비스를 복구 가능하게 유지하세요.
DNS을 변경한 다음 두 주소 체계를 모두 관찰하세요
서비스에 필요한 레코드를 업데이트하고 기존 리졸버 캐시를 고려하세요. 권위 있는 답변과 여러 일반 클라이언트 경로를 확인하세요. 구식 AAAA 레코드가 활성 상태로 남아 있으면 IPv6 클라이언트는 이전 서버에 계속 도달할 수 있고 IPv4 클라이언트는 새 서버에 도달합니다.
새 서비스에서 로그인, 읽기, 쓰기, 업로드, 백그라운드 작업 및 외부 콜백을 테스트하세요. 전환 중에 동일한 애플리케이션의 두 독립적인 쓰기 가능 복사본을 실행하지 마세요. 여전히 이전 대상에 도달하는 트래픽을 처리하기 위한 명확한 규칙을 유지하세요.
롤백을 DNS 결정뿐만 아니라 데이터 결정으로 만드세요
롤백을 트리거하는 실패 조건과 컷오버를 제어하는 사람을 정의하세요. 새 쓰기가 대상에 도달한 후에는 DNS만 되돌리는 것으로 충분하지 않습니다: 이전 복사본으로 돌아가기 전에 그 데이터를 보존하거나 조정해야 합니다.
적절한 복구 기간 동안 소스와 백업을 유지하세요. 대상, 백업, 갱신 및 모니터링을 확인한 후에만 이전 접근을 제거하고 리소스를 해제하세요. 보존 및 삭제는 일반적인 고정 시간 수가 아니라 실제 서비스 정책을 따라야 합니다.