재해 복구와 불변 스토리지를 위한 백업(Backups)

재해 복구와 불변 스토리지를 위한 백업(Backups)

Standard & Business Critical 기능

• 백업은 모든 Snowflake 에디션에서 사용할 수 있어요.
• 보존 잠금(retention lock)이 있는 백업과 법적 보류(legal hold)가 있는 백업은 Business Critical Edition(이상)에서 사용할 수 있어요. 업그레이드 문의는 Snowflake Support에 연락해 주세요.

백업은 조직이 수정이나 삭제로부터 중요한 데이터를 보호하는 데 도움을 줘요.

백업은 Snowflake 객체의 개별 스냅샷을 나타내요. 어떤 객체를 백업할지, 얼마나 자주 백업할지, 백업을 얼마나 오래 보관할지, 조기 삭제가 불가능하도록 보존 잠금을 추가할지 여부를 선택해요.

출처: Snowflake 문서

본문

Snowflake 백업의 사용 사례

다음 사용 사례는 백업의 일반적인 적용이에요.

규정 준수(Regulatory compliance): 보존 잠금이 있는 백업은 조직, 금융 기관, 관련 산업이 불변 형식으로 레코드를 보존해야 하는 규정을 해결하는 데 도움이 돼요.

참고(Note): Snowflake는 Cohasset Associates에 SEC 17a-4(f), SEC 18a-6(e), FINRA Rule 4511(c), CFTC Rule 1.31(c)-(d)를 포함한 주요 규정 레코드보관 요구사항에 대한 백업 기능의 독립적 평가를 의뢰했어요. 이 Cohasset 평가는 Snowflake의 불변 스토리지 통제가 데이터의 생성, 보호, 보존을 지원하며, 평가된 규정에 적용되는 규제 데이터 보존에 대해 Snowflake가 중요한 업계 표준을 충족한다는 독립적인 서드파티 검증을 제공해요.

보존 잠금이 있는 Snowflake 백업에 적용되는 전체 규정 준수 보고서는 Snowflake Compliance Center를 참고해요.

복구(Recovery): 백업은 조직이 우발적 수정이나 삭제의 경우 비즈니스 중요한 데이터를 보호하고 복구하기 위한 개별 스냅샷을 만드는 데 도움을 줘요.

사이버 탄력성(Cyber resilience): 보존 잠금이 있는 백업은 전반적인 사이버 탄력성 전략의 일부예요. 조직이 사이버 공격, 특히 랜섬웨어 공격 중 비즈니스 중요한 데이터를 보호하는 데 도움이 돼요. 보존 잠금은 공격자가 ACCOUNTADMIN 또는 ORGADMIN 역할을 사용해 계정에 접근하더라도 이 데이터를 삭제할 수 없도록 보장해요.

핵심 개념

이 섹션은 Snowflake 백업의 핵심 개념에 대한 개요를 제공해요.

백업(Backup)

*백업(backup)*은 객체의 특정 시점 스냅샷을 나타내요.

• 객체는 단일 테이블, 스키마 또는 전체 데이터베이스일 수 있어요.
• 특정 백업은 Snowflake가 생성한 고유 ID로 식별할 수 있어요.
• 백업은 수정할 수 없어요. 하지만 삭제할 수 있으며, 백업 만료 기간은 수정할 수 있어요(보존 잠금이 적용되지 않는 경우).

일상 운영 중에는 개별 백업과 거의 상호작용하지 않아요. 대신 이를 포함하는 *백업 세트(backup sets)*를 관리해요. 예를 들어 SHOW BACKUPS IN BACKUP SET 명령을 실행해 백업 목록을 얻어요. ALTER BACKUP SET 명령을 실행해 새 백업을 만들어요.

백업 세트(Backup Set)

*백업 세트(backup set)*는 특정 데이터베이스, 스키마 또는 테이블에 대한 백업 집합을 포함하는 스키마 수준 객체예요. Snowflake에는 백업 세트를 CREATE, ALTER, DROP, SHOW, DESCRIBE하는 SQL 명령이 있어요.

같은 객체에 대해 여러 백업 세트를 가질 수 있어요.

세트 내 백업의 수명 주기는 백업 세트에 연결할 수 있는 선택적 *백업 정책(backup policy)*에 의해 결정돼요. 백업 세트에 백업을 수동으로 추가하거나 삭제할 수도 있어요. 백업을 삭제하는 능력은 특히 보존 잠금과 법적 보류 같은 다른 요소의 영향을 받아요.

백업 정책(Backup Policy)

*백업 정책(backup policy)*은 백업 세트 내 백업의 수명 주기를 정의하는 설정을 포함하는 스키마 수준 객체예요. 이러한 설정에는 일정(schedule), 만료(expiration), 보존 잠금(retention lock)이 포함돼요.

• *일정(schedule)*은 백업이 생성되는 시점을 결정해요. 일정은 분 단위의 간격 또는 cron 식으로 정의할 수 있어요. 예를 들어 일정이 1시간으로 설정되면 60분마다 객체의 백업이 생성돼요.
• *만료 기간(expiration period)*은 백업이 유효한 기간이에요. 백업이 만료되면 Snowflake가 자동으로 삭제해요. 다만 특정 백업에 법적 보류가 적용된 경우는 제외해요.

팁(Tip): 백업 세트에 보존 잠금이 없고 특정 백업에 법적 보류가 적용되지 않았다면 만료 기간이 끝나기 전에 백업을 수동으로 삭제할 수 있어요. 수동 백업 삭제는 법적 보류가 없는 가장 오래된 백업부터 시작해 한 번에 하나씩 할 수 있어요.

각 백업 정책은 일정과 만료 기간 속성 중 하나 또는 둘 다를 가져야 해요. 예를 들어 일정과 만료 기간이 있는 정책을 만들어 Snowflake가 정책이 적용된 모든 백업 세트의 백업 생성·제거를 모두 처리하게 할 수 있어요. 또는 이전 백업 제거를 직접 관리하려면 일정은 있고 만료 기간은 없는 정책을 만들 수 있어요. 또는 만료 기간은 있지만 일정이 없는 정책을 만들고 백업 생성을 직접 관리할 수 있어요. 일정도 만료 기간도 없는 정책은 만들 수 없어요.

백업 정책을 백업 세트와 연결할 때는 백업 세트를 만들 때 할 수 있고, 나중에 정책을 적용할 수도 있어요. 또는 연결된 백업 정책이 없는 백업 세트를 가질 수도 있어요. 그 경우 새 백업을 언제 만들고 이전 백업을 만료시킬지 수동으로 제어해요.

백업 정책을 여러 백업 세트에 적용할 수 있어요. 백업 정책을 수정하면 Snowflake가 정책이 연결된 모든 백업 세트에 변경 사항을 적용해요.

보존 잠금(Retention Lock)

*보존 잠금(retention lock)*은 정의된 만료 기간 동안 백업이 삭제되지 않도록 보호해요. 규정 준수와 사이버 탄력성을 위해 보존 잠금이 있는 백업을 사용할 수 있어요. 보존 잠금이 있는 백업 세트에는 다음 제한이 적용돼요.

• 백업은 ACCOUNTADMIN 역할을 포함한 어떤 역할도 삭제할 수 없어요.
• 백업 만료 기간은 늘릴 수 있지만 줄일 수는 없어요.
• 세트에 만료되지 않은 백업이 있으면 백업 세트를 삭제할 수 없어요.
• 만료되지 않은 백업이 있는 백업 세트를 포함하는 스키마는 삭제할 수 없어요.
• 만료되지 않은 백업이 있는 백업 세트를 포함하는 데이터베이스는 삭제할 수 없어요.
• 만료되지 않은 백업이 있는 백업 세트를 포함하는 데이터베이스를 포함하는 계정은 삭제할 수 없어요.

중요(Important): 보존 잠금이 있는 백업 정책을 백업 세트에 적용하는 것은 되돌릴 수 없어요. 규정 준수에 필요한 강력한 보장 때문에 백업 세트에 보존 잠금을 걸면 잠금을 해제할 수 없어요. Snowflake 지원도 그러한 보존 잠금을 해제할 수 없어요. 긴 만료 기간의 백업 세트에 보존 잠금을 설정하기 전에 신중히 계획해, 삭제할 수 없는 백업 세트와 이를 포함하는 스키마·데이터베이스에 대한 예상치 못한 스토리지 요금을 피해야 해요.

Snowflake 조직이 삭제되면 그 조직은 더 이상 Snowflake 고객이 아니에요. 이 경우 Snowflake는 보존 잠금이 있는 백업을 포함한 모든 백업을 삭제해요. Snowflake 조직을 삭제하려면 Snowflake 지원의 개입이 필요해요. 관리자가 우연히 할 수 있는 일이 아니에요.

법적 보류(Legal Hold)

Snowflake 백업의 법적 보류(legal hold) 기능은 백업이 덮어쓰여지거나 삭제되지 않도록 방지해요. 이렇게 하면 자체 법적 요구사항에 기반해 Snowflake 데이터베이스, 스키마 또는 테이블을 보존할 수 있어요.

