Redis 데이터 백업 전략 (RDB, AOF, AOF-RDB Hybrid)

 

이번 포스트에서는 Redis에 대해 간단히 설명하고 Redis 데이터 백업 전략에 대해 알아본다.

 

[1] Redis란?

오픈소스 기반의 In-memory 데이터 저장소로, Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 비관계형 데이터베이스 관리 시스템이다. 데이터베이스, 캐시, 메시지 브로커 등 다양한 용도로 사용할 수 있으며, 정해진 스키마가 없고 유연한 데이터 모델을 사용하는 NoSQL Database이다. 외부에서 사용 가능한 Key-Value 쌍의 해시맵 형태의 서버로 별도의 쿼리문 없이 Key값으로 빠르게 결과를 가져올 수 있다.

 

Redis는 아래과 같은 특징을 가지고 있다.

• In-memory Database : 디스크가 아닌 메모리에서 데이터를 처리하여 매우 빠른 데이터 엑세스 속도를 제공
• 고성능 : 빠른 응답 속도로 대용량 데이터 처리 및 실시간 처리에 적합
• 다양한 자료구조 지원 : String, List, Set, Sorted Set, Hash 등
• TTL(Time To Live) 지원 : 일정 시간이 지나면 데이터 자동 삭제
• 싱글 스레드 기반 처리 : 단일 스레드에서 명령어를 순차적으로 실행하며 동시성 문제에 강점을 가짐
• 데이터 백업 기능 제공(AOF, RDB) : 메모리에서 처리된 데이터를 주기적으로 디스크에 동기화하여 데이터 유실 방지
• Redis Cluster 지원 : 확장성, 부하 분산, 고가용성을 위한 분산 시스템 구성 가능

 

[2] Redis 데이터 백업 전략

Redis는 인메모리 기반의 빠른 성능이 특징인 데이터 저장소이지만, 메모리에 저장된 데이터는 시스템 장애나 종료 시 휘발될 수 있다. Redis 데이터를 안정적으로 보존하고 복구하기 위한 백업 전략이 필요하다.

 

Redis가 제공하는 기본 백업 방식은 크게 RDB, AOF가 있다.

• RDB(Snapshot) 방식 : 저장된 데이터를 주기적으로 파일에 저장
• AOF(Append Only File) 방식 : 명령이 실행될 때마다 데이터를 파일에 기록

 

1) RDB(Snapshot) 방식

특정 시점의 메모리에 있는 Redis 데이터 전체를 바이너리 파일로 저장하는 방식이다.

 

Redis는 직접 세팅하지 않아도 인메모리 데이터를 주기적으로 .rdb 확장자 파일에 저장한다. 이는 기본적으로 설정되어있는 백업 방식이다. 순간적으로 메모리에 있는 데이터를 스냅샷을 떠서 하드디스크에 바이너리 파일로 저장한다. 특정 시점으로 데이터를 복구하는 것이 가능하며, 레디스 데이터의 버저닝도 가능하다. 여기서 RDB는 RDBMS가 아닌 Redis Database File의 약자로 단순히 메로리의 스냅샷을 파일 형태로 저장한 파일의 확장자명이다. 

 

**스냅샷 : 데이터 전체를 복사하는 것이 아니라 특정 시점의 데이터 이미지를 생성하여 저장하는 방식. 일반적인 백업보다 데이터 복사 속도가 빠르며, 필요한 저장 용량은 원본 데이터의 10~20% 정도이다.

 

 

RDB 저장 방식

(1) SAVE : 순간적으로 Redis의 동작을 정지시키고, 그 상태의 snapshot을 저장한다 (blocking 방식)

[SAVE 명령 실행]
       ↓
[Redis 메인 프로세스가 현재 데이터를 RDB temp 파일에 직접 기록]
       ↓
[쓰기 완료 후 → 기존 RDB 파일 삭제 → temp 파일을 최종 RDB 파일로 rename]
       ↓
[클라이언트 요청 처리 재개]

조건을 여러개 지정할 수 있으며, 조건 1개라도 만족하면 저장한다.

 

(2) BGSAVE : 별도의 자식 프로세스를 띄워 Redis 동작을 멈추기 않게 하고, 명령어 수행 시점의 snapshot을 디스크에 저장한다. (non-blocking 방식)

[BGSAVE 명령 실행 또는 자동 조건 만족 시]
       ↓
[Redis 프로세스 fork -> 자식 프로세스 생성]
       ↓
[자식 프로세스가 현재 시점의 데이터를 RDB temp 파일로 덤프]
       ↓
