복구 시점을 정해 주문 저장하기

소개

PAPER & FORM은 종이 인쇄물과 책상용 물건을 판매합니다. 다른 서비스로 이전하기 전에 상점 주인은 백업으로 정확히 어떤 주문을 되살릴 수 있는지 알아야 합니다. 파일이 존재하는 것만으로는 부족합니다. 명확한 복구 시점의 각 주문과 품목 명세를 포함해야 합니다.

작은 주문을 만들고 PostgreSQL 사용자 지정 형식 백업을 저장한 다음, 다른 주문을 추가해 왜 백업에 포함되지 않는지 확인합니다. 기본 터미널 사용에 익숙하면 충분합니다. 데이터베이스, 도구, 사이트가 준비되어 있어 SQL 작성이나 소프트웨어 설치는 필요하지 않습니다. 고객, 가격, 주문은 모두 가상이며 결제나 이메일 서비스는 없습니다.

실제 상점은 Original Shop, 명령은 Workstation에서 조작합니다. Restored Copy는 다음 실습에 쓸 독립적인 빈 대상입니다. 이번 단원에서는 복원하지 마세요. 각 단원은 자체 데이터로 시작합니다. 제공된 프로그램과 uploads/를 그대로 보존하세요. 논리적 데이터베이스 내보내기 연습이며 완전한 재해 복구나 특정 시점 복구(PITR)가 아닙니다.

백업에 포함될 주문 기록하기

이 단계에서는 품목 명세가 있는 실제 주문을 기록합니다. Original Shop에서 시작하세요. 파란 배너가 원본 데이터베이스 shop_source를 표시합니다. Explore the collection ↗를 엽니다. Print pair는 개당 $18.00, Desk tray는 $26.00입니다. 위쪽 메뉴의 Orders에서 R-101을 선택해 품목 행을 읽으세요. Print pair 두 개의 합계는 $36.00입니다. Download receipt ↓를 눌러 저장된 텍스트를 읽습니다. 번호, 고객, 품목, 수량, 합계가 포함되어 있습니다. PAPER & FORM으로 돌아오세요.

데이터베이스는 구조화된 레코드를 저장합니다. 여기서 orders는 주문 번호와 고객을, order_items는 품목 행을 저장합니다. 각 품목은 부모 주문을 가리킵니다. 고객 이름이나 합계만 보존하면 상점에 필요한 관계가 사라집니다. 상세 페이지와 영수증은 실제로 연결된 행을 읽습니다.

Workstation으로 전환하세요. pwd는 작업 디렉터리를, ls는 안의 파일을 표시합니다.

pwd

/home/labex/project/shop-backup

ls

backups, shopctl, uploads가 보입니다. 내보내기는 backups/에 저장하세요. uploads/packing-note.txt는 이 작업과 무관하므로 바꾸면 안 됩니다. 논리적 내보내기는 데이터베이스 밖의 파일을 포함하지 않습니다.

./shopctl은 현재 디렉터리에 준비된 도우미를 실행합니다. identity 동작은 실제 연결을 보여 줍니다. 역할은 권한을 결정하는 데이터베이스 계정입니다. 호스트와 포트는 데이터베이스 서비스를 식별합니다. 실행하세요.

./shopctl identity

읽기 전용 클라이언트 역할 d09_reader를 사용하는 원본 shop_source와 쓰기 가능한 역할 d09_copy를 사용하는 대상 shop_copy를 찾으세요. 둘 다 127.0.0.1:5432에 있습니다. 서버가 같아도 같은 데이터베이스는 아닙니다. 사본 역할은 원본에 연결할 수 없습니다. 사이트는 별도의 원본 쓰기 역할을 사용합니다. 이것은 교육 환경의 경계이며 시스템 관리자에 대한 보안 방어는 아닙니다.

Original Shop에서 Collection을 열고 Place an order까지 내립니다. 제출 전에 Writing to: shop_source · ORIGINAL SHOP을 읽고 다음을 정확히 입력하세요.

Place order ↗를 선택하면 R-103, Rae, Print pair 두 개, 합계 $36.00인 레코드가 열립니다. 이 주문이 백업에 들어가야 할 기준 주문입니다. 원본 양식은 알 수 없는 번호와 사본 전용 번호를 쓰지 않고 거부합니다. 유효하고 보호된 cutoff-kept.dump를 저장하기 전 R-104를 제출해도 Keep the earlier point first가 나오며 아무것도 쓰지 않습니다. R-103을 쓰려던 경우 Collection으로 돌아가 번호를 고치세요. 이 보호는 연습에 필요한 레코드 순서를 위한 것이며 운영 상점이 보통 백업을 기다린 뒤 주문을 받는다는 뜻은 아닙니다. 기존 R-103의 고객, 품목, 수량을 잘못 입력했다면 Workstation에서 지정된 연습 레코드만 고칠 수 있습니다.