Snowflake는 특정 백업에 법적 보류를 걸 수 있게 해요. Snowflake 백업이 법적 보류 상태이면 다음 조건이 적용돼요.

• 아무도 백업을 수정할 수 없어요.
• 아무도 백업을 삭제할 수 없어요. 백업이 EXPIRE_AFTER_DAYS 기간을 지났어도 마찬가지예요.
• 백업에 대한 접근이 로그되고 감사 가능해요.
• 법적 보류는 보존 잠금과 달리 권한 있는 사용자가 제거할 수 있어요.

중요(Important): 백업 세트를 복제한다면 해당 백업 세트의 백업에 법적 보류를 건 직후에 새로고침(refresh)을 수행해야 해요. 법적 보류를 포함하는 백업 세트를 복제하기 전에 장애 조치를 수행하면, 원래 기본 계정으로 장애 복구(failback)할 때 원래 백업 세트가 덮어써져 법적 보류가 지워질 수 있어요.

백업 수명 주기 개요

다음 다이어그램은 Snowflake 객체, 백업, 백업 세트, 백업 정책이 서로 어떻게 관련되는지 보여줘요. 다이어그램은 가장 단순한 종류의 백업, 즉 단일 테이블에 대한 백업을 포함해요. 각 백업 작업은 새 백업을 생성해요. 특정 객체에 대한 모든 백업은 백업 세트로 그룹화돼요. 백업 세트에서 백업의 자동 추가·제거는 백업 정책이 관리해요. 백업에서 정보를 복구하려면 CREATE 명령을 사용해 특정 백업에서 새 객체를 만들어요.

백업 작동 방식

백업은 클론(clones)과 유사한 Snowflake 객체의 제로 카피(zero-copy) 중복이에요. 백업은 생성될 때 테이블 데이터의 사본을 만들지 않아요. 백업 메커니즘은 데이터를 복사하는 추가 비용이나 시간 없이 테이블 데이터를 백업해요.

Snowflake는 데이터를 불변(immutable)인 파일에 저장하며, 백업에서 테이블의 기본이 되는 데이터 파일로의 포인터를 유지해요. 테이블이 발전·수정됨에 따라 Snowflake는 만료되지 않은 백업이 파일을 참조하는 한 각 데이터 파일이 삭제되지 않도록 보장해요.

백업 제한사항

Snowflake는 백업에 대해 다음 제한을 적용해요.

• 백업 정책의 보존 잠금을 수정할 수 없어요.
• 정책에 보존 잠금이 있으면 만료 기간은 늘릴 수 있지만 줄일 수 없어요.
• 예약 백업의 최소 일정 간격은 1시간(60분)이에요.

백업과 다른 재해 복구·비즈니스 연속성 기능 비교

백업은 복제와 Time Travel 같은 다른 Snowflake 비즈니스 연속성·재해 복구 기능과 다른 다음 이점을 제공해요.

• 백업에 장기 보존(long-term retention)을 활성화할 수 있어요. 장기 보존은 랜섬웨어나 내부 공격 같은 위협에 대한 복구, 규정 준수, 사이버 탄력성에 도움이 돼요.
• 보존 잠금은 계정 관리자를 포함한 어떤 사용자도 백업을 삭제할 수 없도록 보장해요.
• 복제 새로고침 같은 다른 데이터 전송 작업에 사용하는 시간대와 다른 시간대로 백업을 예약할 수 있어요.
• 개별 테이블 객체, 또는 전체 스키마나 데이터베이스 같은 컨테이너 객체를 백업하고 복원할 수 있어요.
• 백업을 만든 후 백업의 보존 시간이 줄어들지 않도록 보존 잠금을 포함하는 백업 정책을 사용해 방지할 수 있어요. 이는 보존 간격을 0으로 줄일 수 있는 Time Travel 기능과 다르다.
• Time Travel 및 Fail-safe와 달리 백업은 테이블과 테이블 데이터 이상의 더 많은 객체 유형의 데이터를 보존해요.
• 백업을 만드는 속도와 스토리지 효율은 클로닝에 사용되는 제로 카피 메커니즘과 유사해요.
• 같은 객체의 모든 백업을 백업 세트로 그룹화하는 방식은 클론을 사용해 자체 백업 메커니즘을 구현하는 것보다 관리를 단순화해요. 예를 들어 많은 수의 객체를 관리하고, 복제된 객체를 추적하기 위한 명명 체계를 고안하고, 이전 클론을 삭제하는 일정 메커니즘을 구현할 필요가 없어요. 또한 복제된 객체와 달리 백업은 만든 후 수정할 수 없어요.
• 각 백업은 지정된 시점의 단일 테이블, 스키마 또는 데이터베이스를 나타내요. 백업은 사용자나 역할 같은 계정 수준 객체를 포함하지 않아요. 일부 유형의 테이블과 기타 데이터베이스 수준 객체는 스키마·데이터베이스 백업에 포함되지 않아요. 자세한 내용은 백업 객체를 참고해요.
• 백업 관련 객체는 관련 데이터베이스, 스키마 또는 테이블과 같은 클라우드 서비스 제공자(CSP) 리전에 저장돼요. 비즈니스 연속성·재해 복구 시나리오에서는 일반적으로 백업을 Snowflake 계정 복제와 함께 결합해요. 이렇게 하면 모든 백업 세트와 백업 정책을 다른 리전이나 다른 CSP로 복제하고 원래 리전이나 CSP에 영향을 주는 중단이 있어도 복구할 수 있어요.
• 백업 세트와 백업 정책은 복제할 수 없어요. 그러한 객체를 포함하는 스키마나 데이터베이스를 복제하면 복제된 스키마나 데이터베이스에 포함되지 않아요.

백업 객체

테이블, 스키마, 데이터베이스에 대해 백업 세트를 만들 수 있어요.

테이블에서 다른 객체로의 참조

뷰나 함수 같은 객체는 백업의 스키마나 데이터베이스 외부의 객체를 참조할 수 있어요. 백업에서 복원한 후에도 그러한 참조가 계속 작동하도록 보장하려면 다음 전략 중 하나를 사용해요.

• 테이블과 그 테이블이 참조하는 다른 객체가 모두 같은 스키마나 같은 데이터베이스에 있다면 전체 스키마나 전체 데이터베이스에 대한 백업 세트를 만들어요. 이렇게 하면 백업에서 복원할 때 Snowflake가 모든 상호 연결된 객체를 한 번에 복원해요.
• 백업 세트의 객체가 백업 세트에 포함되지 않은 객체를 참조한다면, 백업이 복원될 때 복원된 객체의 참조가 다른 데이터베이스나 스키마의 원래 객체를 가리킨다는 점을 알아야 해요. 백업을 만든 후 그 다른 객체를 삭제했거나 속성을 변경했다면 복원된 객체에 접근할 때 오류가 발생할 수 있어요.
• 계정 수준 객체의 경우 복원된 객체의 모든 참조는 항상 원래 계정 수준 객체를 가리켜요. 계정 수준 객체는 어떤 백업의 일부도 아니기 때문이에요. 예를 들어 스키마 백업이 보안 통합을 참조하는 시크릿을 포함할 수 있어요. 보안 통합은 계정 수준 객체이며 어떤 백업에도 포함될 수 없어요.

데이터베이스·스키마 백업의 객체 유형

다음 표는 데이터베이스 또는 스키마 백업에 포함되는 객체를 나열해요.