[쓰기 완료 후 → 기존 RDB 파일 삭제 → temp 파일 rename]
       ↓
[자식 프로세스 종료 / 메인 프로세스는 계속 동작 중]

fork를 떠서 자식 프로세스에서 백업을 하므로 메인 프로세스 성능에는 영향이 없다. 하지만 fork를 이용하므로 시간이 오래걸릴 수 있으며, CPU와 메모리 자원을 소모한다. 메모리를 거의 두 배 가량 사용한다고 생각하면 된다.

 

 

장점

• 메모리의 스냅샷을 그대로 저장하고, 서버 재구동 시 다시 읽으면 되기 때문에 속도가 빠르다.
• AOF파일에 비해 파일 사이즈가 작다.

단점

• 스냅샷을 추출하는데 시간이 오래걸린다.
• 스냅샷 저장 시점 사이의 데이터 변경 사항은 유실될 수 있으며, 저장 도중 서버가 꺼지면 이후 데이터가 모두 사라진다.
• 바이너리 파일이므로 사람이 이해하기 어렵다.

 

2) AOF(Append Only File) 방식

수행된 명령어를 로그 파일에 기록하고, 데이터 복구를 위해 로그를 재실행하는 방식이다. 

Redis의 모든 write/update 연산 자체를 모두 log파일에 기록하고, 서버 재시작 시 log에 기록된 write/update 연산을 재실행하여 데이터를 복구한다. default로 appendonly.aof 파일에 기록되며, 조회를 제외한 입력/수정/삭제 명령이 실행될 때마다 기록된다. 현재 시점까지의 로그를 기록할 수 있으며, 기본적으로 non-blocking 으로 동작한다.

 

또한 Redis는 AOF Rewrite 설정을 제공한다.

Rewrite는 AOF 파일의 상태가 특정 조건일 때, 기존의 appendonly.aof 파일을 최적화된 새로운 파일로 교체하는 과정이다. 기존 AOF 파일을 그대로 유지하면서 새로운 파일을 생성하고, 불필요한 명령을 제거하여 크기를 줄인다. 이를 수행하면 이전 기록은 모두 사라지고 최종 데이터만 기록된다.

 

 

동작 순서

[클라이언트의 Write 명령 발생 (SET, HSET 등)]
             ↓
[Redis는 명령을 AOF 버퍼에 저장]
             ↓
[Redis는 appendfsync 설정에 따라 AOF 버퍼를 디스크 flush]
             ↓
[write가 완료되면 실제 해당 명령을 수행해서 Redis 메모리에 내용을 변경]

Redis는 클라이언트의 write명령을 AOF 버퍼 캐시에 저장하고, fsync 설정에 따라 디스크의 내용을 반영(flush)한다. appendfsync를 통해 디스크와의 동기화를 얼마나 자주 할 것인지 설정할 수 있다. 

설정과 관련된 파라미터 옵션은 아래와 같이 있다.

• always : 명령 실행 시 마다 AOF에 기록한다. 데이터 유실은 없지만 성능이 매우 떨어진다
• everysec : 1초마다 AOF에 기록한다. 권한하는 옵션이다.
• no : AOF에 기록하는 시점을 운영체제가 정한다. 데이터 유실 가능성이 있다.

 

장점

• log파일에 대해서만 append하므로 log write 속도가 빠르다
• 특정 시점에 서버가 다운되더라고 데이터가 사라지지 않는다
• 실제 수행된 명령어가 저장되어있어 사람이 직관적으로 이해하기 쉽고, 해당 내용을 일부 수정해서 데이터를 살리는 방법도 가능하다.

단점

• 모든 write/update 연산을 log파일에 남기기 때문에 log 데이터 양이 매우 크다
• 복구 시 저장된 모든 연산을 다시 실행하므로 백업 및 복구 속도가 느리다.⇒ rewrite 기능을 사용하여 이전 기록은 모두 사라지고 최종 데이터만 기록되도록 할 수 있다.

Key가 같고 Value가 다른 set명령이 여러번 수행된다면, 메모리에는 마지막 값만 남아있지만 AOF에는 모든 기록이 남아 있게 된다.

 

☑️ RDB vs AOF

RDB와 AOF를 비교하면 다음과 같다.

