문서 메뉴
문서 홈
/
MongoDB 매뉴얼
/ /

파일 시스템 스냅샷을 사용한 백업 및 복원

이 페이지의 내용

  • 스냅샷 개요
  • 고려 사항
  • Linux에서 LVM을 사용한 백업 및 복원
  • 인스턴스를 별도의 볼륨에 저널 파일로 백업 혹은 저널링 없이 인스턴스 백업

이 문서에서는 LVM 또는 스토리지 어플라이언스와 같은 시스템 수준 도구를 사용하여 MongoDB 독립형 서버 및 복제본 세트의 백업을 만드는 절차와 해당 복원 전략을 설명합니다. 샤드 클러스터에 대한 자세한 내용은 파일 시스템 스냅샷으로 샤드 클러스터 백업을 참조하세요.

이러한 파일 시스템 스냅샷 또는 '블록 수준' 백업 방법은 시스템 수준 도구를 사용하여 MongoDB의 데이터 파일을 보관하는 장치의 복사본을 만듭니다. 이러한 방법은 빠르게 완료되고 안정적으로 작동하지만, MongoDB 외부에서 추가 시스템 구성이 필요합니다.

다음도 참조하세요.

스냅샷은 라이브 데이터와 특수 스냅샷 볼륨 사이에 포인터를 생성합니다. 이러한 포인터는 이론적으로 '하드 링크'와 같습니다. 작업 데이터가 스냅샷에서 분리되면 스냅샷 프로세스에서는 쓰기 중 복사 전략을 사용합니다. 따라서 스냅샷은 수정된 데이터만 저장합니다.

스냅샷을 만든 후 파일 시스템에 스냅샷 이미지를 마운트하고 스냅샷에서 데이터를 복사합니다. 결과 백업에는 모든 데이터의 전체 복사본이 포함됩니다.

MongoDB 3.2에는 MongoDB 인스턴스의 데이터 파일과 저널 파일이 별도의 볼륨에 있는 경우 WiredTiger 스토리지 엔진을 사용한 MongoDB 인스턴스의 볼륨 수준 백업 지원이 추가되었습니다. 그러나 일관성 있는 백업을 생성하려면 백업 프로세스 중에 데이터베이스를 잠그고 데이터베이스에 대한 모든 쓰기를 일시 중단해야 합니다.

MongoDB 3.2 이전에는 WiredTiger를 사용하여 MongoDB 인스턴스의 볼륨 수준 백업을 생성하려면 데이터 파일과 저널이 동일한 볼륨에 있어야 했습니다.

2} 암호화 모드를 사용하는 암호화된 스토리지 엔진의 AES256-GCM AES256-GCM 경우 는 모든 프로세스가 키와 함께 고유한 카운터 블록 값을 사용하도록 요구합니다.

2} 암호로 구성된 암호화된 스토리지 엔진의 경우: AES256-GCM

  • 핫 백업에서 복원
    4.2부터 "hot" 백업을 통해 가져온 파일에서 복원하는 경우(즉, mongod가 실행 중일 때), MongoDB는 시작 시 "더티" 키를 감지하고 데이터베이스 키를 자동으로 롤오버하여 IV(초기화 벡터) 재사용을 방지할 수 있습니다.
  • 콜드 백업에서 복원

    그러나 "cold" 백업을 통해 가져온 파일에서 복원하는 경우(즉, mongod가 실행 중이 아닌 경우), MongoDB는 시작 시 "더티" 키를 감지할 수 없으며, IV를 재사용하면 기밀성 및 무결성 보증이 무효화됩니다.

    4.2부터 콜드 파일 시스템 스냅샷에서 복원한 후 키 재사용을 방지하기 위해 MongoDB는 새로운 명령줄 옵션 --eseDatabaseKeyRollover를 추가합니다. --eseDatabaseKeyRollover 옵션으로 시작하면 mongod 인스턴스는 AES256-GCM 암호로 구성된 데이터베이스 키를 롤오버하고 종료합니다.