객체	백업 포함	비고
영구 테이블(Permanent tables)	예	테이블의 Time Travel 정보는 백업의 일부로 저장되지 않아요.
트랜지언트 테이블(Transient tables)	예	복원 후에도 그러한 테이블은 트랜지언트 테이블로 유지돼요. 트랜지언트 스키마와 트랜지언트 데이터베이스도 복원 후 트랜지언트 속성을 유지해요.
임시 테이블(Temporary tables)	아니요	임시 테이블은 세션 범위이며 백업에 포함되지 않아요.
동적 테이블(Dynamic tables)	예	백업에서 동적 테이블을 복원하면 테이블이 일시 중단 상태로 복원돼요. Snowflake가 첫 새로고침 중에 새 테이블을 자동으로 초기화해요.
외부 테이블(External tables)	아니요
하이브리드 테이블(Hybrid tables)	아니요
Apache Iceberg™ 테이블	아니요	동적 Iceberg 테이블도 백업에 포함되지 않아요.
테이블 제약(Table constraints)	예
이벤트 테이블(Event tables)	아니요
시퀀스(Sequences)	예
뷰(Views)	예
구체화된 뷰(Materialized views)	아니요
보안 뷰(Secure views)	예
파일 형식(File formats)	예
내부 스테이지(Internal stages)	아니요
외부 스테이지(External stages)	아니요
임시 스테이지(Temporary stages)	아니요
디렉터리 테이블(Directory tables)	아니요
파이프(Pipes)	아니요
저장 프로시저(Stored procedures)	예	SQL, Javascript, Python, Java, Scala 프로시저가 모두 지원돼요.
사용자 정의 함수(UDFs)	예	SQL, Javascript, Python, Java, Scala 함수가 모두 지원돼요. 스칼라 UDF와 UDTF(사용자 정의 테이블 함수)가 모두 백업에 포함돼요. 백업의 Java UDF는 클로닝 제한사항과 같은 요구사항을 가져요.
스트림(Streams)	아니요
태스크(Tasks)	예	태스크가 백업에 포함돼요. 백업에서 복원된 태스크는 일시 중단되며 재개해야 해요.
데이터 메트릭 함수(DMFs)	아니요
정책(Policies)	예	스키마 또는 데이터베이스 백업에 다음 종류의 정책이 포함돼요: 열 수준 보안(마스킹), 행 접근 정책, 태그 기반 마스킹 정책. 백업에 포함된 테이블에 다른 종류의 정책이 적용되어 있으면(예: 집계 정책, 프로젝션 정책, 스토리지 수명 주기 정책) 백업 생성이 실패해요.
그랜트(Grants)	예	역할을 삭제하면 관련 소유권 그랜트는 DROP ROLE 명령을 수행하는 역할로 이전돼요. 이 경우 소유권이 아닌 그랜트는 삭제돼요. 따라서 복원된 객체의 그랜트는 백업이 생성될 때 존재했던 그랜트와 다를 수 있어요.
데이터베이스 역할(Database roles)	예
객체 태깅(Object tagging)	예
알림(Alerts)	예
네트워크 규칙(Network rules)	예
Github 저장소	아니요
모델(Models)	아니요
모델 모니터(Model monitors)	아니요
데이터셋(Datasets)	아니요
노트북(Notebooks)	아니요
연락처(Contacts)	아니요
Cortex 검색 서비스(Cortex search services)	아니요
Dbt 프로젝트	아니요
이미지 저장소(Image repositories)	아니요
리스팅(Listings)	아니요
조직 리스팅(Organization listings)	아니요
파이프(Pipes)	아니요
정책(집계)	아니요
정책(인증)	아니요
정책(기능)	아니요
정책(조인)	아니요
정책(패키지)	아니요
정책(비밀번호)	아니요
정책(개인정보)	아니요
정책(프로젝션)	아니요
정책(세션)	아니요
프로비저닝된 처리량(Provisioned throughput)	아니요
시맨틱 뷰(Semantic views)	아니요
서비스(Services)	아니요
스트림릿(Streamlits)	아니요

Snowflake가 객체를 백업 세트와 연결하는 방법

데이터베이스, 스키마 또는 테이블에 대한 백업 세트를 만들면 Snowflake가 백업 세트를 해당 데이터베이스, 스키마 또는 테이블의 내부 ID와 연결해요. 원래 객체를 삭제하면 그 백업 세트에 더 이상 백업을 추가할 수 없어요. 이 동작은 같은 이름으로 객체를 다시 만들거나 백업에서 복원된 객체로 교체하더라도 적용돼요.

대신 원래 객체의 이름을 바꾸면 같은 백업 세트에 백업을 추가해 계속 백업을 만들 수 있어요. 그 경우 SHOW BACKUP SETS의 출력이 이름이 바뀐 객체의 OBJECT_NAME 값을 반영하도록 변경돼요.

테이블의 백업을 만들고 싶지만 CREATE OR REPLACE 문을 통해 그 테이블을 자주 삭제·재생성한다면, 테이블을 포함하는 스키마나 데이터베이스에 대한 백업 세트에 포함해요. 이렇게 하면 테이블의 변경과 무관하게 같은 백업 세트를 계속 사용할 수 있어요.

백업에서 테이블을 복원하면 복원된 테이블은 원래 테이블과 다른 이름으로 시작해요. 원래 테이블의 내용을 백업 데이터로 완전히 교체하고, 같은 테이블의 더 많은 백업에 같은 백업 세트를 계속 사용하고 싶다고 가정해 봐요. 그 경우 TRUNCATE 또는 DELETE 문으로 원래 테이블의 내용을 제거하고, INSERT … SELECT 문으로 복원된 테이블의 데이터를 복사해요. 원래 테이블을 삭제하고 복원된 테이블을 원래 테이블의 이름으로 바꾸지 마요.

백업과 암호화

백업 세트 내 데이터는 다른 Snowflake 객체 및 테이블 데이터와 같은 종단 간 암호화로 보호돼요. Snowflake 암호화에 대한 자세한 내용은 Snowflake의 종단 간 암호화 이해를 참고해요.

키 회전도 백업 내 데이터에 적용돼요.

백업과 데이터 계보

Snowflake는 데이터베이스, 스키마, 테이블 백업에 데이터 계보(data lineage) 메타데이터를 보존하지 않아요. 백업에서 객체를 복원한 후 Snowsight를 사용해 복원된 데이터의 계보 정보를 볼 수 없어요.

백업 비용

다음 표는 백업 요금을 설명해요.

크레딧 소비에 대한 정보는 Snowflake Service Consumption Table을 참고해요.

비용 구성 요소	설명	청구
백업 컴퓨팅	Snowflake 관리 컴퓨팅 서비스가 예약된 백업 생성과 만료를 생성해요.	예
복원 컴퓨팅	백업에서 객체를 복원하는 데 Snowflake 관리 웨어하우스가 사용돼요.	예
백업 스토리지	백업 데이터를 저장하기 위한 Snowflake 관리 클라우드 객체 스토리지.	클론에 보존된 바이트와 유사하게 백업에 대해 보존된 바이트에 대해 청구

TABLE_STORAGE_METRICS 뷰에서 RETAINED_FOR_CLONE_BYTES 열을 사용하고, BACKUP_STORAGE_USAGE 뷰에서 백업 스토리지 비용을 모니터링할 수 있어요.

접근 제어 권한

다음 표는 백업 관리·사용을 위해 권한이 부여되는 권한과 객체 유형을 나열해요.

권한	객체 유형	설명
CREATE BACKUP POLICY	Schema	스키마에 백업 정책을 만들 수 있는 능력을 부여해요. 이 권한을 부여하는 역할은 스키마에 USAGE 권한도 있어야 해요.
CREATE BACKUP SET	Schema	스키마에 백업 세트를 만들 수 있는 능력을 부여해요. 이 권한을 부여하는 역할은 스키마에 USAGE 권한도 있어야 해요. 백업 세트를 실제로 만들려면 백업 세트의 대상인 객체에 대한 적절한 권한도 필요해요. 테이블 백업은 SELECT, 스키마 백업이나 데이터베이스 백업은 USAGE.
APPLY	Backup policy	특정 백업 정책을 적용할 수 있는 능력을 부여해요. 이 권한은 ACCOUNTADMIN 역할을 가진 사용자만 부여할 수 있어요.
APPLY BACKUP RETENTION LOCK	Account	보존 잠금이 있는 백업 정책을 만들고 적용할 수 있는 능력을 부여해요. 이 권한은 ACCOUNTADMIN 역할에 부여되며 위임할 수 있어요. 이 권한은 역할이 다음을 할 수 있게 하는 데 필요해요: 보존 잠금이 있는 백업 정책 생성, 백업 세트에 보존 잠금이 있는 백업 정책 적용, 보존 잠금이 있는 정책으로 보호되는 백업 세트에서 사용자가 수동으로 또는 일정에 따라 자동으로 백업 생성.
APPLY LEGAL HOLD	Account	백업에서 법적 보류를 추가하거나 제거할 수 있는 능력을 부여해요. 기본적으로 ACCOUNTADMIN 역할이 이 권한을 가져요.

Snowflake가 백그라운드에서 백업을 자동으로 생성하거나 만료시킬 때 다음 권한 요구사항이 적용돼요. 백업 세트의 소유자는 다음 권한을 가져야 해요.

• 백업 세트의 대상인 객체에 대한 적절한 권한: 테이블 백업은 SELECT, 스키마 백업이나 데이터베이스 백업은 USAGE
• 백업 세트 대상의 상위 스키마 또는 데이터베이스에 대한 어떤 권한
• 백업 세트의 상위 스키마와 데이터베이스에 대한 어떤 권한

이러한 권한 중 하나라도 없으면 자동 백업 생성 또는 만료가 실패해요. 이러한 백그라운드 작업은 ACCOUNT_USAGE.BACKUP_OPERATION_HISTORY 뷰를 사용해 모니터링할 수 있어요.

백업 정책·세트 생성에 필요한 권한 부여

참고(Note):

• 이 권한을 부여하는 데 사용하는 역할은 스키마에 OWNERSHIP 권한이 있거나, CREATE BACKUP SET 또는 CREATE BACKUP POLICY 권한을 WITH GRANT OPTION으로 가져야 해요.
• 다음 권한은 커스텀 계정 역할 또는 데이터베이스 역할에 부여할 수 있어요.

역할 myrole이 myschema 스키마에 백업 정책을 만들 수 있게 하려면 다음 문을 실행해요.

GRANT CREATE BACKUP POLICY ON SCHEMA policy_schema TO ROLE myrole;

역할 myrole이 myschema 스키마에 백업 세트를 만들 수 있게 하려면 다음 문을 실행해요.

GRANT CREATE BACKUP SET ON SCHEMA policy_schema TO ROLE myrole;