비교 항목	AOF (Append-Only File)	RDB (Snapshot)
저장 방식	모든 쓰기 연산을 기록	일정 간격마다 전체 데이터를 덤프
복구 속도	느림 (모든 명령 실행 필요)	빠름 (바이너리 덤프 복구)
데이터 손실 가능성	적음	있음
파일 크기	큼 (모든 연산이 기록됨)	작음 (최신 상태만 저장)
성능 영향	높음 (모든 연산이 로그로 기록됨)	낮음 (주기적인 덤프 수행)

 

 

 

 

3) RDB + AOF 병행 전략 (AOF-RDB Hybrid 방식)

Redis 7.0 이상에서는 RDB 스냅샷과 AOF를 결합하여 데이터를 최적화된 방식으로 저장하는 방식인 AOF-RDB Hybrid 방식을 제공한다.

 

기존 AOF 방식의 비효율적인 디스크 사용과 느린 복구 속도 문제를 해결하기 위해 도입되었고, Redis 7.0이상에서는 AOF-RDB Hybrid 방식이 기본설정이다. 즉, appendonly.aof 단일 파일이 생성되지 않는다. RDB가 기반이 되므로 RDB 관련 설정이 올바르게 적용되어야 한다.

 

동작 방식

1. 초기 상태 저장 : AOF를 저장할 때, 먼저 RDB 스냅샷을 생성하여 appendonly.aof.X.base.rdb 파일에 저장한다.
2. 변경 사항 저장 : 이후의 모든 변경사항은 appendonly.aof.X.incr.aof 파일에 기록된다. (AOF delta)
3. 데이터 복구 : Redis가 재시작되면 RDB를 먼저 로그한 후 AOF delta를 반영하여 최신 상태로 복원한다.

• appendonly.aof.X.base.rdb : 현재 Redis 메모리 상태를 저장한 RDB 스냅샷 파일
• appendonly.aof.X.incr.aof : 이후 변경 사항을 기록한 AOF 파일
• appendonly.aof.manifest : AOF 파일 목록을 관리하는 메타데이터 파일

 

장점

• RDB 먼저 로드 후 AOF에 반영하므로 재시작 시 복구가 빠르다.
• RDB기반으로 저장공간이 최적화되며, 디스크 I/O의 부담이 적다.

 

☑️ 기존 AOF vs AOF-RDB Hybrid

기존 AOF 방식과 AOF-RDB Hybrid 방식을 비교해보자.

비교 항목	기존 AOF (appendonly.aof)	AOF-RDB Hybrid (appendonly.aof.X.base.rdb)
파일 구조	하나의 appendonly.aof 파일	RDB + AOF Hybrid 구조
기록 방식	모든 명령을 순차적으로 저장	RDB 스냅샷 + AOF delta 저장
성능	시간이 지날수록 느려짐	더 빠르고 최적화됨
Redis 재시작 시 복구 속도	느림 (전체 명령 실행)	빠름 (RDB 먼저 로드 후 AOF 반영)
저장 공간	크기가 계속 증가	RDB 기반으로 최적화됨
디스크 I/O 부담	모든 명령 저장으로 부담 ↑	RDB 기반이라 부담 ↓

 

 

 

 

[3] Redis 데이터 백업 전략의 선택

그럼 Redis 데이터 백업 전략을 어떻게 결정하는 것이 좋을까? Redis 7.0 이전과 이후로 정리해보면 아래와 같다.

Redis 7.0 이전

• redis를 캐시로만 사용한다 ⇒ 저장 공간 낭비가 될 수 있으므로 백업 기능이 없어도 된다.
• 백업은 필요하지만 어느 정도 데이터 손실이 발생해도 괜찮다 ⇒ RDB 방식
• 장애 상황 직전까지 모든 데이터가 보장되어야 한다. ⇒ AOF 방식
• 일반적인 Redis 운영 환경 ⇒ RDB+AOF 혼용
  (주기적으로 RDB으로 백업하고, 다음 스냅샷까지의 저장을 AOF방식으로 수행)

Redis 7.0 이후

• 대부분의 운영 환경 ⇒ AOF-RDB Hybrid 방식
• 금융, 트랜잭션 시스템 등 극한의 데이터 신뢰성이 필요한 경우 ⇒ 기존 AOF 방식

 

 

---

참고자료

https://inpa.tistory.com/entry/REDIS-📚-데이터-영구-저장하는-방법-데이터의-영속성

https://hoons-dev.tistory.com/142

https://blog.mikihands.com/ko/whitedec/2025/2/19/redis-aof-rdb-hybrid-vs-aof/

https://blog.mikihands.com/ko/whitedec/2025/2/17/redis-aof-rewrite-performance-optimization/

https://www.elancer.co.kr/blog/detail/768