일반적으로 MongoDB Enterprise에 파일 시스템 기반 백업을 사용하는 경우 가능하면 핫 백업 기능을 사용하세요.

스냅샷이 실행될 때 데이터베이스가 유효해야 합니다. 즉, 데이터베이스에서 허용하는 모든 쓰기가 디스크(저널 또는 데이터 파일)에 완전히 기록되어 있어야 합니다.

백업이 수행될 때 디스크에 없는 쓰기가 있는 경우, 백업에 이러한 변경 내용이 반영되지 않습니다.

WiredTiger 스토리지 엔진 의 경우, 데이터 파일은 마지막 체크포인트 시점의 일관된 상태를 반영합니다. 체크포인트는 데이터 2GB마다 또는 1분마다 발생합니다.

스냅샷은 전체 디스크 이미지의 이미지를 생성합니다. 전체 시스템을 백업해야 하는 경우가 아니라면 다른 데이터가 포함되지 않은 하나의 논리 디스크에 MongoDB 데이터 파일, 저널(해당되는 경우) 및 구성을 격리하는 것을 고려하세요.

또는 모든 MongoDB 데이터 파일을 전용 기기에 저장하여 관련 없는 데이터를 중복없이 백업할 수 있습니다.

스냅샷에서 다른 시스템으로 데이터를 복사합니다. 이렇게 하면 사이트 장애로부터 데이터를 안전하게 보호할 수 있습니다.

증분 백업 절차는 이 튜토리얼에 포함되어 있지 않습니다. 스냅샷 방법에 따라 제공되는 기능이 다르지만, 아래에 설명된 LVM 방법은 증분 백업을 캡처하는 능력을 제공하지 않습니다.

mongod 인스턴스에서 저널링을 활성화했다면 모든 종류의 파일 시스템 또는 볼륨/블록 수준 스냅샷 도구를 사용하여 백업을 만들 수 있습니다.

Linux 기반 시스템에서 자체 인프라를 관리하는 경우, 시스템을 LVM으로 구성하여 디스크 패키지와 스냅샷 기능을 제공하도록 설정하세요. 또한 클라우드/가상화 환경 에서 LVM 기반 설정을 사용할 수도 있습니다.

참고

LVM을 실행하면 추가적인 유연성이 제공되며 스냅샷을 사용하여 MongoDB를 백업할 수 있습니다.

배포가 인스턴스 내에 RAID가 구성된 Amazon의 EBS(Elastic Block Storage)에 의존하는 경우, 플랫폼의 스냅샷 도구를 사용하여 모든 디스크에서 일관된 상태를 얻는 것은 불가능합니다. 대안으로 다음 중 하나를 수행할 수 있습니다.

  • 디스크에 대한 모든 쓰기를 플러시하고 쓰기 잠금을 생성하여 백업 프로세스 동안 일관된 상태를 유지합니다.

    이 옵션을 선택하는 경우 별도의 볼륨에 저널 파일로 인스턴스 백업 혹은 저널링 없이 인스턴스 백업 을 참조하세요.

  • 시스템 내 RAID 위에 MongoDB 데이터 파일을 실행하고 보관하도록 LVM을 구성합니다.

    이 옵션을 선택하는 경우 스냅샷 만들기에 설명된 LVM 백업 작업을 수행하세요.

이 섹션에서는 Linux 시스템에서 LVM을 사용하는 간단한 백업 프로세스에 대한 개요를 설명합니다. 도구, 명령 및 경로는 시스템에 따라 (약간) 다를 수 있지만, 다음 단계는 백업 작업에 대한 높은 수준의 개요를 제공합니다.

참고

다음 절차는 백업 시스템 및 인프라에 대한 지침으로만 사용하세요. 프로덕션 백업 시스템은 다양한 애플리케이션별 요구 사항 및 환경별로 고유한 요소를 고려해야 합니다.

샤딩된 클러스터에 대한 자세한 내용은 파일 시스템 스냅샷을 사용하여 샤딩된 클러스터 백업을 참조하세요.