역할에 백업 정책에 대한 APPLY 권한 부여

참고(Note):

• 이 권한은 ACCOUNTADMIN 역할을 가진 사용자만 부여할 수 있어요.
• 이 권한은 커스텀 계정 역할 또는 데이터베이스 역할에 부여할 수 있어요.

역할 myrole이 hourly_backup_policy 백업 정책을 백업 세트에 적용할 수 있게 하려면 다음 문을 실행해요.

GRANT APPLY ON BACKUP POLICY hourly_backup_policy TO ROLE myrole;

역할에 APPLY BACKUP RETENTION LOCK 권한 부여

백업 세트에 보존 잠금이 있는 백업 정책을 적용할 권한을 역할에 부여할 수 있어요.

이 권한은 ACCOUNTADMIN 역할을 가진 사용자만 부여할 수 있어요.

중요(Important): 보존 잠금이 있는 백업 정책을 백업 세트에 적용하는 것은 되돌릴 수 없어요. 규정 준수에 필요한 강력한 보장 때문에 백업 세트에 보존 잠금을 걸면 잠금을 해제할 수 없어요. Snowflake 지원도 그러한 보존 잠금을 해제할 수 없어요. 보존 잠금으로 생성된 백업은 만료 기간이 끝날 때까지 삭제할 수 없어요.

Snowflake 조직이 삭제되면 그 조직은 더 이상 Snowflake 고객이 아니에요. 이 경우 Snowflake는 보존 잠금이 있는 백업을 포함한 모든 백업을 삭제해요.

역할 retention_lock_admin_role이 백업 세트에 보존 잠금이 있는 백업 정책을 적용할 수 있게 하려면 다음 문을 실행해요.

GRANT APPLY BACKUP RETENTION LOCK ON ACCOUNT TO ROLE retention_lock_admin_role;

백업 생성·구성

이 섹션은 백업을 만들고 복원하기 위한 예시 워크플로를 제공해요.

• hourly_backup_policy라는 백업 정책을 만들어요. 이 정책으로 생성된 백업은 매시간 생성되며 각 백업은 90일 후 만료돼요.

CREATE BACKUP POLICY hourly_backup_policy
  SCHEDULE = '60 MINUTE'
  EXPIRE_AFTER_DAYS = 90
  COMMENT = 'Hourly backups expire after 90 days';

• 백업 정책 hourly_backup_policy로 테이블 t1에 대한 백업 세트를 만들어요.

CREATE BACKUP SET t1_backups
  FOR TABLE t1
  WITH BACKUP POLICY hourly_backup_policy;

• 백업 정책 hourly_backup_policy로 스키마 s1에 대한 백업 세트를 만들어요.

CREATE BACKUP SET s1_backups
  FOR SCHEMA s1
  WITH BACKUP POLICY hourly_backup_policy;

• 백업 정책 hourly_backup_policy로 데이터베이스 d1에 대한 백업 세트를 만들어요.

CREATE BACKUP SET d1_backups
  FOR DATABASE d1
  WITH BACKUP POLICY hourly_backup_policy;

보존 잠금이 있는 예약 백업 생성

일정에 따라 보존 잠금이 있는 백업을 자동으로 생성하는 백업 세트를 만들어요. 보존 잠금은 정책이 연결된 백업 세트의 백업을 권한 있는 사용자라도 누구도 삭제하거나 수정하지 못하게 해요.

계정에 APPLY BACKUP RETENTION LOCK 권한이 있는 역할만 보존 잠금이 있는 백업 정책을 만들 수 있어요.

중요(Important): 보존 잠금이 있는 백업 정책을 백업 세트에 적용하는 것은 되돌릴 수 없어요. 규정 준수에 필요한 강력한 보장 때문에 백업 세트에 보존 잠금을 걸면 잠금을 해제할 수 없어요. Snowflake 지원도 그러한 보존 잠금을 해제할 수 없어요. 보존 잠금으로 생성된 백업은 만료 기간이 끝날 때까지 삭제할 수 없어요.

Snowflake 조직이 삭제되면 그 조직은 더 이상 Snowflake 고객이 아니에요. 이 경우 Snowflake는 보존 잠금이 있는 백업을 포함한 모든 백업을 삭제해요.

• 만료 기간 90일의 일일 백업을 생성하는 보존 잠금이 있는 정책을 만들어요.

CREATE BACKUP POLICY daily_backup_policy_with_lock
  WITH RETENTION LOCK
  SCHEDULE = '1440 MINUTE'
  EXPIRE_AFTER_DAYS = 90
  COMMENT = 'regulatory backups: they have a retention lock and expire after 90 days';

• 백업 정책 daily_backup_policy_with_lock으로 테이블 t2에 대한 백업 세트를 만들어요.

CREATE BACKUP SET t2_backups
  FOR TABLE t2
  WITH BACKUP POLICY daily_backup_policy_with_lock;

• 백업 정책 daily_backup_policy_with_lock으로 스키마 s2에 대한 백업 세트를 만들어요.

CREATE BACKUP SET s2_backups
  FOR SCHEMA s2
  WITH BACKUP POLICY daily_backup_policy_with_lock;

• 백업 정책 daily_backup_policy_with_lock으로 데이터베이스 d2에 대한 백업 세트를 만들어요.

CREATE BACKUP SET d2_backups
  FOR DATABASE d2
  WITH BACKUP POLICY daily_backup_policy_with_lock;

백업을 수동으로 생성

언제든지 백업 세트에 백업을 수동으로 추가할 수 있어요. 이렇게 하면 백업 세트와 연결된 데이터베이스, 스키마 또는 테이블의 백업이 만들어져요. 백업 세트에 백업 정책이 예약한 백업이 있어도 수동으로 백업을 만들 수 있어요. 백업 정책이 백업 세트와 연결되어 있고 정책이 만료 기간을 정의한다면 그 만료 기간은 수동 백업에도 적용돼요.

다음 예시는 테이블 백업 세트 t1_backups를 만들고 첫 번째 백업을 추가해요.

CREATE BACKUP SET t1_backups FOR TABLE t1;
ALTER BACKUP SET t1_backups ADD BACKUP;

다음 예시는 시간당 백업이 있는 백업 정책, 그 정책을 사용하는 테이블 백업 세트 t2_backups를 만든 다음 백업 세트에 수동 백업을 추가해요.

CREATE BACKUP POLICY hourly_backup_policy
  SCHEDULE = '60 MINUTE'
  EXPIRE_AFTER_DAYS = 7;

CREATE BACKUP SET t2_backups FOR TABLE t2 WITH BACKUP POLICY hourly_backup_policy;
-- Wait several hours. Then the backup set already contains several scheduled backups.
-- You can manually add a backup at any time, in addition to the scheduled backups.
ALTER BACKUP SET t2_backups ADD BACKUP;

스키마나 데이터베이스 백업 세트에 백업을 추가하려면 유사한 명령을 실행할 수 있어요. ALTER BACKUP SET 명령에서 스키마나 데이터베이스 백업 세트의 이름을 대체해요.

백업 세트에서 백업 정책 일시 중단

백업 세트에서 백업 정책을 일시 중단하면 해당 백업 세트에서 백업 정책이 새 예약 백업을 만드는 데 사용되지 않도록 방지해요. 또한 해당 백업 세트에서 백업 정책을 사용하는 기존 백업의 만료도 일시 중단해요. 같은 정책을 사용하는 다른 백업 세트는 영향을 받지 않아요.

다음 예시는 백업 세트 t2_backups에서 백업 정책을 일시 중단해요.

ALTER BACKUP SET t2_backups SUSPEND BACKUP POLICY;

백업 세트의 생성 또는 만료 프로세스를 선택적으로 일시 중단할 수도 있어요. 다음 예시는 백업 세트 t3_backups에서 새 백업 생성을 일시 중단하고, 백업 세트 t4_backups에서 이전 백업 만료를 일시 중단해요.

ALTER BACKUP SET t3_backups SUSPEND BACKUP CREATION POLICY;
ALTER BACKUP SET t4_backups SUSPEND BACKUP EXPIRATION POLICY;

ALTER BACKUP SET 명령에 대한 자세한 내용은 ALTER BACKUP SET을 참고해요.

백업 세트에서 백업 정책 재개

일시 중단된 백업 정책을 재개할 수 있어요. 이렇게 하면 백업 정책에 따라 백업의 생성과 만료가 재개돼요. 정책이 일시 중단된 동안 일부 백업이 만료 시간에 도달했다면 Snowflake는 정책이 재개되는 즉시 그 백업을 삭제해요.

다음 예시는 백업 세트 t1_backup에서 백업 정책을 재개해요.

ALTER BACKUP SET t1_backups
  RESUME BACKUP POLICY;

백업 세트의 생성 또는 만료 프로세스를 선택적으로 재개할 수도 있어요. 다음 예시는 백업 세트 t3_backups에서 새 백업 생성을 재개하고, 백업 세트 t4_backups에서 이전 백업 만료를 재개해요.

ALTER BACKUP SET t3_backups RESUME BACKUP CREATION POLICY;
ALTER BACKUP SET t4_backups RESUME BACKUP EXPIRATION POLICY;

