백업 개요

이 페이지에서는 백업에 대한 정의, 백업의 작동 방식, 일반적인 사용 사례, 백업을 만들고 사용할 때의 권장사항에 대해 설명합니다. 백업을 만들고 관리하는 방법과 백업에서 Filestore 인스턴스를 복원하는 방법은 재해 복구를 위한 데이터 백업을 참조하세요.

백업이란 무엇인가요?

Filestore 백업은 백업을 만드는 시점에 파일 공유의 모든 파일 데이터 및 메타데이터를 포함하는 파일 공유의 복사본입니다.

파일 공유 백업을 생성한 후에는 백업에 영향을 주지 않고 원본 파일 공유를 수정하거나 삭제할 수 있습니다.

백업을 사용하여 파일 공유를 새 Filestore 인스턴스로 복원하거나, 기본 등급 인스턴스의 경우 소스 또는 기존 파일 공유로 복원할 수 있습니다.

백업은 사용자가 만들 때 지정하는 리전 내에 있는 리전별 리소스입니다. 데이터 손실 위험을 줄이기 위해 Filestore 인스턴스와 동일한 리전 또는 다른 리전에 백업을 만들 수 있습니다.

백업은 전역 주소 지정이 가능하며, 모든 리전으로 파일 공유를 복원하기 위한 목적으로 사용될 수 있지만 프로젝트 간에 공유될 수 없습니다.

백업 만들기

첫 번째로 만든 백업은 파일 공유에 있는 모든 파일 데이터와 메타데이터의 전체 사본입니다. 이후의 각 백업은 이전 백업 이후의 데이터에 대한 연속적인 변경사항을 복사합니다.

동일한 인스턴스, 리전, CMEK(사용된 경우)와 연결된 백업 그룹을 백업 체인이라고 부릅니다.

백업 체인은 단일 Cloud Storage 버킷 및 리전에 있으며 소스 인스턴스를 저장하는 데 사용되는 리전 외부에 위치할 수 있습니다.

모든 서비스 등급은 여러 백업 체인을 지원하므로 인스턴스의 백업을 여러 리전에 저장할 수 있습니다.

백업이 생성될 때마다 이전 백업에서 차등 변경사항 및 증분 변경사항을 모두 검사합니다.

  • 차등 변경사항: 파일 수정, 추가, 삭제 등 공유 파일의 변경사항이 포함됩니다.

  • 증분 변경사항: 백업 데이터가 있는 버킷의 스토리지 변경사항이 포함됩니다. 여기에는 체인에서 이전에 참조된 데이터의 중복 삭제가 포함될 수 있습니다.

백업을 동일한 백업 체인에 저장할 때마다 이전 백업에 차등 및 증분 변경사항이 있는지 검사합니다. 이 경우 전체 사본이 필요하지 않습니다.

그러나 인스턴스의 데이터를 여러 백업 체인에 저장하면 다른 위치와 번갈아가며 백업을 저장하고 보관한다는 의미입니다.

다른 위치에 새 백업을 만들 때마다 백업의 전체 사본이 다시 생성됩니다. 백업 체인을 교대하면 백업 create 작업 지연 시간이 길어질 수 있습니다.

이전 백업에 포함된 변경되지 않은 데이터는 새 백업에서 참조만 되고 복사되지 않습니다. 이전 백업을 삭제하면 고유 데이터가 다음 최신 백업에 복사되고 모든 내부 데이터 참조가 자동으로 업데이트됩니다.

백업 만들기는 즉시 수행되지만 백업을 사용할 수 있기 전 복사되는 데이터 양에 비례한 기간이 소요됩니다. 이 기간 동안 백업은 3단계로 진행됩니다.

상태 기간 설명
생성 중 몇 초 현재 파일 공유 상태 캡처. 파일 공유 데이터의 새로운 모든 변경사항은 백업에 포함되거나 포함되지 않을 수 있습니다. 백업이 시작되기 전 인스턴스에서 안정적으로 기록된 것으로 확인된 데이터가 백업에 포함됩니다.
완료 중 크기에 따라 다름 데이터를 백업에 업로드. 파일 공유 데이터의 새로운 모든 변경사항은 백업에 포함되지 않습니다.
레디 백업이 삭제될 때까지 백업을 사용할 수 있습니다.

