로컬 LLM 벡터DB 백업 6단계 · 임베딩 보존과 복구 확인

가이드: 스냅샷 · 메타데이터 · 복구 검증

로컬 LLM 벡터DB 백업은 폴더를 복사하는 작업으로 끝나지 않습니다. 벡터, 문서 조각, 메타데이터, 컬렉션 설정, 임베딩 모델 버전이 함께 보존되어야 검색 결과를 같은 상태로 복구할 수 있습니다. 이 글은 Qdrant 같은 서버형 벡터DB를 중심으로 백업 파일을 만들고, 별도 환경에서 복구하고, 검색 결과까지 확인하는 순서를 정리합니다.

먼저 보는 핵심 요약

백업 대상은 벡터만이 아니라 payload, 컬렉션 설정, alias, 임베딩 모델 정보까지 포함합니다.
운영 중인 원본에 덮어쓰지 말고 새 컬렉션 또는 격리된 인스턴스에서 복구 검증을 먼저 합니다.
스냅샷 파일의 크기와 해시, 생성 시각, DB 버전을 함께 기록합니다.
복구 성공은 API 응답이 아니라 기준 질문의 검색 결과와 문서 ID가 일치할 때 확정합니다.
복구 중에는 스냅샷과 복구 데이터가 동시에 존재하므로 여유 디스크를 계산해야 합니다.

문제 정의: 벡터DB 백업이 어려운 이유

로컬 RAG 시스템은 원문 파일, 파서 결과, 청크, 임베딩 벡터, 메타데이터, 인덱스가 연결된 구조입니다. 원문만 보관하면 다시 임베딩할 수 있지만 시간과 비용이 들고, 당시의 청크 규칙이나 모델 버전을 잃으면 검색 결과가 달라집니다. 반대로 DB 디렉터리만 복사하면 실행 중 쓰기 작업 때문에 파일 상태가 서로 다른 시점으로 섞일 수 있습니다.

따라서 백업의 목적을 먼저 정해야 합니다. 장애 후 같은 서버를 되살리는 재해 복구인지, 새 장비로 옮기는 마이그레이션인지, 특정 컬렉션만 보관하는 아카이브인지에 따라 방법이 달라집니다. 로컬 LLM 벡터DB 백업의 완료 기준은 파일 생성이 아니라 격리된 환경에서 같은 검색 결과를 재현하는 것입니다.

현실 차이: 파일 복사와 스냅샷의 차이

서비스를 완전히 중지하고 데이터 디렉터리를 복사하는 방식은 단일 노드의 작은 실험 환경에서는 사용할 수 있습니다. 그러나 운영 중인 프로세스가 파일을 변경하면 복사 시점이 일치하지 않을 수 있습니다. 서버형 DB가 제공하는 스냅샷 API는 컬렉션 데이터와 설정, 인덱스를 일관된 단위로 묶는 데 유리합니다.

Qdrant 공식 문서는 컬렉션 스냅샷을 특정 시점의 데이터와 설정을 담은 아카이브로 설명합니다. 분산 환경에서는 노드별 스냅샷이 필요하고, 컬렉션 alias는 별도로 관리해야 합니다. 복구 우선순위 설정에 따라 기존 데이터와 스냅샷 중 어느 쪽이 우선되는지도 달라지므로 기본값을 무심코 사용하면 빈 컬렉션이나 예상과 다른 결과가 생길 수 있습니다.

로컬 LLM 벡터DB 백업 판단 기준 1: 백업 단위와 복구 목표

컬렉션 하나만 복구하면 되는지, 전체 스토리지를 복구해야 하는지 구분합니다. 고객별 컬렉션이 분리돼 있고 일부만 이동한다면 컬렉션 스냅샷이 적합합니다. 여러 컬렉션과 공통 설정을 한 번에 보존해야 한다면 전체 스토리지 백업이나 클러스터 백업을 검토합니다.

복구 목표 시간과 허용 가능한 데이터 손실 범위도 기록합니다. 하루 한 번 백업이면 장애 직전 최대 하루의 변경이 사라질 수 있습니다. 문서가 자주 들어오는 시스템은 변경량이나 시간 기준으로 백업 주기를 촘촘하게 잡고, 백업 완료 후 원격 또는 별도 디스크로 복제합니다.

로컬 LLM 벡터DB 백업 판단 기준 2: 임베딩 모델과 청크 규칙 보존