ALTER BACKUP SET 명령에 대한 자세한 내용은 ALTER BACKUP SET을 참고해요.

백업 복원

특정 백업의 ID를 사용해 백업 세트에서 객체를 복원할 수 있어요. 예를 들어 현재 스키마의 백업 세트 t1_backups에서 테이블 t1을 복원하려면 다음 문을 실행해요.

• 복원할 테이블 백업의 ID를 backup_id 열에서 찾아요.

SHOW BACKUPS IN BACKUP SET t1_backups ->> SELECT "created_on", "backup_id", "expire_on" FROM $1;

+-------------------------------+--------------------------------------+-------------------------------+
| created_on                    | backup_id                            | expire_on                     |
|-------------------------------+------------------------------------------+---------------------------|
| 2024-08-19 17:12:28.991 -0700 | 983e0b66-91eb-41cb-8a0b-037abfec1914 | 2024-08-20 17:12:28.991 -0700 |
| 2024-08-19 18:12:33.824 -0700 | b5624ef0-1f35-452f-b132-09d8f0592e52 | 2024-08-20 18:12:33.824 -0700 |
| 2024-08-19 19:12:43.830 -0700 | eca1a94a-fd40-46db-a2bc-4afba6a38c0a | 2024-08-20 19:12:43.830 -0700 |
| 2024-08-19 20:12:45.446 -0700 | 8ee2fd7e-1afe-42e1-acd7-79582765a910 | 2024-08-20 20:12:45.446 -0700 |
| 2024-08-19 21:12:55.305 -0700 | d38caf14-f8a5-4ba8-a248-8287e0cdcf40 | 2024-08-20 21:12:55.305 -0700 |
+-------------------------------+--------------------------------------+-----------+-------------------+

• 복원할 스키마 백업의 ID를 backup_id 열에서 찾아요.

SHOW BACKUPS IN BACKUP SET s1_backups;

+-------------------------------+--------------------------------------+-------------------------------+
| created_on                    | backup_id                            | expire_on                     |
|-------------------------------+--------------------------------------+-------------------------------|
| 2024-08-19 17:12:28.991 -0700 | 0a0382e1-d265-46e9-b152-4c3b2b859e65 | 2024-08-20 17:12:28.991 -0700 |
| 2024-08-19 18:12:33.824 -0700 | 8dbcf919-3393-4590-928f-5481d7f2502f | 2024-08-20 18:12:33.824 -0700 |
| 2024-08-19 19:12:43.830 -0700 | 8ee2fd7e-1afe-42e1-acd7-79582765a910 | 2024-08-20 19:12:43.830 -0700 |
| 2024-08-19 20:12:45.446 -0700 | bd729a79-01bc-444d-a550-adaaa31ab62f | 2024-08-20 20:12:45.446 -0700 |
| 2024-08-19 21:12:55.305 -0700 | 9a8802c5-5fbd-4200-a09d-43e046103939 | 2024-08-20 21:12:55.305 -0700 |
+-------------------------------+--------------------------------------+-------------------------------+

• 복원할 데이터베이스 백업의 ID를 backup_id 열에서 찾아요.

SHOW BACKUPS IN BACKUP SET d1_backups;

+-------------------------------+--------------------------------------+-------------------------------+
| created_on                    | backup_id                            | expire_on                     |
|-------------------------------+--------------------------------------+-------------------------------|
| 2024-08-19 17:12:28.991 -0700 | 42435925-4e77-4b01-ba89-8163ac03e12f | 2024-08-20 17:12:28.991 -0700 |
| 2024-08-19 18:12:33.824 -0700 | 29c2c1b9-6599-4f0b-87b8-d43377fd7c77 | 2024-08-20 18:12:33.824 -0700 |
| 2024-08-19 19:12:43.830 -0700 | a4283984-a063-4415-acc4-0e3c19259fad | 2024-08-20 19:12:43.830 -0700 |
| 2024-08-19 20:12:45.446 -0700 | ffe25397-64b9-4c5f-b061-23a1885dc2dc | 2024-08-20 20:12:45.446 -0700 |
| 2024-08-19 21:12:55.305 -0700 | 28e12b8a-aab8-40a8-ae39-9a5a5f654d66 | 2024-08-20 21:12:55.305 -0700 |
+-------------------------------+--------------------------------------+-------------------------------+

• 2024-08-19 18:12:33에 촬영된 테이블 t1의 백업을 복원해요.

CREATE TABLE restored_t1 FROM BACKUP SET t1_backups IDENTIFIER 'b5624ef0-1f35-452f-b132-09d8f0592e52';

• 2024-08-19 18:12:33에 촬영된 스키마 s1의 백업을 복원해요.

CREATE SCHEMA restored_s1 FROM BACKUP SET s1_backups IDENTIFIER '8dbcf919-3393-4590-928f-5481d7f2502f';

• 2024-08-19 18:12:33에 촬영된 데이터베이스 d1의 백업을 복원해요.

CREATE DATABASE restored_d1 FROM BACKUP SET d1_backups IDENTIFIER '29c2c1b9-6599-4f0b-87b8-d43377fd7c77';

백업 세트에서 백업 삭제

모든 백업 세트에 대해 법적 보류가 없는 가장 오래된 백업만 삭제할 수 있어요. 백업 ID를 지정해 삭제해요. 법적 보류가 없는 백업은 is_under_legal_hold 속성을 검사해 찾을 수 있어요. 가장 오래된 백업은 created_on 속성을 검사해 찾을 수 있어요.

참고(Note): 백업 세트에 보존 잠금이 있는 백업 정책이 연결되어 있거나 특정 백업에 법적 보류가 적용되면 백업 세트에서 어떤 백업도 삭제할 수 없어요.

백업 세트에서 삭제하는 백업은 세트에서 가장 이른 백업이어야 해요.

• 다음 출력의 backup_id 열에서 삭제할 테이블 백업의 ID를 찾아요. created_on 열 기준 오름차순 정렬은 가장 오래된 백업을 첫 번째로 둬요. SELECT 명령에 LIMIT 1을 추가해 가장 오래된 백업의 세부정보가 있는 행만 반환할 수 있어요.

SHOW BACKUPS IN BACKUP SET t1_backups ->>
  SELECT "created_on", "backup_id", "expire_on" FROM $1
 WHERE "is_under_legal_hold" = 'N'
 ORDER BY "created_on";

+-------------------------------+--------------------------------------+-------------------------------+
| created_on                    | backup_id                            | expire_on                     |
|-------------------------------+--------------------------------------+-------------------------------|
| 2024-08-19 17:12:28.991 -0700 | 983e0b66-91eb-41cb-8a0b-037abfec1914 | 2024-08-20 17:12:28.991 -0700 |
| 2024-08-19 18:12:33.824 -0700 | b5624ef0-1f35-452f-b132-09d8f0592e52 | 2024-08-20 18:12:33.824 -0700 |
| 2024-08-19 19:12:43.830 -0700 | eca1a94a-fd40-46db-a2bc-4afba6a38c0a | 2024-08-20 19:12:43.830 -0700 |
| 2024-08-19 20:12:45.446 -0700 | 8ee2fd7e-1afe-42e1-acd7-79582765a910 | 2024-08-20 20:12:45.446 -0700 |
| 2024-08-19 21:12:55.305 -0700 | d38caf14-f8a5-4ba8-a248-8287e0cdcf40 | 2024-08-20 21:12:55.305 -0700 |
+-------------------------------+--------------------------------------+-------------------------------+

• backup_id를 사용해 2024-08-19 17:12:28에 생성된 t1_backups 백업을 삭제해요.

ALTER BACKUP SET t1_backups DELETE BACKUP IDENTIFIER '983e0b66-91eb-41cb-8a0b-037abfec1914';

• 다음 출력의 backup_id 열에서 삭제할 스키마 백업의 ID를 찾아요.

SHOW BACKUPS IN BACKUP SET s1_backups ->>
  SELECT "created_on", "backup_id", "expire_on" FROM $1 ORDER BY "created_on";

+-------------------------------+--------------------------------------+-------------------------------+
| created_on                    | backup_id                            | expire_on                     |
|-------------------------------+--------------------------------------+-------------------------------|
| 2024-08-19 17:12:28.991 -0700 | 28e12b8a-aab8-40a8-ae39-9a5a5f654d66 | 2024-08-20 17:12:28.991 -0700 |
| 2024-08-19 18:12:33.824 -0700 | 46a1e22a-8557-432f-a14c-1261a4ca2b34 | 2024-08-20 18:12:33.824 -0700 |
| 2024-08-19 19:12:43.830 -0700 | 3e42fef6-b895-4055-a59f-179744d015d3 | 2024-08-20 19:12:43.830 -0700 |
| 2024-08-19 20:12:45.446 -0700 | 7807d24e-285e-4741-b332-87c32bad5cb6 | 2024-08-20 20:12:45.446 -0700 |
| 2024-08-19 21:12:55.305 -0700 | e022e619-ee83-45a0-b2b7-9007e284bdb3 | 2024-08-20 21:12:55.305 -0700 |
+-------------------------------+--------------------------------------+-------------------------------+