기본 등급 백업은 생성 후 자동으로 압축되어 비용을 절감합니다. 영역(이전의 대규모 SSD) 및 엔터프라이즈 서비스 등급의 인스턴스에 백업을 만드는 동안 인스턴스 성능이 저하될 수 있습니다. 백업을 만들어도 기본 등급 인스턴스의 가용성 또는 성능에 영향을 미치지 않습니다.

백업 삭제

백업은 소스 인스턴스의 하위 리소스가 아닌 프로젝트 수준 리소스이며 고유한 스토리지가 필요합니다. 따라서 백업 수명 주기는 소스 인스턴스의 수명 주기와 연결되지 않습니다. 소스를 삭제해도 연결된 백업은 삭제되지 않습니다. 백업을 삭제하려면 인스턴스가 아닌 백업에서 삭제 작업을 명시적으로 수행해야 합니다.

필요하지 않은 백업을 모두 삭제해야 합니다. 소스 인스턴스를 삭제해도 나머지 백업에는 요금이 계속 청구됩니다.

백업 삭제는 영구적이며 삭제 취소할 수 없습니다.

백업 일관성

Filestore 백업은 NFSv3 일관성 시맨틱스를 갖습니다. 백업이 시작되기 전 Filestore 인스턴스에서 안정적인 스토리지에 기록된 것으로 확인되었거나 후속 COMMIT 확인이 이뤄진 모든 쓰기 데이터가 백업에 포함됩니다. 자세한 내용은 NFSv3 RFC-1813 섹션 3.3.7을 참조하세요.

일반 사용 사례

다음 섹션에서는 백업의 일반적인 사용 사례를 설명합니다.

재해 복구를 위한 데이터 백업

us-west1-c에 Filestore 인스턴스가 있고 이 리전에 영향을 미치는 재해로부터 데이터를 보호한다고 가정해 보겠습니다. us- east1과 같은 원격 리전에 이 인스턴스의 백업을 정기적으로 만드는 작업을 예약할 수 있습니다. us-west1-c를 포함한 재해가 발생하면 또 다른 위치에 이전 백업으로부터 새 인스턴스를 만들 수 있습니다.

실수로 인한 변경으로부터 보호하기 위한 데이터 백업

의도치 않게 변경되지 않도록 Filestore 데이터를 보호하기 위해서는 인스턴스 백업을 정기적으로 만드는 작업을 예약할 수 있습니다. 데이터가 손실되면 백업 목록을 확인하여 필요한 파일 버전이 포함된 백업을 찾을 수 있습니다. 그런 후 백업으로부터 새 Filestore 인스턴스를 만들고, 원래 인스턴스와 동일한 클라이언트에 마운트하고, 파일을 복사합니다.

파일을 복사하기 전에 두 마운트 지점에서 Linux diff 명령어를 사용하여 원래 인스턴스의 데이터와 백업에서 복원된 데이터 간의 차이점을 확인할 수 있습니다. 데이터가 복구되면 복원된 인스턴스를 삭제하고 이후에 사용할 수 있도록 데이터의 현재 상태를 보존하는 새 백업을 만들 수 있습니다.

또는 백업 데이터가 원래 Filestore 인스턴스에 직접 복원되고, 원래 인스턴스의 모든 데이터를 백업 데이터로 교체하는 인플레이스(In-Place) 복원을 수행할 수 있습니다. 백업되지 않은 데이터가 손실되므로 인플레이스(In-Place) 복원을 수행하기 전에 최신 데이터 백업을 만드는 것이 좋습니다.

개발 및 테스트용 클론 만들기

프로덕션 트래픽을 제공하는 Filestore 인스턴스에 데이터베이스가 설정되어 있다고 가정해보세요. 데이터베이스 입력 테스트를 실행하려는 경우 해당 테스트를 위해 프로덕션 인스턴스의 백업으로부터 새로운 Filestore 인스턴스를 만들 수 있습니다. 이렇게 하면 테스트 사용이 프로덕션에 영향을 주지 않습니다.