같은 문장을 다른 임베딩 모델로 변환하면 벡터 공간이 달라질 수 있습니다. 모델 이름만 적지 말고 정확한 버전, 차원 수, 정규화 여부, 거리 함수, 청크 길이, 겹침 길이, 전처리 규칙을 함께 기록합니다. 컬렉션 설정의 벡터 차원과 복구 후 사용하는 모델 차원이 맞지 않으면 새 데이터 입력이 실패하거나 검색 품질이 무너집니다.

메타데이터 스키마도 백업 계약의 일부입니다. 문서 ID, 원본 경로, 작성일, 접근 권한, 언어, 청크 순번 같은 필드 이름과 자료형을 저장합니다. 필터 검색을 사용하는 시스템은 payload index 설정까지 확인해야 합니다. 벡터 수만 같아도 필터 인덱스가 빠지면 응답 속도와 권한 필터가 달라질 수 있습니다.

로컬 LLM 벡터DB 백업 판단 기준 3: 저장 공간과 버전 호환성

스냅샷 생성과 복구에는 원본 데이터 외의 추가 공간이 필요합니다. Qdrant의 마이그레이션·복구 안내는 복구 과정에서 스냅샷 파일과 복원된 컬렉션이 동시에 존재할 수 있어 대상 환경에 충분한 디스크 여유를 확보해야 한다고 설명합니다. 디스크가 빠듯한 상태에서 복구를 시작하면 중간 실패와 불완전한 파일이 남을 수 있습니다.

소스와 대상 DB 버전도 기록합니다. 버전 차이가 크면 스냅샷 형식이나 인덱스 구조가 호환되지 않을 수 있습니다. 먼저 검증 인스턴스에서 복구하고, 공식 문서가 허용하는 버전 범위를 확인합니다. 운영 서버 업그레이드와 데이터 이동을 한 번에 수행하면 실패 원인을 구분하기 어려우므로 단계를 분리합니다.

로컬 LLM 벡터DB 백업 실행법 1: 백업 전 인벤토리 만들기

백업 전에 컬렉션 이름, 포인트 수, 벡터 차원, 거리 함수, shard와 replica 수, payload index, alias를 JSON으로 기록합니다. 임베딩 모델과 청크 설정, 애플리케이션 커밋 ID도 함께 남깁니다. 이 인벤토리는 복구 후 비교 기준이 됩니다.

기준 검색 질문도 준비합니다. 일반 질문, 고유 문서명을 묻는 질문, 날짜 필터 질문, 권한 필터 질문, 결과가 없어야 하는 질문을 포함합니다. 각 질문에서 기대하는 상위 문서 ID와 점수 범위를 저장하면 복구 후 검색 품질을 빠르게 비교할 수 있습니다.

실행법 2: 스냅샷 생성과 외부 보관

Qdrant에서는 컬렉션 스냅샷 API를 호출해 스냅샷을 만들고 목록에서 생성 결과를 확인합니다. 생성된 파일은 같은 서버에만 두지 말고 별도 디스크나 접근 통제된 저장소로 복사합니다. 파일명에는 컬렉션, 생성 시각, DB 버전을 포함하고 SHA-256 같은 해시를 계산해 전송 중 손상 여부를 확인합니다.

분산 클러스터라면 컬렉션을 구성하는 각 노드의 스냅샷 절차를 공식 문서에 맞춰 수행합니다. 노드 하나의 파일만으로 전체 복구가 된다고 가정하지 않습니다. alias와 애플리케이션 환경변수, 비밀값은 스냅샷과 분리해 암호화된 설정 저장소에서 관리합니다.

실행법 3: 원본을 건드리지 않는 복구 리허설

복구는 새 컬렉션 이름 또는 격리된 검증 인스턴스에서 시작합니다. 운영 컬렉션에 바로 덮어쓰지 않습니다. 스냅샷을 업로드하거나 복구 위치를 지정하고, 마이그레이션 목적이라면 스냅샷 데이터가 우선되도록 복구 우선순위를 확인합니다.

복구가 끝나면 포인트 수와 컬렉션 설정을 인벤토리와 비교합니다. 이어서 기준 검색 질문을 실행하고 상위 문서 ID, 점수, payload, 필터 결과를 비교합니다. 신규 문서 한 건의 입력과 삭제도 시험해 읽기뿐 아니라 쓰기 경로가 정상인지 확인합니다.

실행법 4: 애플리케이션 연결 전환

검증이 통과하면 애플리케이션의 연결 대상을 새 컬렉션으로 전환합니다. alias를 사용하는 환경이라면 alias 변경으로 전환 시간을 줄일 수 있습니다. 전환 직전 쓰기 작업을 잠시 멈추거나 변경분을 동기화해 백업 시점 이후 데이터가 빠지지 않게 합니다.