• backup_id를 사용해 2024-08-19 17:12:28에 생성된 s1_backups 백업을 삭제해요.

ALTER BACKUP SET s1_backups DELETE BACKUP IDENTIFIER '28e12b8a-aab8-40a8-ae39-9a5a5f654d66';

• 다음 출력의 backup_id 열에서 삭제할 데이터베이스 백업의 ID를 찾아요.

SHOW BACKUPS IN BACKUP SET d1_backups ->>
  SELECT "created_on", "backup_id", "expire_on" FROM $1 ORDER BY "created_on";

+-------------------------------+--------------------------------------+-------------------------------+
| created_on                    | backup_id                            | expire_on                     |
|-------------------------------+--------------------------------------+-------------------------------|
| 2024-08-19 17:12:28.991 -0700 | d3a77432-c98d-4969-91a9-fffae5dd655c | 2024-08-20 17:12:28.991 -0700 |
| 2024-08-19 18:12:33.824 -0700 | 0a0382e1-d265-46e9-b152-4c3b2b859e65 | 2024-08-20 18:12:33.824 -0700 |
| 2024-08-19 19:12:43.830 -0700 | 25e01ee0-ea9d-4bb7-af7f-f3fe87f9409e | 2024-08-20 19:12:43.830 -0700 |
| 2024-08-19 20:12:45.446 -0700 | a12294f5-fc63-49cf-84f1-c7b72f7664af | 2024-08-20 20:12:45.446 -0700 |
| 2024-08-19 21:12:55.305 -0700 | 28e12b8a-aab8-40a8-ae39-9a5a5f654d66 | 2024-08-20 21:12:55.305 -0700 |
+-------------------------------+--------------------------------------+-------------------------------+

• backup_id를 사용해 2024-08-19 17:12:28에 생성된 d1_backups 백업을 삭제해요.

ALTER BACKUP SET d1_backups DELETE BACKUP IDENTIFIER 'd3a77432-c98d-4969-91a9-fffae5dd655c';

• 2024-08-19 21:12:55에 생성된 더 최근의 d1_backups 백업을 삭제하려 시도해요. 백업 세트에서 가장 오래된 백업이 아닌 백업을 삭제하는 것을 Snowflake가 방지하는 방식을 주목해요.

ALTER BACKUP SET d1_backups DELETE BACKUP IDENTIFIER '28e12b8a-aab8-40a8-ae39-9a5a5f654d66';

Backup '28e12b8a-aab8-40a8-ae39-9a5a5f654d66' cannot be deleted as it is not the oldest active backup in the backup set D1_BACKUPS.

백업 세트 삭제

DROP BACKUP SET 명령을 사용해 백업 세트를 삭제할 수 있어요.

참고(Note): 보존 잠금이 있고 만료되지 않은 백업이 있는 백업 세트는 삭제할 수 없어요. 백업 중 하나에 법적 보류가 있으면 백업 세트도 삭제할 수 없어요.

t1_backups 백업 세트를 삭제해요.

DROP BACKUP SET t1_backups;

s1_backups 백업 세트를 삭제해요.

DROP BACKUP SET s1_backups;

d1_backups 백업 세트를 삭제해요.

DROP BACKUP SET d1_backups;

특정 테이블의 백업을 포함하는 모든 백업 세트 찾기

다음 예시는 특정 스키마와 데이터베이스 안의 특정 테이블을 포함하는 모든 백업 세트를 찾는 방법을 보여줘요. SHOW TABLES 명령은 파이프 연산자를 사용해 데이터베이스, 스키마, 테이블의 이름을 검색해 변수에 저장해요. SHOW BACKUP SETS 출력은 테이블을 포함하는 데이터베이스, 테이블을 포함하는 스키마, 또는 그 단일 테이블을 백업하는 백업 세트가 표시되도록 필터링돼요.

SHOW BACKUP SETS의 필터링된 출력은 my_big_important_database 데이터베이스에 대한 데이터베이스 백업 세트 두 개, my_big_important_database.public 스키마에 대한 스키마 백업 세트 하나, my_big_important_database.public.my_small_secondary_table 테이블에 대한 테이블 백업 세트 하나가 있다는 것을 보여줘요.

SHOW TABLES IN SCHEMA public ->>
  SET (dname, sname, tname) =
    (SELECT "database_name", "schema_name", "name" FROM $1
      WHERE "name" = 'MY_SMALL_SECONDARY_TABLE' AND "kind" = 'TABLE');

SHOW BACKUP SETS ->> SELECT "object_kind", "name", "database_name", "schema_name", "object_name" FROM $1
  WHERE ("object_kind" = 'TABLE' AND "database_name" = $dname AND "schema_name" = $sname AND "object_name" = $tname)
    OR ("object_kind" = 'SCHEMA' AND "database_name" = $dname AND "object_name" = $sname)
    OR ("object_kind" = 'DATABASE' AND "object_name" = $dname);

+-------------+------------------+---------------------------+-------------+---------------------------+
| object_kind | name             | database_name             | schema_name | object_name               |
|-------------+------------------+---------------------------+-------------+---------------------------|
| DATABASE    | DATABASE_BACKUP  | MY_BIG_IMPORTANT_DATABASE | PUBLIC      | MY_BIG_IMPORTANT_DATABASE |
| DATABASE    | DATABASE_BACKUP2 | MY_BIG_IMPORTANT_DATABASE | PUBLIC      | MY_BIG_IMPORTANT_DATABASE |
| SCHEMA      | SCHEMA_BACKUP3   | MY_BIG_IMPORTANT_DATABASE | PUBLIC      | PUBLIC                    |
| TABLE       | TABLE_BACKUP2    | MY_BIG_IMPORTANT_DATABASE | PUBLIC      | MY_SMALL_SECONDARY_TABLE  |
+-------------+------------------+---------------------------+-------------+---------------------------+

종속성이 있는 테이블의 백업 생성

다음 예시는 다른 스키마의 시퀀스와 외래 키를 참조하는 테이블에 대한 테이블 백업을 만드는 방법을 보여줘요. 준비를 위해 other_schema 스키마를 만들고 시퀀스와 테이블을 포함시켜요. 그런 다음 public 스키마에 시퀀스와 다른 테이블을 참조하는 기본 테이블을 만들어요.

USE DATABASE my_big_important_database;

CREATE SCHEMA other_schema;
USE SCHEMA other_schema;

CREATE SEQUENCE my_sequence;
CREATE TABLE my_dimension_table (id INT AUTOINCREMENT PRIMARY KEY);

USE SCHEMA public;
CREATE TABLE dependent_table
(
   id INT DEFAULT my_big_important_database.other_schema.my_sequence.NEXTVAL PRIMARY KEY,
   foreign_id INT,
   FOREIGN KEY (foreign_id) REFERENCES my_big_important_database.other_schema.my_dimension_table(id)
 );

SELECT GET_DDL('TABLE','dependent_table');

GET_DDL() 출력은 다른 스키마를 가리키는 참조를 보여줘요.

+-------------------------------------------+
| GET_DDL('TABLE','DEPENDENT_TABLE')        |
|-------------------------------------------|
| create or replace TABLE DEPENDENT_TABLE ( |
|     ID NUMBER(38,0) NOT NULL DEFAULT MY_BIG_IMPORTANT_DATABASE.OTHER_SCHEMA.MY_SEQUENCE.NEXTVAL,
|     FOREIGN_ID NUMBER(38,0),                |
|     primary key (ID),                       |
|     foreign key (FOREIGN_ID) references MY_BIG_IMPORTANT_DATABASE.OTHER_SCHEMA.MY_DIMENSION_TABLE(ID)
| );                                        |
+-------------------------------------------+

다음으로 테이블에 대한 백업 세트를 만들고 백업을 추가해요.

CREATE BACKUP SET dependency_experiments FOR TABLE dependent_table;
ALTER BACKUP SET dependency_experiments ADD BACKUP;
SHOW BACKUPS IN BACKUP SET dependency_experiments;

SHOW BACKUPS 출력은 복원 작업에 사용할 backup_id 값을 포함해요.

+-------------------------------+--------------------------------------+------------------------+---------------------------+--------------+-----------+
| created_on                    | backup_id                            | backup_set_name        | database_name             | schema_name  | expire_on |
|-------------------------------+--------------------------------------+------------------------+---------------------------+--------------+-----------|
| 2025-07-01 11:53:27.860 -0700 | 0fd44138-b571-449b-be0a-72779501f80e | DEPENDENCY_EXPERIMENTS | MY_BIG_IMPORTANT_DATABASE | OTHER_SCHEMA | NULL      |
+-------------------------------+--------------------------------------+------------------------+---------------------------+--------------+-----------+

새 이름으로 그 테이블을 복원하고 복원된 테이블이 다른 스키마의 객체를 참조하는지 확인해요.

CREATE TABLE restored_dependent_table FROM BACKUP SET dependency_experiments
  IDENTIFIER '0fd44138-b571-449b-be0a-72779501f80e';

