2026 Redis 8.0 AOF 재작성 실패, 어떻게 해야 할까? 먼저 디스크와 복구 경로를 확인하세요

AOF 재작성 오류와 디스크 경고가 함께 나타났다면, 파일을 지우거나 운영 서버를 바로 재시작하지 마세요.

먼저 Redis 지속성 상태와 파일 시스템의 여유 공간·인오드를 확인하고, AOF 파일 묶음을 복사해 격리 환경에서 복구를 검증하세요. Redis 8.0의 지원 종료 일정도 확인하되, 버전 업그레이드가 백업이나 복구 훈련을 대신하지는 않습니다. 공식 버전 관리 문서에는 지원 종료일이 2026년 12월 1일로 안내되어 있습니다.

이 글은 Redis 지속성 설정을 맡은 DBA, 복구 가능성을 확인하려는 백엔드 엔지니어, 디스크 경고와 재시작 위험을 다루는 플랫폼 운영자에게 적합합니다.
Redis 서버의 용량과 외부 백업 경로까지 함께 계획하는 기술 책임자도 점검 기준을 확인할 수 있습니다.

Redis 8.0 AOF 재작성 실패는 상태와 파일을 나눠 봅니다

AOF 재작성은 기존 기록을 새 파일 묶음으로 정리하는 백그라운드 작업입니다. 재작성 중에도 새 쓰기가 이어질 수 있으므로 기존 파일, 새로 만들어지는 파일, 작업 중 추가된 기록을 함께 고려해야 합니다. Redis 공식 지속성 문서에서 AOF와 재작성의 동작, 다중 파일 AOF 구조를 먼저 확인하세요.

재작성 오류가 난 뒤 무엇부터 확인해야 하나요?

오류 메시지 하나만으로 원인을 단정하지 말고, Redis가 보고하는 지속성 상태와 파일 시스템 상태를 함께 확인합니다.

redis-cli INFO persistence
df -h /경로/데이터
df -i /경로/데이터
findmnt -T /경로/데이터

INFO persistence 응답에서는 aof_enabled, aof_rewrite_in_progress, aof_last_bgrewrite_status, aof_last_write_status 항목을 살펴봅니다. 항목 이름과 보고 내용은 INFO 명령 문서를 기준으로 확인하세요. 예를 들어 재작성 진행 여부와 마지막 재작성 결과, 마지막 쓰기 상태는 서로 다른 정보입니다. 어느 하나가 정상이라고 해서 파일 전체가 손상되지 않았거나 복구에 성공했다고 판단할 수는 없습니다.

df -h는 파일 시스템의 공간을, df -i는 인오드 여유를 확인하는 데 씁니다. 데이터 디렉터리가 예상한 파일 시스템에 실제로 마운트됐는지도 확인하세요. df 명령 문서는 표시되는 공간 정보의 해석 기준을 설명합니다.

공간 부족과 작업 정체는 다른 원인으로 추적합니다

재작성 중 디스크 공간이 부족해졌다면 어떻게 해야 하나요?

우선 Redis가 쓰는 파일과 매니페스트의 위치를 확인하고, 해당 파일 시스템에서 공간과 인오드가 실제로 부족한지 살펴봅니다. AOF 파일을 임의로 지우는 대신, Redis와 무관한 임시 파일 가운데 안전하게 정리할 수 있는 항목이 있는지 담당 절차에 따라 검토합니다. 정리만으로 필요한 여유 공간을 만들 수 없다면 저장 공간 확장이나 쓰기 부하 조정 가능성을 평가합니다.

디스크 여유가 있어 보이는데도 재작성 상태가 바뀌지 않으면 프로세스 상태, 운영체제 로그, 저장 장치의 입출력 상태를 함께 봅니다. 다른 작업의 자원 경합이나 저장 장치 오류도 후보가 될 수 있지만, 특정 커뮤니티 사례를 근거로 모든 환경의 원인을 정해선 안 됩니다. Redis 로그, 실행 파일과 빌드 정보, 시스템 상태를 보존해 원인을 좁히세요. BGREWRITEAOF 명령 문서에서 명령의 목적과 실행 동작을 확인하되, 명령을 다시 실행하는 것만으로 기존 오류가 해결된다고 가정하지 마세요.

Redis 7 이후의 다중 파일 AOF는 어떻게 온전히 복사하나요?

Redis 공식 지속성 문서에서 현재 파일 목록과 매니페스트의 관계를 확인한 뒤, 매니페스트가 가리키는 기반 파일과 증분 파일을 모두 같은 복구 지점의 묶음으로 확보해야 합니다. 실행 중인 디렉터리에서 파일 몇 개만 골라 복사하면 필요한 기록이 빠지거나 시점이 서로 달라질 수 있습니다. 일관된 복사본을 만들 수 있는 백업 절차를 마련하고, 원본 파일은 별도 보존하세요.

