소개
작은 상점은 주문 서비스로 고객, 상품, 수량을 연결합니다. 준비된 사고 이후 주문 두 건이 사라졌습니다. 데이터베이스와 관련 없는 공개 카탈로그를 교체하지 않고 필요한 데이터를 복구하는 것이 목표입니다. 모든 인물과 기록은 합성 데이터이며 악성코드는 없습니다.
백업은 복구용 사본입니다. 아카이브는 파일을 묶고 체크섬은 파일의 바이트를 요약합니다. 참조값을 신뢰할 수 있을 때만 체크섬이 유용한 이유를 배우고 임시 준비 영역을 통해 실제 SQLite 데이터베이스를 복원합니다. 범위가 제한된 복구 실습이며 전체 사고 대응 절차는 아닙니다.
기본 명령 입력과 탭 전환만 필요합니다. Workstation과 App Server는 시작 디렉터리가 다른 동일 훈련 호스트의 별도 터미널 세션이며 별도 컴퓨터가 아닙니다. 브라우저 화면은 Order Service에서 확인합니다.
손상된 서비스 데이터 보존하기
이 단계에서는 누락된 업무 데이터를 이해하고 서비스를 변경하기 전에 롤백 사본을 보존합니다.
Order Service를 엽니다. 정상적인 각 행은 주문 번호와 고객, 상태, 상품, 수량을 연결합니다. 필요한 복구 시점에는 다음 세 주문이 있습니다.
| 주문 | 고객 | 상태 | 상품 | 수량 |
|---|---|---|---|---|
| 4101 | Mina | packed | notebook | 1 |
| 4102 | Jon | packed | notebook | 2 |
| 4103 | Asha | packed | notebook | 3 |
현재는 4101만 보입니다. Public catalog를 누르면 머그잔, 노트, 가방이 여전히 나열되어야 합니다. 이 업로드는 데이터베이스와 무관하며 복구 후에도 남아야 합니다. 이후 주문 페이지로 돌아갑니다.
API는 프로그램이 사용하는 서비스 인터페이스입니다. Workstation에서 curl로 API를 요청합니다. -f는 서버 오류를 실패로 처리하고, -s는 진행률을 숨기며, -S는 오류를 계속 표시합니다. 127.0.0.1은 동일한 훈련 호스트, 8080은 서비스 포트입니다.
curl -fsS http://127.0.0.1:8080/api/orders
결과는 대괄호로 둘러싼 행 목록인 JSON 배열입니다. Mina의 행만 있습니다. 요청 성공이 업무 데이터의 완전함을 의미하지는 않습니다.
App Server로 전환합니다. pwd는 현재 디렉터리를 출력합니다.
pwd
/srv/order-service가 나와야 합니다. SQLite는 앱 테이블을 orders.db에 저장합니다. 준비된 서비스에는 쓰기 작업이 없고 요청마다 데이터베이스를 새로 열므로 여기서는 복사가 안전합니다. 사용 중인 운영 데이터베이스에는 애플리케이션과 일관성을 보장하는 백업 절차가 필요합니다.
cp는 원본 다음에 대상을 받습니다. 잘못된 복원을 되돌릴 수 있도록 현재 데이터베이스를 앱 디렉터리 밖에 보존합니다.
cp /srv/order-service/orders.db /home/labex/project/recovery/damaged-before-recovery.db
보통 출력이 없으면 복사가 끝난 것입니다. 복구 후 이 명령을 반복하면 복구된 데이터베이스로 롤백 사본을 덮어쓰므로 반복하지 마세요. 손상 상태는 보존했지만 서비스는 아직 복구해야 합니다.
신뢰할 수 있는 복구 아카이브 선택하기
이 단계에서는 변조된 백업을 제외하고 적합한 검증 아카이브를 준비 디렉터리에 배치합니다.
Workstation으로 전환합니다. cd는 디렉터리를 변경하고 ls는 내용을 나열합니다. 절대 경로는 /로 시작하며 현재 디렉터리에 관계없이 작동합니다.
cd /home/labex/project/recovery/backups
ls
.tar.gz 아카이브가 세 개 있습니다. tar는 파일을 묶고 gzip은 압축합니다. 이름은 복구 시간을 설명하며 최신 파일이 자동으로 안전하거나 적합한 것은 아닙니다.
cat은 텍스트 파일을 출력합니다. 백업 관리자가 별도로 제공한 복구 시점을 읽습니다.
cat /opt/backup-custodian/recovery-points.txt
0800 아카이브는 주문 4102와 4103 이전입니다. 0900은 필요한 복구 시점을 포함합니다. 1000 후보는 더 늦지만 무결성 검사도 필요합니다.
무결성은 참조에 비해 바이트가 변경되지 않았음을 뜻합니다. SHA-256은 비교값인 다이제스트를 만듭니다. 관리자의 매니페스트는 root 소유이며 일반적으로 편집 가능한 복구 폴더 밖에 있습니다. 독립적으로 보호된 경로로 전달되었다고 가정하며, 서명이나 키 배포는 다루지 않습니다. 관리자 권한은 로컬 소유권을 무시할 수 있으므로 이 교육 호스트를 변조 불가능한 신뢰 기준으로 보지 마세요.
sha256sum -c는 파일명과 다이제스트 쌍을 읽고 현재 디렉터리의 파일을 비교합니다. 독립적인 매니페스트를 사용합니다.
sha256sum -c /opt/backup-custodian/SHA256SUMS
0800과 0900은 OK, 1000은 FAILED를 보고해야 합니다. 0이 아닌 종료값과 경고는 예상된 결과입니다. 하나 이상의 아카이브가 변경되었습니다. 해당 후보를 추출하지 마세요.
옆의 매니페스트는 백업과 함께 편집할 수 있습니다. 결과를 비교합니다.
sha256sum -c SHA256SUMS
세 파일 모두 OK입니다. 아카이브를 변경할 수 있는 사람은 옆의 체크섬도 교체할 수 있습니다. 신뢰할 수 없는 다이제스트와의 일치는 진위를 보장하지 않습니다. 오래된 0800은 변경되지 않았지만 필요한 기록이 없습니다. 변경되지 않았고 적합한 0900을 선택합니다.
준비 디렉터리를 사용하면 실제 서비스를 건드리기 전에 데이터를 검사할 수 있습니다. mkdir -p는 디렉터리를 만들고 이미 존재해도 사용할 수 있습니다.
mkdir -p /home/labex/project/recovery/stage
검증한 후보를 복사합니다.
cp orders-0900.tar.gz /home/labex/project/recovery/stage/orders-0900.tar.gz
원본을 잘못 입력하면 cp가 파일을 찾을 수 없다고 보고합니다. ls로 확인하고 다시 시도하세요. 검사는 검증했다는 문장이 아니라 준비된 아카이브의 실제 바이트를 확인합니다.
준비한 데이터베이스 검사하기
이 단계에서는 아카이브 항목을 확인하고 예상 파일 하나를 추출한 뒤 수정하지 않고 데이터베이스를 읽습니다.
Workstation에서 준비 영역으로 이동합니다.
cd /home/labex/project/recovery/stage
tar -tvzf는 gzip 아카이브를 나열합니다. t는 목록, v는 유형과 권한, z는 gzip, f는 아카이브 지정을 의미합니다. 목록 표시는 파일을 추출하지 않습니다.
tar -tvzf orders-0900.tar.gz
유일한 항목은 orders.db이며 권한 필드는 일반 파일을 나타내는 -로 시작해야 합니다. 절대 경로, .. 경로 요소, 링크 또는 예상치 못한 파일이 보이면 중단하세요. 신뢰할 수 있는 이 교육 아카이브에는 일반 파일 하나만 있으므로 이름 검사가 유용합니다. 임의의 아카이브에 적용하는 완전한 안전 추출 정책은 아닙니다. 의심스러운 백업의 프로그램을 실행하지 마세요.
추출에는 t 대신 x를 사용하고 자세한 출력 옵션 v는 생략합니다. 마지막 orders.db는 추출을 해당 항목으로 제한하며 --no-same-owner는 자신의 소유권을 유지합니다.
tar -xzf orders-0900.tar.gz --no-same-owner orders.db
SQLite는 관련 테이블을 파일 하나에 저장합니다. 준비된 db-view는 데이터베이스를 읽기 전용으로 열고 내부 일관성과 관계를 검사한 뒤 연결된 업무 행을 출력합니다. SQL 작성이나 데이터베이스 편집은 필요 없습니다. 준비 파일 경로를 전달합니다.
/opt/c11-runtime/db-view /home/labex/project/recovery/stage/orders.db
Integrity: ok, Relationships: ok 다음에 필요한 세 주문이 나와야 합니다. 유효한 데이터베이스라도 복구 시점이 틀릴 수 있으므로 고객, 상태, 수량도 1단계와 비교하세요.
경로가 틀리면 빈 데이터베이스를 만드는 대신 오류를 보고합니다. pwd와 ls를 확인하고 다시 시도하세요. 데이터가 다르면 독립 매니페스트로 돌아가 올바른 아카이브를 선택한 뒤 다시 추출합니다. 실제 사이트는 아직 손상 상태입니다. 준비만으로 앱이 복구되지는 않습니다.
실제 서비스 복원 및 테스트하기
이 단계에서는 지정 데이터베이스만 교체하고 공개 업로드를 보존하면서 실제 요청으로 복구를 확인합니다.
App Server로 전환합니다. 롤백 사본은 이 디렉터리 밖에 있고 준비한 데이터베이스는 검사를 통과했습니다. 해당 데이터베이스만 앱의 지정 데이터 경로에 복사합니다.
cp /home/labex/project/recovery/stage/orders.db /srv/order-service/orders.db
원본과 대상은 다른 파일입니다. /srv/order-service에는 보존해야 할 관련 없는 업로드가 있으므로 준비 디렉터리 전체를 덮어쓰지 마세요. 이 준비된 읽기 전용 앱은 요청 후 데이터베이스를 닫기 때문에 데몬 재시작이 필요 없습니다. 다른 앱은 문서화된 유지보수나 재시작 절차가 필요할 수 있습니다.
백업이나 restored 텍스트 파일의 존재에 의존하지 말고 앱에 질의합니다.
curl -fsS http://127.0.0.1:8080/api/orders
4101, 4102, 4103 세 행에 올바른 고객, packed 상태, 수량 1, 2, 3이 있어야 합니다. Order Service를 열고 새로고침하면 동일한 기록이 표시되어야 합니다.
관련 없는 공개 업로드도 확인합니다.
curl -fsS http://127.0.0.1:8080/uploads/catalog.txt
Public catalog: mugs, notebooks, tote bags
브라우저에서 Public catalog를 눌러 동일한 내용을 확인합니다. 복구란 필요한 업무 데이터가 돌아오고 관련 없는 정상 기능도 계속 작동하는 것입니다.
Database unavailable이 나오면 준비한 데이터베이스를 다시 검사하고 올바른 절대 경로로 단일 파일 복사를 반복하세요. 오류를 조사하는 동안 원래 손상 상태로 돌아가려면 보존한 사본을 사용합니다.
cp /home/labex/project/recovery/damaged-before-recovery.db /srv/order-service/orders.db
마지막 명령은 의도적으로 복구를 취소합니다. 사용했다면 완료 전에 검증한 준비 데이터베이스를 실제 경로로 다시 복사하세요. 롤백 파일은 추가 검토를 위해 남겨둡니다.
요약
롤백 사본을 보존하고 독립적인 신뢰 매니페스트와 백업 바이트를 비교해 적합한 복구 시점을 선택한 뒤 준비된 SQLite 데이터베이스를 검사했습니다. 이후 실제 서비스를 복구하고 관계 및 관련 없는 업로드를 확인했습니다. 최신, 변경되지 않음, 적합함은 서로 다른 속성이며 안전한 복구에는 올바른 조합이 필요합니다.