SELECT GET_DDL('TABLE','restored_dependent_table');

+----------------------------------------------------+
| GET_DDL('TABLE','RESTORED_DEPENDENT_TABLE')        |
|----------------------------------------------------|
| create or replace TABLE RESTORED_DEPENDENT_TABLE ( |
|     ID NUMBER(38,0) NOT NULL DEFAULT MY_BIG_IMPORTANT_DATABASE.OTHER_SCHEMA.MY_SEQUENCE.NEXTVAL,
|     FOREIGN_ID NUMBER(38,0),                         |
|     foreign key (FOREIGN_ID) references MY_BIG_IMPORTANT_DATABASE.OTHER_SCHEMA.MY_DIMENSION_TABLE(ID),
|     primary key (ID)                                 |
| );                                                 |
+----------------------------------------------------+

참조된 객체가 더 이상 존재하지 않으면 어떤 일이 발생하는지 설명하기 위해 시퀀스를 삭제하고 같은 백업에서 테이블을 다시 복원해요.

DROP SEQUENCE my_big_important_database.other_schema.my_sequence;
CREATE OR REPLACE TABLE restored_dependent_table FROM BACKUP SET dependency_experiments
  IDENTIFIER '0fd44138-b571-449b-be0a-72779501f80e';

SELECT * FROM restored_dependent_table;

테이블 쿼리는 여전히 작동해요.

+----+------------+
| ID | FOREIGN_ID |
|----+------------+
+----+------------+
0 Row(s) produced. Time Elapsed: 0.129s

하지만 GET_DDL(), DESCRIBE, INSERT 같은 작업은 더 이상 존재하지 않는 시퀀스에 의존하므로 모두 실패해요.

SELECT GET_DDL('TABLE','restored_dependent_table');

002073 (02000): SQL compilation error:
Sequence used as a default value in table 'MY_BIG_IMPORTANT_DATABASE.OTHER_SCHEMA.RESTORED_DEPENDENT_TABLE'
  column 'ID' was not found or could not be accessed.

DESC TABLE restored_dependent_table;

+------------+--------------+--------+-------+----------------------------------------+-------------+------------+-------+------------+---------+-------------+----------------+
| name       | type         | kind   | null? | default                                | primary key | unique key | check | expression | comment | policy name | privacy domain |
|------------+--------------+--------+-------+----------------------------------------+-------------+------------+-------+------------+---------+-------------+----------------|
| ID         | NUMBER(38,0) | COLUMN | N     | [sequence cannot be found or accessed] | Y           | N          | NULL  | NULL       | NULL    | NULL        | NULL           |
| FOREIGN_ID | NUMBER(38,0) | COLUMN | Y     | NULL                                   | N           | N          | NULL  | NULL       | NULL    | NULL        | NULL           |
+------------+--------------+--------+-------+----------------------------------------+-------------+------------+-------+------------+---------+-------------+----------------+

INSERT INTO restored_dependent_table (foreign_id) VALUES (2);

002073 (02000): SQL compilation error:
Sequence used as a default value in table 'MY_BIG_IMPORTANT_DATABASE.OTHER_SCHEMA.RESTORED_DEPENDENT_TABLE'
  column 'ID' was not found or could not be accessed.

동적 테이블의 백업 생성

동적 테이블은 항상 다른 테이블에 대한 참조를 포함해요. 따라서 동적 테이블에는 스키마 백업이나 데이터베이스 백업을 사용하는 것이 더 좋을 수 있어요. 원래 테이블과 동적 테이블을 같은 백업에 포함할 수 있기 때문이에요.

동적 테이블에 대한 테이블 백업을 만들면 CREATE BACKUP SET 명령과 백업에서 복원할 때 CREATE TABLE 명령에 키워드 DYNAMIC을 포함해요. 다음 예시는 동적 테이블, 그 테이블에 대한 테이블 백업 세트를 설정하고 첫 번째 백업을 만들어요.

CREATE DYNAMIC TABLE my_dynamic_table
  TARGET_LAG = '1 minute'
  WAREHOUSE = my_wh
  AS SELECT * FROM my_base_table WHERE col1 IS NOT NULL;

CREATE BACKUP SET dynamic_table_backups
  FOR DYNAMIC TABLE my_dynamic_table;

ALTER BACKUP SET dynamic_table_backups ADD BACKUP;

다음 예시는 다양한 시점에 생성된 백업의 백업 ID를 확인하는 방법을 보여줘요. 이 경우 가장 새로운 백업이 결과 집합의 첫 번째 행이에요. 그런 다음 CREATE DYNAMIC TABLE 명령에서 백업의 ID를 사용해요.

SHOW BACKUPS IN BACKUP SET dynamic_table_backups
  ->> SELECT "created_on", "backup_id" FROM $1
        ORDER BY "created_on" DESC;

CREATE DYNAMIC TABLE restored_dynamic_table
  FROM BACKUP SET dynamic_table_backups
    IDENTIFIER '<backup_id_from_SHOW_BACKUPS_output>';

팁(Tip): 백업에서 동적 테이블을 복원하면 Snowflake가 첫 새로고침 중에 새 테이블을 자동으로 초기화해요.

법적 보류 추가·제거

Snowflake 백업의 법적 보류를 다루기 전에 그 목적과 요구사항을 배워요. 자세한 내용은 법적 보류를 참고해요.

조직의 법무·규정 준수 팀이 어떤 유형의 데이터를 보존해야 하는지 지정하는 소송 보류 요청을 보낸다고 가정해 봐요. 그 경우 다음과 같은 프로세스를 따를 수 있어요.

• 법무 팀과 협력해 관련 데이터가 어디에 저장되어 있는지, 연관된 객체를 포함하는 백업 세트가 무엇인지 식별해요.
• 백업 세트 내 적용 가능한 기간의 백업에 법적 보류를 걸어요. 이렇게 하면 해당 백업에 대한 자동 만료가 비활성화돼요. Snowflake가 일정에 따라 자동으로 만든 백업이나 수동으로 만든 백업에 법적 보류를 걸 수 있어요. 법적 보류는 백업 세트에 연결된 백업 정책, 만료 기간, 보존 잠금이 있는지 여부와 무관하게 적용돼요.
• 백업 세트를 포함하는 데이터베이스가 복제되는 보조 계정에 대해 새로고침 작업을 수행해요. 이렇게 하면 법적 보류와 관련 백업이 장애 조치·장애 복구 작업 전반에 걸쳐 보존돼요.
• Snowflake 접근 통제와 로그를 사용해 법적 보류 중인 데이터에 대한 접근을 감사해요.
• 법적 사건이 종결되고 법무 팀이 법적 보류 제거를 승인하면 APPLY LEGAL HOLD 권한이 있는 사용자가 법적 보류를 해제해요. 그러면 정상적인 만료 자동화가 재개돼요.

이 예시는 특정 백업 세트 내 백업의 법적 보류 수명 주기 동안 사용할 수 있는 SQL 명령의 순서를 보여줘요. SHOW BACKUPS IN BACKUP SET 명령을 사용해 관련 백업의 식별자를 찾고 "is_under_legal_hold" 열을 확인해 법적 보류가 이미 있는지 확인해요. 그런 다음 특정 백업에서 법적 보류를 추가하거나 제거해요.

USE ROLE <role_name>; -- use a role that has the APPLY LEGAL HOLD privilege
SHOW BACKUPS IN BACKUP SET <backup_set_name>
  ->> SELECT * FROM $1 WHERE "is_under_legal_hold" = 'N';
ALTER BACKUP SET <backup_set_name>
  MODIFY BACKUP IDENTIFIER '<backup_identifier>'
  ADD LEGAL HOLD;

USE ROLE <role_name>; -- use a role that has the APPLY LEGAL HOLD privilege
SHOW BACKUPS IN BACKUP SET <backup_set_name>
  ->> SELECT * FROM $1 WHERE "is_under_legal_hold" = 'Y';
ALTER BACKUP SET <backup_set_name>
  MODIFY BACKUP IDENTIFIER '<backup_identifier>'
  REMOVE LEGAL HOLD;

팁(Tip): INFORMATION_SCHEMA.BACKUPS 또는 ACCOUNT_USAGE.BACKUPS 뷰의 "is_under_legal_hold" 열을 쿼리해 법적 보류의 존재 여부를 확인할 수도 있어요.

백업 관련 객체 복제

복제를 데이터베이스, 스키마, 테이블 백업과 함께 사용할 때 복제 그룹과 장애 조치 그룹에 백업 세트와 백업 정책을 포함하는 데이터베이스를 지정해요. 복제 그룹과 장애 조치 그룹을 구성하고 백업 세트와 백업 정책을 포함할 데이터베이스와 스키마를 선택해 백업 관련 객체가 복제되는 방식을 제어할 수 있어요. 자세한 내용은 데이터베이스, 스키마, 테이블 백업의 백업 복제를 참고해요.

백업 세트와 백업 정책은 데이터베이스 객체예요. Snowflake는 백업 세트와 백업 정책을 해당 객체를 포함하는 데이터베이스와 스키마와 함께 복제해요.

