개발자를위한레디스 7장 - 레디스 데이터 백업 방법

레디스 데이터 백업 방법

Posted Jun 14, 2025

redis

By ydj515

views 12 min read

레디스에서 데이터를 영구 저장하기

레디스를 캐시가 아닌 영구 저장소와 같은 용도로 사용한다면 디스크에 데이터를주기적으로 백업하는 것이 안전합니다.

복제: 가용성을 위한 것
백업: 장애 상황에서 데이터의 복구를 위한 것

백업 방식

AOF : Append OnlyFile
- 레디스 인스턴스가 처리한 모든 쓰기 작업을 차례대로 기록
- 복원 시에는 파일을 다시 읽어가며 데이터 세트를 재구성
- 원하는 시점으로 복구 가능
- RDB 파일보다 크기가 크고 주기적으로 압축해 재작성해야 함
RDB : Redis DataBase
- 일정 시점에 메모리에 저장된 데이터 전체를 저장(snapshot 방식)
- 시점 단위로 여러 백업본을 저장 가능
- AOF 파일보다 복원이 빠름

레디스에서 데이터를 복원할 수 있는 시점은 서버가 재시작될 뿐입니다. 또한, RDB파일보다 AOF 파일이 더 내구성이 보장된다고 판단하기 때문에 2개의 파일이 모두 존재할 때에는 AOF의 데이터를 로드합니다.

RDB 방식의 데이터 백업

원하는 시점에 메모리 자체를 스냅숏 찍듯 저장할 수 있기 때문에 백업에 적합한 파일 형태로 볼 수 있습니다. 그러나 저장 시점부터 장애가 발생한 직전까지의 데이터는 손실될 수 있습니다. 설정파일에서 특정 조건에 파일이 자동으로 저장되도록 지정할 수 있으며, 사용자가 원하는 시점에 커맨드로 수동으로 파일 생성이 가능합니다.

  
save <기간(초)> <기간 내 변경된 키의 개수> # 일정한 기간동안 변경된 키의 개수가 조건에 맞을 때 자동으로 RDB 파일 저장
dbfilename <RDB 파일 이름> # RDB 파일은 dbfilename 옵션에 지정된 이름으로 생성
dir <RDB 파일이 저장될 경로> # dir에 지정한 경로에 저장

레디스는 실행중인 상태에서 설정파일을 변경해도 적용되지않습니다. 실행중인 레디스에서 파라미터를 수정할때 redis-cli에서 직접 CONFIG SET 커맨드로 설정을 변경한 후, CONFIG REWRITE 커맨드를 이용해 설정파일을 재작성하는 과정을 거쳐야합니다. 설정파일을 재작성하지 않은 상태에서 레디스 인스턴스가 재시작된다면 레디스는 기존 설정파일에 작성된 옵션, 즉 변경되지않은 옵션 값으로 설정됩니다.

수동으로 RDB 파일 생성

SAVE 커맨드
- 동기 방식으로 파일을 저장
- 파일 생성이 완료될 때까지 다른 모든 클라이언트의 명령을 차단
BGSAVE 커맨드
- fork를 호출해 자식 프로세스를 생성하며 생성된 자식 프로세스가 백그라운드에서 RDB 파일을 생성한 뒤 종료
- 백그라운드로 데이터가 저장되고 있을 때 이 커맨드를 수행하며 에러를 반환 (SCHEDULE 옵션을 사용하면 기존 백업 완료 후 다시 BGSAVE 수행)

복제를 사용할 경우 자동으로 RDB 파일 생성

복제본에서 REPLICAOF 커맨드를 이용해 복제를 요청하면 마스터 노드에서는 RDB 파일을 새로 생성해 복제본에 전달합니다.

이미 복제 연결이 돼 있는 상태에서도 상황에 따라 마스터에서는 언제든지 RDB 파일을 재생성할 수 있습니다.

AOF 방식의 데이터 백업

appendonly 옵션을 yes로 지정하면 AOF 파일에 주기적으로 데이터가 저장됩니다.

  
appendonly yes
appendfilename "appendonly.aof"
appenddirname "appendonlydir"

기본적으로 AOF 파일은 apendonly.aof라는 이름으로 저장됩니다. 버전 7.0 이상부터 AOF파일은 여러개로 저장되며 appenddirname옵션에서 지정된디럭토리 하위에 저장됩니다.

다만, AOF의 특성상 인스턴스가 실행되는 시간에 비례해서 AOF 파일 크기가 계속 증가하게 됩니다.