버전 3.2에서 변경됨:MongoDB 3.2부터는 WiredTiger를 사용해 MongoDB 인스턴스를 볼륨 단위로 백업할 때 데이터 파일과 저널이 단일 볼륨에 있지 않아도 됩니다.

LVM을 사용하여 스냅샷을 생성하려면 다음 명령을 root로 실행하세요.

lvcreate --size 100M --snapshot --name mdb-snap01 /dev/vg0/mongodb

이 명령은 vg0 볼륨 그룹에 있는 mongodb 볼륨의 mdb-snap01 이라는 LVM 스냅샷(--snapshot 옵션 사용)을 만듭니다.

이 예에서는 /dev/vg0/mdb-snap01에 위치한 mdb-snap01이라는 이름의 스냅샷을 만듭니다. 시스템 볼륨 그룹 및 장치의 위치와 경로는 운영 체제의 LVM 구성에 따라 약간 다를 수 있습니다.

매개 변수 --size 100M으로 인해 스냅샷의 최대 용량은 100메가바이트입니다. 이 크기는 디스크에 있는 데이터의 총량을 반영하는 것이 아니라 /dev/vg0/mongodb의 현재 상태와 스냅샷 생성 시점(예: /dev/vg0/mdb-snap01) 사이의 차이의 양을 반영합니다.

경고

특히 시스템에서 데이터를 복사하거나 임시 이미지로 복사하는 데 걸리는 시간을 고려하여 데이터 증가를 수용할 수 있도록 스냅샷의 공간을 충분히 만들어야 합니다.

스냅샷 공간이 부족하면 스냅샷 이미지를 사용할 수 없게 됩니다. 이 논리 볼륨을 삭제하고 다른 논리 볼륨을 만드세요.

명령이 반환되면 스냅샷이 존재합니다. 언제든지 스냅샷에서 직접 복원하거나, 새 논리 볼륨을 생성하여 이 스냅샷에서 대체 이미지로 복원할 수 있습니다.

스냅샷은 고품질 백업을 빠르게 생성하는 데 유용하지만, 백업 데이터를 저장하기 위한 형식으로는 적합하지 않습니다. 스냅샷은 일반적으로 원본 디스크 이미지와 동일한 스토리지 인프라에 의존하고 상주합니다. 따라서 이러한 스냅샷을 아카이브하여 다른 곳에 보관하는 것이 중요합니다.

스냅샷을 만든 후 스냅샷을 마운트하고 데이터를 별도의 스토리지에 복사합니다. 백업 이미지를 오프라인으로 옮길 때 시스템에서 압축을 시도할 수 있습니다. 또는 다음 절차에 따라 스냅샷 이미지의 블록 수준 복사본을 만듭니다.

umount /dev/vg0/mdb-snap01
dd if=/dev/vg0/mdb-snap01 | gzip > mdb-snap01.gz

위의 명령 시퀀스는 다음을 수행합니다.

  • /dev/vg0/mdb-snap01 장치가 마운트되지 않았는지 확인합니다. 마운트된 파일 시스템 또는 파일 시스템 스냅샷의 블록 수준 복사본을 만들지 마세요.

  • dd 명령을 사용하여 전체 스냅샷 이미지의 블록 수준 복사를 수행하고, 결과를 현재 작업 디렉토리에 gzip 파일로 압축합니다.

    경고

    이 명령은 현재 작업 디렉토리에 큰 gz 파일을 생성합니다. 이 명령은 여유 공간이 충분한 파일 시스템에서 실행해야 합니다.

LVM으로 생성된 스냅샷을 복원하려면 다음 명령 시퀀스를 실행합니다.

lvcreate --size 1G --name mdb-new vg0
gzip -d -c mdb-snap01.gz | dd of=/dev/vg0/mdb-new
mount /dev/vg0/mdb-new /srv/mongodb

