로그·체크포인트·백업·복구·데이터 보호
회복은 로그·백업 등을 이용해 완료된 변경은 보존하고 미완료 변경은 취소하는 과정이다. UNDO·REDO, 지연·즉시 갱신, 체크포인트와 그림자 페이징을 구분한다. 전체·증분·차등 백업은 필요한 복원 체인이 다르며 RPO·RTO와 실제 복원 가능성을 확인한다. 데이터베이스 암호화와 DAC·MAC·RBAC 접근제어는 서로 보완하는 보호 수단이다.
회복과 데이터 보호의 목표
데이터베이스의 신뢰성은 정상 실행 중의 트랜잭션 제어만으로 완성되지 않는다. 전원 장애, 프로세스 종료, 저장장치 손상, 잘못된 삭제와 보안 사고가 발생했을 때도 커밋된 결과는 가능한 범위에서 보존하고, 미완료 작업은 제거하며, 필요한 시점의 데이터로 복원할 수 있어야 한다.
이번 이론은 다음 세 흐름을 연결한다.
- 로그·체크포인트·장애 회복: 시스템 장애 뒤 어떤 변경을 REDO하고 어떤 변경을 UNDO하는지 판단한다.
- 백업·복원·복구 목표: 백업 유형과 복구 순서를 RPO·RTO에 맞추어 설계한다.
- 데이터 보호: 인증·인가·접근통제·감사·암호화와 키 관리를 결합한다.
트랜잭션의 ACID, 격리 수준과 교착상태는 앞 이론에서 다뤘다. 여기서는 지속성과 원자성을 장애 뒤에 어떻게 복구하는지, 그리고 저장된 데이터와 백업을 어떻게 보호하는지에 집중한다.
장애 유형부터 구분하기
복구 방법은 무엇이 손상되었는지에 따라 달라진다.
| 장애 유형 | 대표 상황 | 일반적인 복구 방향 | 핵심 자료 |
|---|---|---|---|
| 트랜잭션 장애 | 제약조건 위반, 사용자 취소, 교착 희생자 | 해당 트랜잭션만 롤백 | UNDO 정보, 트랜잭션 로그 |
| 시스템·인스턴스 장애 | 전원 차단, 운영체제·DBMS 프로세스 비정상 종료 | 현재 데이터 파일과 로그로 충돌 복구 | 온라인 로그·WAL, 체크포인트 |
| 미디어 장애 | 디스크·데이터 파일 손상 또는 유실 | 백업을 복원한 뒤 로그를 재적용 | 물리 백업, 보관 로그 |
| 논리적·사용자 오류 | 잘못된 DELETE, 잘못된 배치 작업 | 오류 직전 시점 복구 또는 선택 복원 | 시점 복구용 로그, 논리 백업 |
| 사이트·보안 사고 | 화재, 랜섬웨어, 관리자 계정 탈취 | 격리된 환경에 깨끗한 사본을 복원 | 오프사이트·오프라인·불변 백업, 키 |
시스템 장애에서는 비휘발성 저장장치의 데이터 파일과 로그가 남아 있다고 가정한다. 반면 미디어 장애에서는 데이터 파일 자체가 없거나 신뢰할 수 없으므로 로그만으로 시작할 수 없고, 먼저 백업을 복원해야 한다.
로그·UNDO·REDO와 WAL
회복용 로그는 트랜잭션의 시작·변경·커밋 등의 기록이다. 변경 전 값은 UNDO, 변경 후 값은 REDO의 근거가 될 수 있다.
| 작업 | 뜻 | 관련 목적 |
|---|---|---|
| UNDO | 미완료 작업의 반영 효과를 취소 | 원자성 |
| REDO | 완료된 작업의 미반영 효과를 다시 적용 | 지속성 |
WAL(Write-Ahead Logging)은 변경된 데이터 페이지를 저장하기 전에 관련 로그를 먼저 영구 저장하는 원칙이다. 일반적인 동기 커밋에서는 필요한 로그와 커밋 기록을 영구 저장한 뒤 성공을 알린다. 로그는 남았지만 데이터 페이지가 아직 저장되지 않은 경우에도 완료된 변경을 다시 적용할 수 있다.
다음은 변경이 로그에 기록되고, 데이터 파일에는 일부만 반영될 수 있다고 가정한 예다.
초기 X=100, Y=50
T1: X를 130으로 변경
T2: Y를 20으로 변경
T1: COMMIT
시스템 장애
회복된 결과는 T1의 변경을 보존한 X=130과 T2의 미완료 변경을 취소한 Y=50이어야 한다. 데이터 파일에 X 변경이 빠졌으면 REDO하고, T2의 Y 변경이 반영돼 있으면 UNDO한다. 이미 반영된 작업까지 무조건 다시 쓰는지는 회복 방식에 따라 다르다.
WAL의 기록 순서와 체크포인트
메모리에서 데이터를 변경하더라도 수정 페이지를 영구 기록하기 전에 관련 로그를 먼저 기록한다. 일반적인 동기 커밋은 커밋 로그 영구 기록 뒤 성공을 알린다. 체크포인트는 복구 조사량을 줄이며 백업이나 모든 트랜잭션의 커밋이 아니다. UNDO·REDO는 실제 반영 상태를 따른다.
회복 기법
| 기법 | 기본 원리 | 교재의 대표적인 복구 관점 |
|---|---|---|
| 지연 갱신 | 완료 전에는 실제 DB에 변경을 반영하지 않음 | 미완료 변경의 UNDO 불필요, 완료 미반영분 REDO |
| 즉시 갱신 | 완료 전에도 변경이 DB에 반영될 수 있음 | 미완료 반영분 UNDO, 완료 미반영분 REDO |
| 검사점 회복 | 로그와 데이터 처리 상태의 기준점을 이용 | 로그 조사·회복 범위를 줄임 |
| 그림자 페이징 | 원래 페이지 연결을 보존하고 새 페이지에 변경 | 실패 시 원래 페이지 연결로 복귀 |
지연 갱신은 NO-UNDO/REDO, 일반적인 즉시 갱신은 UNDO/REDO로 요약하지만 실제 문항에서는 반영 여부와 제시된 가정을 먼저 확인한다.
체크포인트
체크포인트는 로그·데이터 페이지와 회복에 필요한 상태를 기록하는 검사점이다. 장애 후 처음부터 모든 기록을 조사하는 부담을 줄인다. 체크포인트는 백업도 아니고 모든 사용자 트랜잭션을 커밋시키는 명령도 아니다.
단순한 검사점 문제에서는 검사점 전에 완료되고 변경 반영이 끝난 트랜잭션은 다시 처리할 필요가 없다고 가정한다. 검사점 당시 진행 중이거나 이후 실행된 트랜잭션은 커밋·미완료 여부를 따로 판단한다. 실제 제품의 검사점 방식은 다르므로 '검사점 이전 로그는 언제나 삭제 가능'이라고 일반화하지 않는다.
그림자 페이징
변경 전 페이지를 가리키는 그림자 페이지 테이블을 유지하고 변경은 새 페이지에 기록한다. 성공 시 현재 페이지 연결을 확정하고 실패 시 그림자 연결을 사용한다. 기본 방식은 로그 기반의 변경 취소·재적용 대신 페이지 사본을 사용한다. 회복이 단순한 대신 공간 단편화·페이지 관리 비용이 생길 수 있다.
백업의 분류 축
물리 백업과 논리 백업
| 구분 | 백업 대상 | 장점 | 주의점 |
|---|---|---|---|
| 물리 백업 | 데이터 파일·페이지·블록과 관련 로그 | 대용량에서 복원 속도가 빠를 수 있고 DB 전체 회복에 적합 | DBMS 버전·플랫폼·파일 구조 의존성이 큼 |
| 논리 백업 | 테이블 정의, SQL 문장, 행 데이터와 객체 메타데이터 | 객체 단위 선택과 이관에 유리 | 대용량에서 백업·복원이 느릴 수 있고 계정·역할 등 전역 객체를 별도 확보해야 할 수 있음 |
논리 백업은 단순히 CSV 한 파일을 저장하는 것과 같지 않다. 제약조건, 시퀀스, 권한, 저장 프로그램과 문자 인코딩 등 복원에 필요한 객체가 범위에 포함되는지 확인해야 한다.
전체·증분·차등 백업
교재에서 일반적으로 사용하는 구분은 다음과 같다.
| 방식 | 포함 범위 | 복원에 필요한 기본 체인 | 특성 |
|---|---|---|---|
| 전체 백업 | 백업 범위의 전체 데이터 | 전체 백업 하나 | 백업 크기·시간이 크지만 복원 체인이 단순함 |
| 증분 백업 | 직전 백업 이후 변경분 | 전체 + 이후 증분을 순서대로 모두 | 일일 백업량은 작지만 체인이 길어질 수 있음 |
| 차등 백업 | 기준 전체 백업 이후 변경분 | 전체 + 가장 최근 차등 | 시간이 지날수록 차등 크기가 커지지만 복원 단계가 적음 |
일요일 전체 F0
월요일 증분 I1
화요일 증분 I2
수요일 증분 I3
복원: F0 → I1 → I2 → I3
일요일 전체 F0
월요일 차등 D1
화요일 차등 D2
수요일 차등 D3
복원: F0 → D3
제품별 명칭보다 무엇을 기준으로 한 변경분인지 확인한다.
오프라인·온라인 백업
- 오프라인·콜드 백업: 데이터베이스를 일관되게 종료하거나 쓰기를 중지한 상태에서 수행한다. 일관성 확보가 단순하지만 서비스 중단이 필요하다.
- 온라인·핫 백업: 서비스를 계속 제공하면서 수행한다. 백업 중 변경을 일관된 상태로 만들 로그와 제품별 백업 절차가 반드시 필요하다.
실행 중인 데이터 파일을 운영체제 명령으로 임의 복사한 것만으로 유효한 온라인 백업이 되는 것은 아니다. 여러 파일의 서로 다른 시점이 섞일 수 있기 때문이다.
전체·증분·차등 백업 체인
증분 복원은 전체 F0 → I1 → I2 → I3를 모두 연결하고 차등 복원은 전체 F0와 최신 D3를 사용한다. 시점 복구에는 연속 로그도 필요하다. RPO는 허용 데이터 손실의 시간 범위, RTO는 서비스 복구 시간 목표다. 복제는 독립 백업을 대신하지 않는다.
복구 목표와 복원 검증
복원(restore)은 백업을 가져오는 것이고 복구(recovery)는 로그 적용 등을 통해 요구한 일관된 상태로 되살리는 과정이다. 같은 용어로 혼용되기도 하지만 백업 파일 복사만으로 최신 상태까지 모두 복구된 것은 아니다.
RPO는 허용할 데이터 손실의 시점 목표, RTO는 업무를 재개하기까지 허용하는 시간 목표다. 14:37 장애에 마지막 복구 가능 데이터가 14:35이면 손실 구간은 2분이다. 15:22에 서비스가 재개되었다면 복구 시간은 45분이다. 이 수치는 측정값이고 목표를 만족했는지는 미리 정한 허용값과 비교한다.
백업 성공 메시지와 실제 복원 가능성은 다르다. 백업·로그·필요한 키가 모두 있는지, 무결성이 맞는지, 목표 시간에 복원되는지 시험해야 한다. 로그 체인 중간이 없으면 그 뒤 기록만으로 연속적인 시점 복구가 안 될 수 있다.
복제는 잘못된 삭제도 전달할 수 있고 같은 장치의 스냅숏은 장치 장애에 함께 손상될 수 있다. 과거 상태의 독립된 백업을 보존하는 목적과 서비스 이중화를 구분한다.
데이터베이스 암호화와 접근제어
데이터 보호는 기밀성·무결성·가용성을 함께 고려한다. 접근제어는 누가 어떤 데이터를 사용할 수 있는지를 제한하고, 암호화는 키 없이는 저장·전송 내용을 읽기 어렵게 한다.
| 개념 | 목적 |
|---|---|
| 인증 | 주장한 사용자가 맞는지 확인 |
| 인가 | 어떤 객체에 어떤 작업을 허용할지 결정 |
| 감사 | 누가 무엇을 수행했는지 추적 |
| 최소 권한 | 업무에 필요한 범위만 허용 |
DB 파일·칼럼·백업을 암호화할 수 있고, 클라이언트와 DB 사이 전송도 보호 대상이다. 저장 파일을 암호화해도 정상 계정의 과도한 조회 권한까지 없어지지는 않는다. 암호화와 접근제어는 함께 사용한다.
| DB 암호화 적용 방식 | 기본 위치·특징 |
|---|---|
| 응용 프로그램 API 방식 | 응용 프로그램이 암호화·복호화를 호출 |
| DB 플러그인 방식 | DB 내부 또는 확장 모듈에서 처리 |
| DBMS 자체 암호화 | DBMS가 저장 영역 등을 암호화하며 TDE가 대표 예 |
실제 지원 범위는 제품에 따라 다르다. DB 전체 또는 특정 칼럼 등 적용 단위, 검색·성능 영향, 키 보관·복구 가능성을 확인한다. 암호화된 백업이 있어도 키를 잃으면 복원할 수 없다.
마스킹은 표시값 일부를 가리는 것이며 원본 암호화와 다르다. 해시는 변경 검출 등에 쓰는 요약값으로 원문을 복호화하는 암호화와 구분한다. 암호 알고리즘 내부나 전자서명 절차를 데이터베이스 권한 설정과 혼동하지 않는다.
DAC·MAC·RBAC
| 모델 | 권한 결정 기준 | 권한 관리 주체 | 핵심 판별 |
|---|---|---|---|
| DAC | 객체 소유자나 권한 보유자의 재량 | 소유자·권한 위임자 | 사용자가 권한을 다른 사용자에게 넘길 수 있는 구조 |
| MAC | 정보의 보안 등급과 사용자의 인가 등급 | 중앙 보안 정책 | 개별 소유자가 등급 규칙을 임의로 바꿀 수 없음 |
| RBAC | 조직의 역할과 직무 | 보안 관리자·역할 정책 | 권한을 역할에 연결하고 사용자를 역할에 배정 |
RBAC에서는 사용자에게 수백 개 권한을 직접 반복 부여하기보다 고객상담, 결제승인, DB운영 같은 역할에 필요한 권한을 묶는다. 역할 계층과 상속을 사용할 수 있으며, 상충하는 역할을 한 사람이 동시에 수행하지 못하게 직무 분리를 적용할 수 있다.
최소 권한과 직무 분리
- 최소 권한: 업무 수행에 필요한 최소한의 자원과 권한만 부여한다.
- 직무 분리: 한 사람이 중요한 업무의 승인·실행·감사를 모두 장악하지 못하게 역할을 나눈다.
- 일반 계정과 관리자 계정을 분리한다.
- 응용 프로그램 계정에 스키마 소유자나 전체 관리자 권한을 주지 않는다.
- 장기간 사용하지 않는 권한과 계정을 회수한다.
- 원본 민감 열 대신 제한된 뷰·행 수준 정책·열 권한을 사용한다.
데이터 마스킹은 조회 결과에서 일부 값을 가리는 통제이며, 원본 저장값을 암호화한 것과 같지 않다. 높은 권한이나 우회 경로가 있으면 원본에 접근할 수 있으므로 권한 통제와 함께 사용한다.
트랜잭션 로그·감사 로그·오류 로그 구분
이름에 모두 ‘로그’가 들어가지만 목적은 다르다.
| 로그 | 주목적 | 대표 내용 | 복구·보안에서의 역할 |
|---|---|---|---|
| 트랜잭션 로그·WAL | 데이터베이스 상태 회복 | 변경 순서, 트랜잭션 상태 | REDO·UNDO, 시점 복구 |
| 감사 로그 | 책임 추적과 정책 위반 탐지 | 사용자, 객체, 작업, 시각, 성공·실패 | 누가 무엇을 했는지 조사 |
| 오류·서버 로그 | 운영 진단 | 오류, 시작·종료, 경고, 성능 상태 | 장애 원인 분석 |
| 백업 이력 | 백업 운영 관리 | 백업 시각, 범위, 위치, 성공 여부 | 복구 체인 선택과 보존 관리 |
트랜잭션 로그만으로 감사 요구를 모두 충족한다고 단정할 수 없다. 내부 복구 형식은 사람이 수행한 업무 의미와 접속 주체를 충분히 보존하지 않을 수 있다. 감사 로그는 일반 사용자나 감사 대상 관리자가 임의로 삭제·수정하지 못하도록 보호하고, 시각 동기화와 보존 정책을 함께 관리한다.
백업 체인·이중화·감사 로그의 적용
일반적인 증분 백업은 직전 백업 이후의 변경을 담으므로 전체 F0 뒤에 I1·I2·I3가 순차로 있다면 복원에 그 연결 체인이 필요하다. 차등 백업은 마지막 전체 백업 이후의 변경을 누적하므로 F0와 가장 최근 차등 D3를 사용한다. 제품이 사용하는 명칭과 기준 백업의 정의를 확인하고, 단순히 파일 이름이 '증분'이라고 다른 복구 체인을 추정하지 않는다.
그림자 페이징은 변경 전 페이지 테이블을 보존하고 변경할 페이지를 별도 위치에 기록한 뒤 확정 시점에 새 페이지 테이블로 전환하는 아이디어다. 임의의 실행 중 데이터 파일 복사를 일관된 온라인 백업이라고 볼 수는 없다. 온라인 백업은 DBMS의 일관된 스냅숏·로그 연계 등 적절한 지원을 사용해야 한다.
Active–Standby는 주 시스템이 처리하고 대기 시스템이 장애에 대비하는 구성, Active–Active는 여러 시스템이 평상시 업무를 처리하는 구성이다. 두 노드가 합쳐 초당 120건을 처리하고 한 노드의 최대 처리량이 80건이라면 한 노드 고장 후 40건/초의 용량 부족이 생길 수 있다. 노드 수만으로 고장 후에도 같은 성능이 보장되지는 않는다.
복제는 잘못된 삭제도 사본에 전파할 수 있으므로 과거 정상 상태를 보존하는 독립 백업을 대체하지 않는다. 복제 지연, 장애 전환의 절차와 용량, 백업 보존 시점을 별도로 관리한다.
MAC은 보안 등급·인가 수준 같은 중앙 정책으로 접근을 통제하고, DAC은 소유자 등에 허용된 권한 부여, RBAC은 역할에 연결된 권한을 중심으로 한다. 감사 로그는 누가 언제 무엇에 접근·변경했는지 추적하는 데 사용한다. REDO·UNDO를 위한 트랜잭션 로그가 모든 조회의 사용자 감사 정보를 대신한다고 단정하지 않는다.