AOF 파일을 재구성하는 방법

AOF 파일을 이용한 백업 기능을 안정적으로 사용하려면 점점 커지는 파일을 주기적으로 압축 시키는 재구성 작업이 필요합니다.

기본이 되는 바이너리 형태의 RDB 파일, 증가하는 RESP의 텍스트 형태의 AOF 파일로 나눠 데이터를 관리합니다.

현재 레디스가 바라보고 있는 파일이 어떤 것인지 나타내는 매니페스트 파일이 추가적으로 도입되었습니다.

세 파일 모두 설정 파일에 지정한 appenddirname 이름의 폴더 내에 저장됩니다.

자동 AOF 재구성

auto-aof-rewrite-percentage는 AOP 파일을 다시 쓰기 위한 시점을 정하는 옵션.

마지막으로 재구성됐던 AOF 파일의 크기와 비교해, 현재의 AOF 파일이 지정된 퍼센트만큼 커졌을 때 재구성을 시도함.

수동 AOF 재구성

BGREWRITEAOF 커맨드를 이용하면 원하는 시점에 직접 AOF 파일을 재구성 가능.–

AOF 타임스탬프

aof-timestamp-enabled yes

aof-timestamp-enabled 옵션을 활성화시키면 AOF 데이터가 저장될 때 타임스탬프도 함께 저장

AOF 파일 복원

시점 복원(point-in-time-recovery)에서 사용한 redis-check-aof 프로그램은 AOF 파일이 손상됐을 때에도 사용할 수 있음

레디스가 의도치 않은 장애로 중단됐을 때 redis-check-aof 프로그램을 사용하면 AOF 파일의 상태가 정상적인지 확인 가능

fix 옵션을 사용한 복구 또한 원본 파일을 변경하기 때문에 이전의 데이터를 보호하고 싶은 경우 원본 데이터를 다른 곳에 복사해두는 것이 안전

AOF 파일의 안전성

레디스에서 AOF 파일을 저장할 때 APPENDSYNC 옵션을 이용하면 FSYNC 호출을 제어할 수 있으며, 즉 파일 저장의 내구성 제어가 가능

APPENDSYNC no: AOF 데이터를 저장할 때 WRITE 시스템 콜을 호출
APPENDSYNC always: AOF 데이터를 저장할 때 항상 WRITE와 FSYNC 시스템 콜을 함께 호출
APPENDSYNC everysec: 데이터를 저장할 때 WRITE 시스템 콜을 호출하며, 1초에 한 번씩 FSYNC 시스템 콜을 호출

백업을 사용할 때 주의할 점

RDB와 AOF 파일을 사용하는 경우 인스턴스의 maxmemory 값은 실제 서버 메모리보다 여유를 갖고 설정하는 것이 좋습니다. BGSAVE커맨드로 RDB 파일을 저장하거나 AOF 재구성을 진행할 때 레디스는 fork()를 이용해 자식프로세스를 생성하는데 이 자식프로세스는 레디스의 메모리를 그대로 파일에 저장해야하며, 기존의 부모 프로세스는 다른 메모리의 데이터를 이용해 다른 클라이언트의 연결을 처리해야합니다. 이때 레디스는 COW(Copy-On-Write) 방식을 이용해 메모리상의 데이터를 하나 더 복사하는 방법을 이용해 백업을 진행하면서도 클라이언트의 요청 사항을 받아 메모리의 데이터를 읽고 수정하는 작업을 진행할 수 있습니다.

COW 과정에서 물리적 메모리에 있는 실제 메모리 페이지가 그대로 복제되기 때문에 최악의 경우 레디스는 기존 메모리 용량의 2배를 사용하게 될 수도 있습니다.

따라서, 레디스의 maxmemory값이 너무 크면 레디스의 COW 동작으로 인해 OS메모리가 가득 차는 상황이 발생할 수 있으며, 이로인해 OOM(Out Of Memory)문제로 서버가 다운될 수 있습니다.

다음은 책에서 나온 메모리 가이드입니다.

RAM	Maxmemory	비율
2GB	638MB	33%
4GB	2048MB	50%
8GB	4779MB	58%
16GB	10240MB	63%
32GB	21163MB	65%
64GB	43008MB	66%

RDB 스냅샷을 저장하는 도중엔 AOF의 재구성 기능을 사용할 수 없고, AOF 재구성이 진행될 때에는 BGSAVE를 실행할 수 없습니다.

redis, books