위의 시퀀스는 다음을 수행합니다.

  • /dev/vg0 볼륨 그룹에 mdb-new라는 새 논리 볼륨을 생성합니다. 새 장치의 경로는 /dev/vg0/mdb-new가 됩니다.

    경고

    이 볼륨의 최대 크기는 1기가바이트입니다. 원본 파일 시스템의 총 크기가 1GB 이상이면 복원이 실패합니다.

    1G를 원하는 볼륨 크기로 변경합니다.

  • mdb-snap01.gzmdb-new 디스크 이미지로 압축을 풀고 아카이브를 해제합니다.

  • mdb-new 디스크 이미지를 /srv/mongodb디렉토리에 마운트합니다. MongoDB 데이터 파일 위치 또는 필요에 따라 다른 위치에 해당하도록 마운트 지점을 수정합니다.

참고

복원된 스냅샷에는 오래된 mongod.lock 파일이 있습니다. 스냅샷에서 이 파일을 제거하지 않으면 MongoDB는 오래된 잠금 파일이 잘못된 종료를 나타내는 것으로 간주할 수 있습니다. 을 활성화한 상태에서 실행 storage.journal.enabled 중이고 을 사용 db.fsyncLock() 하지 않는 경우 파일을 제거할 필요가 없습니다.mongod.lock db.fsyncLock() 를 사용하는 경우 잠금을 제거해야 합니다.

압축된 gz 파일에 쓰지 않고 백업을 복원하려면 다음 명령 시퀀스를 사용하세요.

umount /dev/vg0/mdb-snap01
lvcreate --size 1G --name mdb-new vg0
dd if=/dev/vg0/mdb-snap01 of=/dev/vg0/mdb-new
mount /dev/vg0/mdb-new /srv/mongodb

참고

버전 3.6에 새로 추가됨:

모든 MongoDB 컬렉션에는 기본적으로 UUID가 포함되어 있습니다. MongoDB가 컬렉션을 복원할 때 복원된 컬렉션은 본래의 UUID를 유지합니다. UUID가 없는 컬렉션을 복원하는 경우, MongoDB는 복원된 컬렉션에 대한 UUID를 생성합니다.

컬렉션 UUID에 대한 자세한 내용은 컬렉션 을 참조하세요.

결합된 프로세스와 SSH를 사용하여 시스템 외부 백업을 구현할 수 있습니다.

이 순서는 SSH를 사용하여 원격 시스템에 백업을 보관하고 압축한다는 점을 제외하면 위에서 설명한 절차와 동일합니다.

다음 절차를 고려하세요.

umount /dev/vg0/mdb-snap01
dd if=/dev/vg0/mdb-snap01 | ssh username@example.com gzip > /opt/backup/mdb-snap01.gz
lvcreate --size 1G --name mdb-new vg0
ssh username@example.com gzip -d -c /opt/backup/mdb-snap01.gz | dd of=/dev/vg0/mdb-new
mount /dev/vg0/mdb-new /srv/mongodb

버전 3.2에서 변경됨:MongoDB 3.2부터는 WiredTiger를 사용해 MongoDB 인스턴스를 볼륨 단위로 백업할 때 데이터 파일과 저널이 단일 볼륨에 있지 않아도 됩니다. 그러나 백업의 일관성을 유지하려면 백업 프로세스 중에 데이터베이스를 잠그고 데이터베이스에 대한 모든 쓰기를 일시 중단해야 합니다.

mongod 인스턴스가 저널링 없이 실행 중이거나 저널 파일이 별도의 볼륨에 있는 경우, 백업 프로세스 중에 쓰기를 방지하기 위해 모든 쓰기를 디스크에 플러시하고 데이터베이스를 잠가야 합니다. 복제본 세트 구성이 있는 경우 읽기를 수신하지 않는 세컨더리(즉, 숨겨진 멤버)를 백업에 사용합니다.

1

디스크에 쓰기를 플러시하고 데이터베이스를 '잠금'하려면 다음을 참고해 mongosh에서 db.fsyncLock() 메소드를 실행합니다.

db.fsyncLock();
2
3

스냅샷이 완료된 후 데이터베이스 잠금을 해제하려면 mongosh에서 다음 명령을 사용합니다.

db.fsyncUnlock();
← MongoDB 백업 방법