마찬가지로 오프라인 분석 및 조사를 위해 백업을 사용하고, 프로덕션에는 영향을 주지 않을 수 있습니다.

데이터 마이그레이션

Filestore 인스턴스를 만든 후에는 해당 위치 또는 서비스 등급을 변경할 수 없습니다. 데이터를 다른 리전으로 마이그레이션하려면 백업을 만들고 백업을 사용하여 새 Filestore 인스턴스를 만들거나 기존 인스턴스에 복원할 수 있습니다.

또한 백업에서 새 Filestore 인스턴스를 만들 때 소스 인스턴스 등급에 관계없이 기본 HDD 등급이나 기본 SSD 등급을 선택할 수 있습니다.

기능 제한사항

Filestore 백업은 이제 기본 SSD, 기본 HDD, 엔터프라이즈 인스턴스에 정식 버전(GA)으로 제공되며 영역 인스턴스의 경우 미리보기 기능입니다.

다음과 같은 제한사항이 적용됩니다.

  • 영역 등급 인스턴스에 이 기능을 사용 설정하려면 새 프로젝트를 만드는 것이 좋습니다. 프로덕션 워크로드는 항상 미리보기 워크로드와 별도의 프로젝트에 있어야 합니다.

  • Filestore 백업은 Filestore Multishares 기능과 함께 사용할 수 없습니다.

  • 가격 책정이 시행되면 관련 수수료가 적용됩니다.

  • 사용자는 미리보기에서 생성된 백업을 대체할 새 백업을 만들어야 합니다. 미리보기에서 생성된 백업은 삭제될 수 있습니다. 미리보기에서 생성된 백업은 생성 시 사용 가능한 기능 동작을 반영합니다. 새 기능이 출시되더라도 기존 백업은 업데이트되지 않습니다.

다음 섹션에서는 성능, 스토리지, 용량, 암호화와 관련된 다른 기능 제한사항을 자세히 설명합니다.

성능

  • 동일한 파일의 수많은 하드 링크를 통해 다수의(예: 수만 또는 수십만 개) 변경사항을 적용하면 성능에 영향을 미칠 수 있습니다.

  • 사용률이 높은 인스턴스의 경우 백업이 업로드되는 동안 성능이 최대 15%까지 저하될 수 있습니다. 기본 등급 인스턴스 성능은 백업 create 작업의 영향을 받지 않습니다.

  • 인스턴스의 데이터를 여러 백업 체인에 저장하면 백업 성능에 영향을 미칩니다. 백업 체인을 교대하면 백업 create 작업 지연 시간이 길어질 수 있습니다.

  • restore 인스턴스 또는 delete 인스턴스와 같은 인스턴스 작업은 백업 create 작업이 완료될 때까지 지연될 수 있습니다.

  • 경우에 따라 delete 작업을 완료하려면 최대 24시간까지 걸릴 수 있습니다.

작업 동시 실행

  • 동일한 소스 인스턴스와 연결된 백업 delete 작업은 한 번에 하나씩 수행해야 합니다.

    백업 체인 내에서 대량 백업 delete 작업은 지원되지 않습니다. delete 작업이 보류 중일 때 동일한 백업 체인 내에서 새 delete 작업을 수행하면 RESOURCE_EXHAUSTED 오류가 반환됩니다. 이는 소스 인스턴스가 삭제되었는지 여부와 관계가 없습니다.

    • 소스 인스턴스가 삭제된 경우 사용자에게 유사한 FAILED_PRECONDITION 오류가 표시됩니다.

    • 이 제한사항은 기본 SSD 및 기본 HDD를 제외한 모든 서비스 계층에 적용됩니다.

    • 백업이 별도의 소스 인스턴스를 참조할 때 Filestore는 동시 백업 delete 작업을 지원합니다.

      예를 들어 Source1이라는 라벨의 인스턴스에 Backup1 및 Backup2에서 참조되는 백업 데이터가 포함됩니다. Source2에는 Backup3 및 Backup4에서 참조되는 백업 데이터가 포함됩니다. Backup1 및 Backup2를 동시에 삭제할 수 없지만 Backup2 및 Backup3은 삭제할 수 있습니다.

  • 동일한 백업 체인 내에서 시작된 백업 create 및 백업 delete 작업을 동시에 실행할 수 있습니다. 그러나 사용자는 최신 백업을 삭제하는 동안 백업 create 작업을 완료할 수 없습니다.

    • 최신 백업을 삭제하는 동안 인스턴스의 새 백업을 만들려고 시도하면 FAILED_PRECONDITION 오류가 표시됩니다. 예를 들어 Source1에 Backup1 및 Backup2로 구성된 백업 체인이 있고 사용자가 Backup3에 대한 create 작업을 시작하면 create 작업이 완료될 때까지 Backup2를 삭제할 수 없습니다. 가장 최근의 백업에는 백업 create 작업을 성공적으로 완료하는 데 필요한 가장 중요한 데이터가 포함되어 있기 때문입니다.

