백업은 질문입니다. 복원이 답합니다.

첫 연습은 의도적으로 작게 유지하십시오

이 연습은 장난감 노트 데이터베이스와 첨부 파일 하나를 만들고, 둘 다 캡처한 다음 새 데이터베이스와 디렉터리로 복원합니다. PostgreSQL 17 서버와 일치하는 클라이언트 유틸리티, Bash 및 GNU coreutils가 있는 일회용 Linux 머신을 사용하십시오. 프로덕션 데이터가 없어야 하며 프로덕션 애플리케이션, 아웃바운드 메일 또는 예약 작업과 연결되어서는 안 됩니다. 이 연습에서 생성한 아카이브만 사용하십시오.

명령은 미리 구성된 비슈퍼유저 데이터베이스 역할을 가정하며 이름은 restore_lab이며, 테스트 데이터베이스를 생성할 수 있고 로컬에서 인증할 수 있는 동일한 이름의 OS 로그인이 있습니다. PostgreSQL 소켓은 /var/run/postgresql 포트 5432에서 수신 대기합니다. 관리자가 일회용 환경에서 해당 계정을 준비하도록 하십시오. 이 가이드는 데이터베이스 액세스 규칙을 수정하지 않습니다. 무엇이든 생성하기 전에 엔드포인트를 확인하십시오:

psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version

호스트, 계정 또는 버전이 예상과 다르면 중지하십시오. 이 첫 훈련에서는 클라이언트와 서버를 동일한 메이저 버전으로 유지하십시오. pg_dump 는 자체 메이저 버전보다 새로운 서버를 덤프할 수 없으며, 더 오래된 복원 대상은 일반적으로 호환성이 보장되지 않습니다. 다음을 참조하십시오 pg_dump 버전 제한. 각 블록을 별도로 실행하고 오류 발생 시 중지하십시오. && 는 붙여넣은 블록의 이후 명령이 실패 후 실행되는 것을 방지합니다. 데이터베이스 또는 디렉터리 생성이 실패한 후에는 절대 다음 블록으로 계속하지 마십시오.

레코드와 그에 맞는 파일 생성

이름 offvps_restore_source 및 offvps_restore_target 은 사용되지 않아야 합니다. 기존 데이터베이스는 중지하고 새로운 격리 연습을 선택할 이유이지, 삭제할 이유가 아닙니다. 새 파일 시스템 작업 공간과 소스 데이터베이스를 만드십시오:

umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_source

새 작업 공간은 기존 디렉터리를 덮어쓰지 않도록 합니다. mktemp 는 고유한 디렉터리를 만듭니다. createdb 는 선택한 템플릿에서 새 데이터베이스를 만듭니다. 이 두 마커를 저장하십시오:

psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
  -U restore_lab -d offvps_restore_source \
  -c "CREATE TABLE notes (
        id integer PRIMARY KEY,
        body text NOT NULL,
        attachment text NOT NULL
      );
      INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"

레코드는 어떤 파일이 노트에 속하는지 알려주며, 둘 다 동일한 마커를 포함합니다. 이렇게 하면 누락된 첨부 파일이나 일치하지 않는 복사본이 드러납니다. -X 는 개인 psql 시작 설정을 피하고 ON_ERROR_STOP 는 SQL 오류 시 중지합니다. 다음을 참조하십시오 psql 스크립팅 옵션. 이 장난감 데이터 세트에 쓰는 애플리케이션은 없습니다.

데이터베이스와 파일을 하나의 복구 세트로 캡처

pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
  --format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"

사용자 지정 형식 아카이브는 다음으로 읽힙니다: pg_restore; 일반 SQL 덤프는 다른 복원 절차를 따릅니다. 아카이브를 나열하면 예상 테이블과 데이터 항목이 있는지 확인하는 데 도움이 됩니다. 일관된 데이터베이스 덤프가 외부 업로드를 자동으로 동기화하지는 않습니다. 실제 앱의 경우 문서화된 유지 관리 또는 쓰기 일시 중지 절차를 사용하여 파일 트리와 데이터베이스가 동일한 시점을 나타내도록 하십시오. 장난감 연습은 이미 조용합니다.

데이터베이스 버전, 애플리케이션 릴리스, 캡처 시작/종료 및 파일 경로를 번들 옆에 기록하십시오. 실제 자격 증명은 적절한 액세스 제어 아래 별도로 보관하십시오. 데이터베이스별 덤프는 전역 역할과 테이블스페이스를 캡처하지 않습니다. 실제 복구 계획은 그것들도 고려해야 합니다. 범위는 다음에 설명되어 있습니다 PostgreSQL의 SQL 덤프 가이드.

기존 대상을 정리하지 않고 새 대상으로 복원

createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
  --dbname=offvps_restore_target --no-owner --no-acl \
  --single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"

대상 데이터베이스는 비어 있게 생성됩니다. 복원은 의도적으로 다음을 생략합니다 --clean, 이는 기존 객체를 제거할 수 있습니다. --single-transaction 는 이 작은 데이터베이스 복원이 단위로 성공하거나 부분 변경을 적용하지 않고 중지하도록 합니다. 병렬 작업과 결합할 수 없습니다. --no-owner 및 --no-acl 는 이 테스트 역할의 소유권을 단순화하므로, 이 훈련은 애플리케이션의 프로덕션 역할이나 권한을 검증하지 않습니다. 다음을 참조하십시오 pg_restore.

파일 복사는 새 복원 디렉터리를 대상으로 하여 소스를 그대로 둡니다. GNU cp -a 는 파일 속성을 보존하려고 시도합니다. 실제 애플리케이션을 실행할 계정의 소유권과 액세스를 검사하십시오. 바이트 복사는 애플리케이션 권한 테스트가 아닙니다. 다음을 참조하십시오 cp의 아카이브 옵션.

종료 코드뿐 아니라 관계를 확인

psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
  -d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"

예상 결과는 ID 1, 본문이 있는 행 하나입니다 restore-marker-01 및 첨부 파일 marker.txt, 그리고 다음을 포함하는 파일 restore-marker-01. 소스에 여전히 원래 행과 파일이 있는지 확인하십시오. 실제 앱의 경우 격리된 인스턴스를 복원된 데이터베이스와 업로드 디렉터리로 가리키고, 대표 레코드를 열고, 첨부 파일을 가져오고, 의도한 로그인 권한을 테스트하십시오. 그 동안 콜백, 메일 및 작업을 격리된 상태로 유지하십시오.

증명한 것과 남은 것을 기록

위의 예상 출력은 연습 기준이며 OffVPS이 이미 관찰한 결과가 아닙니다. 첫 훈련은 모든 파일을 한 머신에 유지하므로 해당 머신의 손실로부터 보호하지 못합니다. 실제 계획에는 별도 장애 도메인의 보호된 복사본, 사용 가능한 복호화 키, 보존 및 테스트된 검색 경로가 필요합니다. 나중에 정리하기 전에 정확한 일회용 데이터베이스 이름과 디렉터리를 검토하십시오. 프로덕션은 그 과정 밖에 두십시오.

중요한 변경 후 연습을 반복하고 실패를 성공만큼 주의 깊게 기록하십시오. 선택적 백업 서비스는 애플리케이션의 복구 시간을 증명하지 않습니다. 계속하려면 예약 작업 계획 캡처 자동화를 준비할 때, 별도의 복원 훈련은 유지하십시오.