./shopctl correct source R-103

도우미는 실제 대상을 보여 준 다음 R-103만 Rae / Print pair / 2로 바꿉니다. 원래 기준 번호는 수정을 거부하며 다른 주문, 이후 레코드, 업로드, 모든 아카이브를 보존합니다. 학습자가 명시적으로 하는 수정이며 검사가 대신 수행하지 않습니다. 내보내기 전에 수정하고 레코드를 다시 읽으세요. 반복 클릭으로 번호가 이미 존재하면 Already recorded가 나옵니다. 중복 제출 대신 Orders에서 해당 레코드를 확인하세요.

Workstation으로 돌아갑니다. records는 실제 연결된 데이터를 표시합니다. 마지막 숫자는 수량과 센트 단위의 단가입니다.

./shopctl records source

R-103 | Rae | Print pair | 2 | 1800과 세 주문의 합계 $98.00를 찾으세요. 원래 R-101과 R-102를 바꾸지 않고 필요한 주문을 추가했습니다.

일관된 사용자 지정 형식 아카이브 저장하기

이 단계에서는 확정된 세 주문을 저장합니다. 복구 시점은 내보내기가 포착한 데이터베이스 상태이며 파일 이름이나 수정 시각이 아닙니다. PostgreSQL의 pg_dump는 일관된 스냅샷을 만듭니다. 다른 사용자가 활동해도 관련 테이블을 동일한 데이터베이스 관점에서 저장합니다. 이번 연습에서는 R-103을 완료한 뒤 내보내고, 내보내기가 끝날 때까지 다음 주문을 추가하지 않습니다. 시계를 비교하지 않고도 기준점을 분명히 할 수 있습니다.

Workstation에서 계속합니다. pg_dump는 데이터베이스를 내보내고 pg_restore는 해당 아카이브 형식을 읽습니다. 설치된 클라이언트 버전을 확인하세요.

pg_dump --version

pg_restore --version

준비된 환경에서는 둘 다 PostgreSQL 14를 표시하며 서버도 14입니다. 오래된 pg_dump로 더 새로운 서버에 연결하면 실패할 수 있습니다. 빈 파일을 저장해 버전 오류를 숨기지 마세요. 이 실습에는 호환 도구가 준비되어 있습니다.

원본을 선택하기 전에 연결을 다시 표시합니다.

./shopctl identity

PostgreSQL 연결 서비스는 저장된 연결 설정입니다. service=shop-source는 shop_source와 읽기 전용 역할을, service=shop-copy는 독립 대상을 고릅니다. --dbname은 그 연결을 지정합니다. 클라이언트 기본값에 의존하지 말고 항상 서비스를 명시하세요.

--format=custom은 일반 SQL 스크립트 대신 pg_restore가 필요한 PostgreSQL 압축 아카이브 형식을 만듭니다. --file은 출력 이름입니다. --no-privileges는 원본의 접근 권한 부여를 제외합니다. 사용자 지정 아카이브에서는 pg_dump --no-owner가 무시됩니다. 소유권은 나중에 pg_restore에 --no-owner를 전달하여 건너뜁니다. 이 복원 옵션을 쓰면 대상 역할이 복원된 객체를 소유합니다. 다음 명령은 원본을 읽고 지정한 로컬 백업 파일에만 씁니다.

pg_dump --dbname=service=shop-source --format=custom --no-privileges --file=backups/cutoff.dump

성공한 내보내기는 보통 아무것도 출력하지 않습니다. 완료 전에는 다음 업무 주문을 입력하지 마세요. 연결이나 파일 오류가 나면 pwd, ./shopctl identity, 출력 경로를 확인한 뒤 다시 시도합니다. 재실행은 backups/cutoff.dump를 덮어쓰므로 원본이 아직 필요한 기준 상태일 때만 하세요. 나중 내보내기는 나중 데이터를 담습니다.

pg_restore --list는 가져오지 않고 아카이브 목차를 읽습니다.

pg_restore --list backups/cutoff.dump

위쪽에서 Format: CUSTOM, dbname: shop_source, 일치하는 서버/클라이언트 버전을 찾습니다. 아래쪽에는 orders, order_items, 데이터, 시퀀스, 제약 조건 항목이 있습니다. 구조를 설명할 뿐 올바른 업무 행이 있다는 증명은 아닙니다. 실제 복원 후 행을 읽는 것이 더 강한 근거입니다.