스토리지

  • 엔터프라이즈 및 영역 등급 인스턴스에는 소스 인스턴스 또는 기존 인스턴스로의 백업 restore 작업이 지원되지 않습니다. 이러한 서비스 등급 중 하나에서 인스턴스 백업을 복원하려면 새 인스턴스를 만들어야 합니다.

  • restore, edit, delete와 같은 백업 작업은 미리보기에서 생성된 일부 백업에 제공되지 않을 수 있습니다.

  • RestoreInstance 작업이 엔터프라이즈 인스턴스에 적용되면 작업 전에 이전 스냅샷과 동일한 이름으로 스냅샷을 만들 수 없습니다.

  • 백업 삭제 또는 스냅샷 삭제가 진행되는 동안 백업에서 인스턴스를 복원하려고 하면 실패합니다.

  • 백업 삭제가 실패하면 상태가 invalid로 표시됩니다. 이러한 경우 delete 작업을 다시 시도해야 합니다.

용량

각 백업은 인스턴스 용량을 차지합니다. 이 용량은 마지막 백업이 생성된 후 데이터의 변경 범위에 따라 달라집니다.

구체적으로는 백업이 생성되면 사용 가능한 인스턴스 용량의 일부를 차지하는 파일 시스템의 내부 스냅샷을 Filestore가 만듭니다.

스냅샷 크기는 또한 마지막 백업이 생성된 이후의 공유 내 데이터 변경사항의 범위를 기준으로 합니다. 이 스냅샷은 다음 백업이 생성되고 업로드될 때까지 계속 존재합니다.

백업에서 참조하는 모든 데이터는 캡처 시의 상태로 유지되며 파일 시스템에서 용량을 계속 차지합니다. 예를 들어 마운트된 파일 시스템에서 데이터를 삭제하면 이 자체로 용량이 확보되지 않습니다. 대신 용량을 확보하려면 상당한 양의 데이터를 삭제하거나 덮어쓴 후 새 백업을 만듭니다.

워크로드에 충분한 용량을 예측하려면 다음 중 하나를 적용하는 것이 좋습니다.

  • 현저하게 자주 변경되거나 높은 변경 비율을 가진 워크로드의 인스턴스 용량을 늘립니다.

암호화

CMEK를 사용하여 백업 체인을 암호화하는 경우 다음 제한사항이 적용됩니다.

  • 전체 백업 체인은 동일한 CMEK를 사용하여 암호화됩니다.

  • CMEK는 암호화하는 리소스와 동일한 리전에 있어야 합니다.

  • 소스 인스턴스와 별개의 리전에 백업 체인을 저장하는 경우 소스 및 백업 체인에 대해 별도의 키를 적용해야 할 수 있습니다.

    • 모든 서비스 등급은 여러 백업 체인을 지원하고 인스턴스의 백업을 여러 리전에 저장하는 기능을 지원합니다. CMEK를 암호화에 사용하도록 선택할 경우 CMEK 키는 암호화하는 리소스와 동일한 리전에 있어야 합니다. 소스와 별도의 리전에 백업을 저장하고 CMEK가 멀티 리전 키가 아닌 경우 별도의 CMEK 키를 사용해야 합니다. 자세한 내용은 CMEK 제한사항 및 최적의 CMEK 위치 선택을 참조하세요.

  • 단일 CMEK는 백업 체인이 저장되는 Cloud Storage 버킷에 적용되며 결합하거나 대체할 수 없습니다.

  • 기본 등급 백업에는 CMEK 지원이 제공되지 않습니다.