전환 후에는 검색 오류율, 응답 시간, 결과 없음 비율, 권한 필터 실패를 모니터링합니다. 문제가 생기면 기존 컬렉션으로 돌아갈 수 있도록 원본을 즉시 삭제하지 않습니다. 안정화 기간이 지나고 검증 로그가 쌓인 뒤에만 오래된 복사본의 보존 정책을 적용합니다.

실행법 5: 자동 백업과 보존 정책

백업 작업은 생성, 다운로드, 해시 검증, 원격 복사, 오래된 파일 정리, 복구 시험 결과 기록으로 나눕니다. 생성 명령이 성공했다고 전체 작업을 성공으로 표시하지 않습니다. 원격 저장소에 파일이 존재하고 해시가 맞으며 정기 복구 시험이 통과해야 합니다.

보존 정책은 최근 일별 백업, 주별 백업, 월별 백업처럼 층을 나눌 수 있습니다. 모든 파일을 무기한 보관하면 저장 비용이 늘고 관리가 어려워집니다. 삭제 작업은 최소 보존 개수와 마지막 검증 성공본을 보호하는 조건을 둡니다.

실행법 6: 복구 보고서 고정

복구 보고서에는 백업 ID, 해시, 생성 시각, 소스와 대상 버전, 복구 소요 시간, 포인트 수 비교, 검색 질문 통과율, 쓰기 시험 결과, 남은 경고를 기록합니다. 이 보고서가 있어야 다음 장애에서 같은 절차를 반복할 수 있습니다.

복구 실패도 분류합니다. 파일 손상, 버전 불일치, 디스크 부족, 권한 오류, 벡터 차원 불일치, alias 누락을 구분하면 재시도 조건이 분명해집니다. 원인을 모른 채 같은 명령을 반복하지 않습니다.

복구 검증 체크리스트

검증 항목	통과 기준	실패 시 확인
파일 무결성	저장·전송 전후 해시 일치	불완전 다운로드, 저장소 오류
컬렉션 구조	차원·거리함수·포인트 수 일치	버전, 설정, 스냅샷 범위
메타데이터	필수 payload와 index 존재	스키마 변경, alias 누락
검색 결과	기준 질문 상위 문서 일치	모델·청크·정규화 차이
쓰기 경로	입력·조회·삭제 시험 통과	권한, 디스크, API 설정

엔진별로 달라지는 부분

Qdrant는 컬렉션과 전체 스토리지 스냅샷 기능을 제공합니다. Chroma의 로컬 영속 저장은 사용 방식과 배포 형태에 따라 백업 단위가 달라질 수 있으므로 사용 중인 버전의 공식 문서를 확인해야 합니다. FAISS 파일만 사용하는 구조라면 인덱스 파일과 별도로 문서 ID 매핑, 메타데이터 저장소, 임베딩 설정을 함께 보존해야 합니다.

엔진을 바꾸는 마이그레이션은 스냅샷 복구와 다릅니다. 서로 다른 엔진 간에는 포인트와 payload를 내보내 다시 입력하고 인덱스를 재구축해야 할 수 있습니다. 이 경우 원본과 대상에서 같은 질문 세트를 실행해 검색 결과 차이를 측정합니다.

운영 비용과 저장 공간 계산

백업 크기는 벡터 수와 차원, payload 크기, 인덱스 설정에 영향을 받습니다. 현재 컬렉션 크기만큼만 여유 공간을 잡지 말고 스냅샷 파일, 복구 중 생성되는 데이터, 임시 파일, 다음 백업까지 고려합니다. 디스크 사용률에 경고선을 두고 경고선을 넘으면 새 백업 전에 보존 정책을 점검합니다.

복구 시간도 측정합니다. 작은 검증 데이터의 복구 시간이 짧다고 운영 데이터도 같은 비율로 끝난다고 가정하지 않습니다. 정기 리허설에서 실제 크기에 가까운 컬렉션을 사용하고 네트워크와 디스크 처리량을 기록합니다.

공식 자료

복구 리허설에서 확인할 8개 항목

백업 파일이 존재한다는 사실만으로 복구 가능성을 증명할 수는 없습니다. 운영과 분리된 환경에서 정기적으로 복구하고, 사람이 확인할 수 있는 결과를 남겨야 합니다. 리허설 날짜, 사용한 스냅샷, 대상 버전, 소요 시간, 검증 쿼리 결과를 한 묶음으로 기록하면 다음 장애 때 판단 속도가 빨라집니다.