검사는 새 폐기 가능 데이터베이스에서 실제 아카이브를 시험하고 기준 주문과 품목 관계를 확인합니다. Restored Copy 탭을 복원하는 것은 아닙니다. 다음 단계를 위해 아카이브를 보존하세요.

다음으로 가기 전에 검사 결과를 읽고 검증된 아카이브를 보관합니다. cp는 파일을 두 번째 이름으로 복사합니다. chmod a-w는 모든 사용자의 쓰기 권한을 제거해 pg_dump --file로 두 파일을 실수로 덮어쓰는 일을 방지합니다.

cp backups/cutoff.dump backups/cutoff-kept.dump

chmod a-w backups/cutoff.dump backups/cutoff-kept.dump

백업 검사에 통과한 뒤에만 실행하세요. 이제 보호된 파일로 직접 내보내면 복구 시점을 바꾸는 대신 Permission denied로 실패합니다. 원래 파일 이름을 지웠다면 cp backups/cutoff-kept.dump backups/cutoff.dump가 원래 바이트를 되돌립니다. 보관 파일은 일반적인 실수에 대비한 두 번째 로컬 사본이지 외부 재해 보호 수단이 아닙니다.

이후 주문과 저장된 복구 시점 구분하기

이 단계에서는 원본은 앞으로 진행하지만 아카이브는 이전 시점에 남는 것을 확인합니다. Original Shop의 Collection을 열고 쓰기 전에 Writing to: shop_source · ORIGINAL SHOP을 읽습니다. 다음을 제출하세요.

새 레코드의 합계는 $26.00입니다. Orders에서 R-101, R-102, R-103, R-104를 확인합니다. R-104는 pg_dump가 끝난 뒤 확정되었으므로 backups/cutoff.dump에는 없습니다. 백업은 계속 주문을 받는 실시간 연결이 아닙니다. 지금 기준 아카이브 위에 다시 내보내지 마세요.

Workstation에서 원본을 다시 읽습니다.

./shopctl records source

이제 R-104 | Sol | Desk tray | 1 | 2600이 보이고 합계는 $124.00입니다. 원본은 계속 사용 가능합니다. 복원 연습을 만들려고 업무 데이터를 파괴하지 않았습니다. 아카이브를 다시 나열하면 원래 구조가 그대로 보입니다.

pg_restore --list backups/cutoff.dump

아카이브 검사는 폐기 가능한 테스트 데이터베이스에만 복원합니다. R-101부터 R-103까지 있어야 하고 R-104는 없어야 합니다. 단순히 파일 존재 여부가 아니라 복구 시점을 증명합니다. 이번 단원에서 Restored Copy는 비워 두세요.

R-104를 잘못 입력했다면 ./shopctl correct source R-104가 원본을 표시하고 해당 기존 연습 주문만 Sol / Desk tray / 1로 수정하며 이전 레코드는 모두 보존합니다. 알 수 없는 번호는 양식이 거부하므로 번호를 고쳐 다시 제출하세요.

cutoff.dump를 실수로 삭제하거나 바꿨다면 새로운 미래 스냅샷이 아니라 보관한 이전 바이트에서 복구합니다. Workstation의 chmod u+w는 소유자에게 그 파일 하나의 쓰기 권한을 돌려줍니다. 이어 cp로 내용을 복구하고 chmod a-w로 다시 보호합니다.

chmod u+w backups/cutoff.dump

cp backups/cutoff-kept.dump backups/cutoff.dump

chmod a-w backups/cutoff.dump

파일이 삭제됐다면 첫 명령을 생략하고 보관 사본을 바로 사용하세요. 이후 아카이브 검사를 다시 합니다. R-104를 삭제하거나 원본을 되감지 마세요. 이후 업무 레코드를 보존해야 합니다. 과거 시점의 모든 사본을 실제로 잃었다면 새 논리 내보내기로 과거를 만들 수 없습니다. 그래서 이전 단계는 원본이 진행하기 전에 보호된 사본을 검사하고 보관합니다. 다음 독립 실습은 같은 기준 아카이브를 제공하므로 안전한 복원에 집중할 수 있습니다.

요약

실제 주문을 만들고 일관된 PostgreSQL 사용자 지정 형식 아카이브를 내보낸 뒤, 저장된 복구 시점과 이후 원본 주문을 구분했습니다. 아카이브 검사는 폐기 가능한 데이터베이스에 실제로 복원한 관계를 시험했습니다. 다음 독립 실습에서는 저장된 상태를 사용 가능한 상점 사본으로 엽니다.