Snowflake는 클로닝과 유사한 메커니즘을 사용해 백업의 시간과 스토리지 사용을 최소화하므로 각 백업이 모든 테이블 데이터의 완전한 새 사본을 요구하지 않아요. 백업 세트가 백업 세트가 적용되는 데이터베이스·스키마·테이블과 다른 장애 조치 그룹의 일부라면 해당 복제 그룹이나 장애 조치 그룹의 첫 새로고침에 데이터의 일회성 전체 전송이 있어요.

복제 그룹 또는 장애 조치 그룹에 백업 세트가 포함되면 새로고침 지연 시간의 증가는 마지막 새로고침 이후 생성된 백업 수에 비례해요.

이전 백업에 대한 만료 기간을 정의하면 자동 삭제가 기본 계정에서 발생해요. 새로고침 작업을 수행하면 만료된 백업이 보조 계정에서 제거돼요.

중요(Important): 백업 세트를 복제한다면 해당 백업 세트의 백업에 법적 보류를 건 직후에 새로고침(refresh)을 수행해야 해요. 법적 보류를 포함하는 백업 세트를 복제하기 전에 장애 조치를 수행하면, 원래 기본 계정으로 장애 복구할 때 원래 백업 세트가 덮어써져 법적 보류가 지워질 수 있어요.

따라서 다음 관행을 따라 백업 관련 객체의 복제를 세부 조정할 수 있어요.

• 새로고침 실패 가능성을 최소화하려면 백업 세트와 선택적 백업 정책을 같은 데이터베이스와 스키마에 두어요. 실용적이지 않다면 이들을 같은 복제 그룹이나 장애 조치 그룹에 두어요. 이렇게 하면 이러한 관련 객체가 모두 동시에 복제돼요.
• 복제할 백업 관련 객체와 복제 일정에 대한 유연성을 최대화하려면 백업 세트와 선택적 백업 정책을 관련 데이터베이스·스키마·테이블과 다른 데이터베이스에 둬요. 이렇게 하면 백업 관련 객체가 복제되는지, 얼마나 자주 복제되는지를 지정할 수 있어요.
• 이전 백업에 대한 만료 기간이 있는 정책을 적용할 때는 만료 기간을 복제 새로고침 작업 사이의 간격보다 길게 만들어요. 이렇게 하면 새 백업이 만료되기 전에 보조 계정에 최소 한 번 복제돼요.
• 법적 보류를 추가한 직후 백업 세트를 포함하는 데이터베이스가 복제되는 모든 보조 계정에서 새로고침 작업을 수행해요. 이렇게 하면 법적 보류와 관련 백업이 장애 조치·장애 복구 작업 전반에 걸쳐 보존돼요.
• 백업 정책과 관련 백업 세트를 서로 다른 복제 그룹이나 장애 조치 그룹의 일부인 데이터베이스에 둔다고 가정해 봐요. 그 경우 백업 정책을 포함하는 그룹의 초기 새로고침을 먼저 해야 해요. 그렇지 않으면 보조 계정에서 연결된 백업 정책이 없는 백업 세트를 만들 수 없으므로 새로고침 작업이 실패해요.

참고(Note): 백업 세트를 백업 세트 대상 객체와 다른 복제 그룹이나 장애 조치 그룹에 두려면 백업 세트를 포함하는 그룹의 첫 새로고침 동안 모든 데이터의 전체 전송이 필요해요.

보조 계정에서 스키마 백업이나 데이터베이스 백업을 복원하면 복원된 스키마·데이터베이스 내 객체에 대한 참조는 참조된 객체가 백업과 같은 장애 조치 그룹의 일부가 아니면 제대로 해석되지 않을 수 있어요.

백업과 백업 작업 모니터링

다음 뷰를 쿼리해 어떤 백업 관련 객체가 존재하는지, 그 속성, 스토리지 사용량을 확인할 수 있어요.

Information schema:

• BACKUP_POLICIES 뷰
• BACKUP_SETS 뷰
• BACKUPS 뷰

Account usage:

• BACKUP_OPERATION_HISTORY 뷰
• BACKUP_POLICIES 뷰
• BACKUP_SETS 뷰
• BACKUP_STORAGE_USAGE 뷰
• BACKUPS 뷰

Organization usage:

• BACKUP_OPERATION_HISTORY 뷰
• BACKUP_POLICIES 뷰
• BACKUP_SETS 뷰
• BACKUPS 뷰

SQL 참조 주제

백업 정책

• CREATE BACKUP POLICY
• ALTER BACKUP POLICY
• DROP BACKUP POLICY
• SHOW BACKUP POLICIES

백업 세트

• CREATE BACKUP SET
• ALTER BACKUP SET
• DROP BACKUP SET
• SHOW BACKUP SETS

백업

실제 CREATE BACKUP 명령을 실행하지 않아요. 새 백업을 만들려면 ALTER BACKUP SET … ADD BACKUP을 실행해요. 또는 백업 세트를 일정이 있는 백업 정책과 연결하면 Snowflake가 지정된 일정에 따라 백업 세트에 백업을 자동으로 생성해요. 이전 백업을 삭제하려면 ALTER BACKUP SET … DELETE BACKUP을 실행해요. 이러한 작업은 특정 백업의 식별자를 지정해야 해요. 다음 명령을 사용해 백업 식별자와 각 백업이 생성된 시점 등의 기타 정보를 찾을 수 있어요.

• SHOW BACKUPS IN BACKUP SET

백업에서 객체 복원

CREATE *object_kind* FROM BACKUP SET 구문을 사용해 각 종류의 객체를 적절한 종류의 백업 세트에서 복원해요.

백업 세트의 추가 백업은 복원된 객체가 아닌 원래 객체를 사용해요. 복원된 객체를 원래 객체와 같은 이름으로 바꾸더라도 마찬가지예요. 복원 후 같은 백업 세트를 계속 사용하려면 새 이름으로 객체를 복원한 다음 데이터를 원래 객체로 다시 전송해요.

• CREATE DATABASE FROM BACKUP SET
• CREATE SCHEMA FROM BACKUP SET
• CREATE TABLE FROM BACKUP SET

뷰

다음 시스템 뷰는 백업, 백업 세트, 백업 정책과 관련된 메타데이터를 포함해요.

Information schema 뷰

INFORMATION_SCHEMA 스키마의 이 뷰들은 현재 존재하는 백업 관련 객체에 대한 정보를 포함해요.

• BACKUP_POLICIES 뷰
• BACKUP_SETS 뷰
• BACKUPS 뷰

Account usage 뷰

ACCOUNT_USAGE 스키마의 이 뷰들은 존재하거나 삭제된 백업 관련 객체, 백업에 대해 수행된 작업, 사용하는 스토리지에 대한 계정 수준 정보를 포함해요.

• BACKUP_OPERATION_HISTORY 뷰
• BACKUP_POLICIES 뷰
• BACKUP_SETS 뷰
• BACKUP_STORAGE_USAGE 뷰
• BACKUPS 뷰

Organization usage 뷰

ORGANIZATION_USAGE 스키마의 이 뷰들은 존재하거나 삭제된 백업 관련 객체, 백업에 대해 수행된 작업, 사용하는 스토리지에 대한 조직 수준 정보를 포함해요.

• BACKUP_OPERATION_HISTORY 뷰
• BACKUP_POLICIES 뷰
• BACKUP_SETS 뷰
• BACKUPS 뷰

용어 변경

이 기능은 이제 스냅샷(snapshots) 대신 **백업(backups)**이라고 해요. 모든 SQL 명령, 뷰, 권한은 BACKUP 용어를 사용해요.

• CREATE BACKUP POLICY, CREATE BACKUP SET
• ALTER BACKUP POLICY, ALTER BACKUP SET
• DROP BACKUP POLICY, DROP BACKUP SET
• SHOW BACKUP POLICIES, SHOW BACKUP SETS, SHOW BACKUPS IN BACKUP SET
• Account Usage, Organization Usage, Information Schema의 BACKUPS, BACKUP_POLICIES, BACKUP_SETS 뷰
• APPLY BACKUP RETENTION LOCK 권한

이전 SNAPSHOT/SNAPSHOTS 이름은 여전히 존재하지만 해당 BACKUP/BACKUPS 등가물을 선호하여 더 이상 사용되지 않아요. 예를 들어:

• CREATE SNAPSHOT POLICY는 더 이상 사용되지 않으며, 대신 CREATE BACKUP POLICY를 사용해요.
• SNAPSHOTS 뷰는 더 이상 사용되지 않으며, 대신 BACKUPS 뷰를 사용해요.
• APPLY SNAPSHOT RETENTION LOCK 권한은 더 이상 사용되지 않으며, 대신 APPLY BACKUP RETENTION LOCK 권한을 사용해요.

더 이상 사용되지 않는 명령, 뷰, 권한은 계속 작동하지만 Snowflake는 향후 릴리스에서 제거할 예정이에요.

더 알아보기 (Learn more)

• 클론 이해 — 제로 카피 복제 메커니즘
• 복제 소개 — 비즈니스 연속성·재해 복구
• CREATE BACKUP SET — 백업 세트 생성 명령