복구가 의심되는 파일에는 먼저 복사본을 만들고, 해당 Redis 버전의 도구 설명을 확인한 뒤 redis-check-aof를 적용합니다. 수정 기능을 쓰더라도 원본이 아니라 복사본에서만 실행하고, 도구가 보고하거나 제거할 수 있는 끝부분 기록을 검토하세요. Redis 공식 AOF 검사와 수정 안내는 도구의 용도와 주의할 경계를 확인하는 기준입니다. 도구가 오류 없이 끝났다는 사실만으로 업무 데이터가 모두 살아났다고 결론 내리면 안 됩니다.

파일을 고친 뒤에는 격리 환경에서 복구를 확인합니다

생산 서버의 파일을 덮어쓰기 전에 백업 사본으로 격리된 Redis 인스턴스를 구성하세요. 운영 환경과 같은 복구 절차를 사용해야 백업 파일만 검사하고 실제 시작 절차를 놓치는 일을 줄일 수 있습니다.

다음 순서로 확인합니다.

1. 복구 지점과 연결된 AOF 파일 묶음, 매니페스트, 백업 시점을 기록합니다.
2. 원본을 보존하고, 검사와 수정 작업에는 별도 복사본을 사용합니다.
3. 운영 서버와 분리된 경로에 복구 사본을 배치합니다.
4. 실제 운영 절차에 맞춰 Redis를 시작하고 로그와 지속성 상태를 확인합니다.
5. 업무에서 사용하는 키와 자료형, 만료 동작, Stream 같은 핵심 불변 조건을 확인합니다.
6. 같은 복구 지점의 RDB 백업도 별도로 검증하고, 두 방식의 결과 차이를 기록합니다.

AOF를 고친 뒤 데이터가 복구됐는지는 무엇으로 판단하나요?

격리 인스턴스가 시작되는지만 보지 말고, 서비스에 중요한 키의 존재와 자료형, 만료 시각, Stream 처리 상태 등 업무 규칙을 확인합니다. 백업 시점 이후의 쓰기가 빠지는 것은 복구 지점에 따라 예상 가능한 차이일 수 있습니다. 따라서 백업 시점과 검증 결과를 대조해야 합니다. 검증을 통과하지 못했다면 생산 파일을 덮어쓰거나 완전 복구를 선언하지 마세요.

저장 공간과 백업 경로는 조건에 맞춰 결정합니다

다음 조건 분기로 용량 조정, 복사본 검증, 외부 백업 중 우선할 작업을 정하세요.

• 파일 시스템의 공간이나 인오드가 부족하고 기존 파일 묶음은 읽을 수 있다면, 원본을 보존한 채 안전한 공간 확보 또는 저장 장치 확장을 먼저 검토합니다.
• 공간은 충분하지만 재작성 상태나 시스템 로그가 비정상이라면, 파일 삭제나 반복 재시작 대신 로그와 프로세스 상태를 보존해 원인을 추적합니다.
• AOF 검사 결과가 불분명하거나 복구 결과가 의심된다면, 운영 데이터에 손대지 말고 별도 복사본을 격리 환경에서 검증합니다.
• 한 장치의 장애로 데이터와 백업이 함께 사라질 수 있다면, 복사본을 다른 서버나 별도 저장 위치에 보관하고 복구 훈련을 계획합니다.

다음 표는 현재 운영 방식과 전용 서버를 비교할 때 확인할 항목입니다. 전용 하드웨어만으로 데이터 중복성이나 백업이 생기는 것은 아닙니다.

저장 장치를 비교할 때는 메모리와 디스크를 함께 설계하는 기준을 메모리와 디스크 계획 안내에서 살펴보고, 운영 서버에 접속해 점검할 담당자는 셸 접속 안내도 확인하세요. Redis 8.0의 지원 종료일이 가까워도 버전 변경은 유지보수 계획의 일부일 뿐, 손상 파일이나 불완전한 백업을 고쳐 주지는 않습니다. 지원 상태와 파일 조작 안내는 운영 버전의 공식 문서에서 다시 확인해야 합니다.

최종 업데이트: 2026년 11월 4일. 지원 일정은 Redis 공식 버전 관리 문서, AOF 동작과 검사 경계는 Redis 공식 지속성 문서를 기준으로 확인했습니다.

공유 환경에서 자원 경쟁이나 저장 장치 정책을 직접 통제하기 어렵고, 장기간 실행되는 Redis에 독립적인 디스크 구성이 필요하다면 전용 AMD 물리 서버가 더 적합할 수 있습니다. 다만 전용 서버도 AOF 복구를 보장하지 않으므로, 디스크 구성과 서버 밖 백업을 함께 설계해야 합니다. OSFP Cloud를 검토한다면 먼저 현재 제공 구성을 확인하고, 필요한 저장 장치 선택지가 파일 배치와 격리 복구 계획에 맞는지 확인하세요.