자세한 내용은 백업 체인에 대한 CMEK 지원을 참조하세요.

권장사항

다음 섹션에서는 권장사항을 설명합니다.

최상의 백업 일관성을 위한 파일 공유 준비

백업 품질은 애플리케이션이 대량의 쓰기 작업이 수행되는 워크로드 기간 중에 생성되는 백업으로부터 복구할 수 있는 기능에 따라 달라집니다. 대부분의 경우 애플리케이션이 파일 공유에 데이터 쓰기를 수행하는 동안에도 일관성이 뛰어난 백업을 만들 수 있습니다. 하지만 애플리케이션에 엄격한 일관성이 요구될 때는 다음 중 하나를 수행하는 것이 좋습니다.

  • sync 마운트를 사용합니다. 자세한 내용은 nfs(5)의 'sync mount 옵션' 섹션을 참조하세요. 또는 O_DIRECT|O_SYNC 플래그를 사용하여 파일을 열 수 있습니다. 자세한 내용은 open(2)을 참조하세요.
  • 파일 공유에 데이터를 쓰는 애플리케이션 또는 운영체제 프로세스를 일시중지하고 백업을 시작하기 전 파일 공유에 변경사항을 반영하도록 만듭니다. 자세한 내용은 fsync(2)를 참조하세요.
  • 애플리케이션에 여러 공유 간 일관성이 필요하면 모든 파일 공유에 쓰기를 수행 중인 모든 인스턴스에서 모든 애플리케이션을 일시중지하고 애플리케이션을 재개하기 전 모든 파일 공유에 대한 백업을 만듭니다.
  • 애플리케이션 수준 일관성이 필요하면 애플리케이션을 중지하고 백업을 만들기 전에 파일 공유를 마운트 해제합니다.

백업 만들기 시간을 줄이기 위해 기존 백업을 새 백업의 기준으로 사용

한 리전 내에서 파일 공유의 기존 백업은 파일 공유의 새 백업을 만들기 위한 기준으로 사용되며, 백업 생성 시간을 줄여줍니다. 따라서 다음을 수행하는 것이 좋습니다.

  • 파일 공유의 이전 백업을 삭제하기 전에 파일 공유의 새 백업을 수행합니다.

  • 동일한 파일 공유에 대해 후속 백업을 만들기 전에 새 백업이 Ready 상태가 될 때까지 기다립니다.

백업 만들기 시간을 줄이기 위해 사용량이 적은 시간에 백업 예약

사용량이 적은 시간에 백업을 만들면 백업을 만드는 데 걸리는 시간이 줄어듭니다. 파일 공유에 대해 정기적인 백업을 예약할 경우 가능하면 사용량이 적은 시간에 예약하는 것이 좋습니다.

백업을 만들 때 가장 좋은 시간은 하루 업무가 마감되었을 때와 Filestore 인스턴스가 배치된 리전의 자정입니다. 아침 일찍 또는 업무일 중에 백업을 만드는 것이 좋습니다.

효율성 극대화를 위한 개별 Filestore 인스턴스에 데이터 정리

파일 공유에 데이터가 많을수록 백업이 더 커지고 비용도 늘어납니다. 백업이 필요한 데이터만 백업하기 위해서는 데이터를 개별 파일 공유에 정리해두는 것이 좋습니다. 즉, 다음과 같습니다.

  • 서로 다른 쓰기 패턴 또는 서로 다른 백업 요구사항에 따라 중요한 데이터를 서로 다른 파일 공유에 저장합니다.
  • 유사한 데이터를 하나의 파일 공유에 보관하여 만들어야 할 백업 수를 줄입니다.

할당량

기본 SSD 및 기본 HDD 서비스 등급의 리전별 백업 수와 관련이 있습니다.

백업 할당량 한도는 영역 및 엔터프라이즈 서비스 등급에 적용되지 않습니다.

자세한 내용은 서비스 등급 및 할당량을 참조하세요.

Filestore 백업 시작하기

이 기능을 사용하려면 재해 복구를 위한 데이터 백업을 참조하세요.

다음 단계