파일 무결성: 스냅샷 크기와 체크섬을 백업 직후 값과 비교합니다.
버전 호환: 소스와 대상 벡터DB의 버전, 스냅샷 호환 범위, 필수 플러그인을 기록합니다.
컬렉션 수: 복구 전후 컬렉션과 샤드 수가 같은지 비교합니다.
포인트 수: 전체 개수뿐 아니라 테넌트나 문서 유형별 개수도 표본으로 대조합니다.
벡터 차원: 임베딩 차원과 거리 함수가 원본 설정과 같은지 확인합니다.
검색 결과: 고정 질의 세트로 상위 결과와 점수 분포를 비교합니다.
메타데이터: 필터에 쓰는 필드, payload, 문서 출처가 손실되지 않았는지 봅니다.
복구 시간: RTO 안에 끝났는지, 네트워크와 디스크 병목이 어디였는지 남깁니다.

고정 질의 세트는 정상 질의만 넣지 않습니다. 결과가 없어야 하는 질의, 특정 테넌트만 나와야 하는 질의, 날짜 필터가 필요한 질의도 포함합니다. 그래야 단순히 벡터가 읽히는 수준을 넘어 서비스 규칙이 그대로 복구됐는지 확인할 수 있습니다.

자동 백업이 멈췄을 때 알림 기준

자동화는 명령 실행보다 실패를 발견하는 장치가 중요합니다. 마지막 성공 시각, 최근 파일 크기, 체크섬 생성 여부, 원격 저장소 복제 결과를 매 실행마다 로그로 남깁니다. 예정 시각을 넘겼는데 새 스냅샷이 없거나 파일 크기가 평소 범위에서 크게 벗어나면 즉시 알림을 보냅니다.

알림에는 실패했다는 문장만 넣지 않고 컬렉션 이름, 실행 호스트, 명령 종료 코드, 저장 위치, 마지막 정상 스냅샷을 포함합니다. 담당자가 로그를 다시 찾지 않아도 첫 대응을 시작할 수 있어야 합니다. 자격증명과 API 키는 알림 본문에 넣지 않으며, 백업 서버와 운영 서버의 권한도 분리합니다.

보존 정책은 일간·주간·월간처럼 복구 시점을 여러 층으로 나눕니다. 최신 파일 하나만 덮어쓰면 논리적 손상이 이미 포함된 뒤 과거 정상 시점으로 돌아갈 수 없습니다. 삭제 작업은 보존 기간과 성공 복구 기록을 확인한 뒤 수행하고, 원격 복제본까지 동시에 지우는 단일 명령은 피합니다.

자주 묻는 질문

데이터 폴더를 압축하면 백업이 되나요?

서비스를 완전히 중지하고 엔진이 허용하는 방식으로 복사한다면 사용할 수 있는 경우가 있습니다. 운영 중 파일 복사는 시점 불일치 위험이 있으므로 서버형 엔진에서는 공식 스냅샷 기능을 우선 검토합니다.

원문 파일도 함께 백업해야 하나요?

그렇습니다. 벡터DB는 검색을 빠르게 하는 파생 데이터입니다. 원문, 파서 설정, 청크 규칙, 임베딩 모델 정보를 함께 보존해야 재구축과 감사가 가능합니다.

복구 후 포인트 수가 같으면 성공인가요?

충분하지 않습니다. payload, 필터, alias, 검색 결과, 쓰기 경로까지 확인해야 합니다. 같은 수의 포인트라도 임베딩 모델이나 메타데이터가 다르면 RAG 결과가 달라질 수 있습니다.

백업 파일은 몇 개 보관해야 하나요?

변경 빈도와 허용 손실 범위에 따라 다릅니다. 최근 일별·주별·월별 계층을 두고 마지막 검증 성공본은 보호하는 방식이 실용적입니다.

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받을 수 있습니다.

마무리

로컬 LLM 벡터DB 백업은 스냅샷 하나를 만드는 명령이 아니라 복구 가능한 상태를 증명하는 절차입니다. 백업 전 인벤토리를 남기고, 공식 스냅샷을 생성하고, 해시를 검증해 외부 저장소에 보관합니다. 복구는 새 컬렉션에서 실행하고 기준 질문, 포인트 수, payload, 필터, 쓰기 경로를 비교합니다.

이 과정을 정기적으로 반복하면 장애가 발생했을 때 어떤 파일을 선택하고 어떤 순서로 복구할지 흔들리지 않습니다. 백업 성공 로그보다 복구 리허설 통과 로그를 운영 기준으로 삼는 것이 핵심입니다.

명령과 API 옵션은 사용 중인 벡터DB 버전과 배포 방식에 따라 달라질 수 있습니다. 운영 적용 전 공식 문서와 검증 환경에서 확인하세요.