본문으로 건너뛰기
snowflake검색
아키텍처

Time Travel, Fail-safe, 제로 카피 클론 (보존 기간과 복구)

실수로 지운 데이터를 되살리는 Time Travel, Snowflake 만 꺼낼 수 있는 Fail-safe 7일, 저장 비용 없이 환경을 복제하는 제로 카피 클론의 동작과 보존 기간 설정, 저장 비용 함정을 정리합니다.

Time TravelFail-safeUNDROP클론DATA_RETENTION_TIME_IN_DAYS임시 테이블2026-10 기준, 약 9분

한눈에 보기

기능기간누가 꺼내나저장 비용
Time Travel0~90일 (Standard 에디션은 최대 1일)사용자가 SQL 로바뀌거나 지워진 파티션만큼
Fail-safe영구 테이블은 7일 고정Snowflake 지원팀만 (최선 노력)그 기간의 이전 데이터만큼
클론원본 시점 그대로사용자클론 후 바뀐 파티션만

세 기능 모두 마이크로 파티션이 불변 파일이라는 데서 나옵니다. 데이터를 바꾸면 새 파티션이 생기고 옛 파티션은 지워지지 않고 보관 상태로 넘어갑니다. 그래서 과거 시점을 읽을 수 있고, 클론은 파일을 복사하지 않고 같은 파일을 가리키기만 합니다.

Time Travel

과거 시점 읽기

-- 1시간 전 상태
SELECT * FROM sales.orders AT(OFFSET => -3600);

-- 특정 시각
SELECT * FROM sales.orders AT(TIMESTAMP => '2026-10-20 09:00:00'::TIMESTAMP_LTZ);

-- 잘못된 DELETE 직전 상태 (쿼리 ID 기준)
SELECT * FROM sales.orders BEFORE(STATEMENT => '01b8c2a4-0000-1234-0000-000000000001');

지운 객체 되살리기

DROP TABLE sales.orders;
UNDROP TABLE sales.orders;   -- 스키마, 데이터베이스도 UNDROP 가능

-- 잘못 덮어쓴 테이블을 과거 시점으로 복구
CREATE OR REPLACE TABLE sales.orders_restored CLONE sales.orders
  AT(TIMESTAMP => '2026-10-20 09:00:00'::TIMESTAMP_LTZ);

주의 CREATE OR REPLACE TABLE 로 테이블을 바꾸면 이전 테이블은 DROP 된 것으로 처리됩니다. 같은 이름의 새 테이블이 있으면 UNDROP 이 실패하므로, 새 테이블 이름을 먼저 바꾼 뒤 UNDROP 합니다.

보존 기간 설정

ALTER ACCOUNT SET DATA_RETENTION_TIME_IN_DAYS = 1;          -- 계정 기본값
ALTER DATABASE finance SET DATA_RETENTION_TIME_IN_DAYS = 30; -- 중요한 DB 만 길게
ALTER TABLE staging.raw_events SET DATA_RETENTION_TIME_IN_DAYS = 0; -- 다시 만들 수 있는 테이블
  • 계정, 데이터베이스, 스키마, 테이블 수준에서 정할 수 있고 아래가 위를 덮습니다.
  • MIN_DATA_RETENTION_TIME_IN_DAYS 를 계정에 걸면 그보다 짧게 못 내립니다. 실수로 0 을 넣는 사고를 막는 안전장치입니다.
  • 스트림이 걸린 테이블은 스트림이 오래되지 않도록 보존 기간이 자동으로 늘어날 수 있습니다 (MAX_DATA_EXTENSION_TIME_IN_DAYS, 기본 14일). 자세한 것은 Streams 와 Tasks 에 있습니다.

Fail-safe

  • 영구 테이블에서 Time Travel 기간이 끝난 데이터는 7일 동안 Fail-safe 로 넘어갑니다. 기간은 바꿀 수 없습니다.
  • 사용자가 직접 꺼낼 수 없습니다. Snowflake 지원팀이 장애나 재해 상황에서 최선 노력으로 복구하는 마지막 안전망이고, 복구에는 몇 시간에서 며칠이 걸릴 수 있습니다.
  • 임시(transient) 와 세션 임시(temporary) 테이블은 Fail-safe 가 없습니다.

테이블 종류와 보존 기간

종류Time TravelFail-safe쓰임
영구0~90일7일원본, 마트
임시(transient)0~1일없음스테이징, 매일 다시 만드는 중간 테이블
세션 임시(temporary)0~1일없음세션 안에서만
CREATE TRANSIENT TABLE staging.daily_snapshot (...);
CREATE TRANSIENT DATABASE scratch;   -- 안의 모든 테이블이 transient

팁 매일 통째로 지우고 다시 넣는 큰 테이블을 영구 테이블로 두면 날마다 테이블 크기만큼이 Fail-safe 로 7일 쌓입니다. 저장 비용이 갑자기 두세 배가 되는 대표 원인입니다. 이런 테이블은 transient 로 바꿉니다.

저장 비용 확인

SELECT table_catalog, table_schema, table_name, is_transient,
       ROUND(active_bytes / POWER(1024, 4), 3)      AS active_tb,
       ROUND(time_travel_bytes / POWER(1024, 4), 3) AS time_travel_tb,
       ROUND(failsafe_bytes / POWER(1024, 4), 3)    AS failsafe_tb,
       ROUND(retained_for_clone_bytes / POWER(1024, 4), 3) AS clone_tb
FROM snowflake.account_usage.table_storage_metrics
WHERE deleted = FALSE
ORDER BY failsafe_bytes + time_travel_bytes DESC
LIMIT 20;

failsafe_tb 가 active_tb 보다 크다면 위의 "매일 다시 만드는 영구 테이블" 패턴일 가능성이 높습니다.

제로 카피 클론

-- 운영 DB 를 그대로 복제해 개발 환경 만들기 (몇 초, 저장 비용 거의 0)
CREATE DATABASE dev_sales CLONE prod_sales;

-- 배포 전 테이블 백업
CREATE TABLE sales.orders_bak_20261021 CLONE sales.orders;

-- 과거 시점 클론
CREATE SCHEMA sales_yesterday CLONE sales AT(OFFSET => -86400);
  • 클론은 원본과 같은 마이크로 파티션을 가리킵니다. 어느 쪽이든 데이터가 바뀌면 바뀐 부분만 새 파티션이 생기고 그만큼만 저장 비용이 늘어납니다.
  • 데이터베이스나 스키마를 클론하면 하위 객체가 함께 복제됩니다. 권한은 기본적으로 하위 객체의 권한만 따라오고, 클론한 컨테이너 자체의 권한은 따라오지 않습니다. 필요하면 COPY GRANTS 를 씁니다.
  • 파이프, 스트림, 태스크도 함께 복제되지만 동작에 주의할 점이 있습니다. 예를 들어 클론된 태스크는 일시 중지 상태로 만들어지므로 필요하면 직접 재개합니다. 스테이지와 파이프의 세부 규칙은 공식 Cloning considerations 문서를 확인합니다.
  • 클론한 테이블은 Automatic Clustering 이 일시 중지된 상태로 시작합니다.

백업 기능과의 관계

Time Travel 은 짧은 기간의 실수 복구용이고, 몇 달 단위의 규제 보존에는 길게 잡으면 비용이 큽니다. 2026-10 기준 Snowflake 에는 시점 스냅샷인 백업(Backups) 기능이 있습니다. 백업 세트(대상 객체별 백업 묶음)와 백업 정책(주기, 만료, 보존 잠금)으로 데이터베이스, 스키마, 테이블의 사본을 남기고, 2026년 3월부터 객체당 백업 세트 수 제한이 없어졌습니다. 모든 에디션에서 쓸 수 있지만 보존 잠금(retention lock)과 법적 보존(legal hold)은 Business Critical 이상입니다. 임시(transient) 테이블, 하이브리드, Iceberg 테이블, 스테이지, 스트림, 파이프는 백업에 들어가지 않습니다. 장기 보존이 필요하면 Time Travel 을 90일로 늘리기보다 백업 정책을 검토합니다.

주의 보존 잠금은 한 번 걸면 되돌릴 수 없고 ACCOUNTADMIN 이나 Snowflake 지원팀도 만료 전 삭제를 못 합니다. 테스트 계정에서 먼저 연습합니다.

트러블슈팅

  • 증상: UNDROP TABLE 이 "object already exists" 로 실패합니다.

  • 원인: 같은 이름의 테이블이 이미 있습니다 (CREATE OR REPLACE 로 만들어진 새 테이블).

  • 해결: ALTER TABLE t RENAME TO t_new; 후 UNDROP TABLE t; 를 실행합니다.

  • 증상: 어제 지운 데이터를 찾는데 "Time travel data is not available" 오류가 납니다.

  • 원인: 테이블 보존 기간이 0 이거나 transient 테이블입니다. 이미 Fail-safe 로 넘어갔을 수도 있습니다.

  • 해결: SHOW TABLES LIKE ... 의 retention_time 을 확인합니다. Fail-safe 기간이라면 지원 케이스로 요청할 수 있지만 보장되지 않습니다. 중요한 테이블은 미리 보존 기간과 MIN_DATA_RETENTION_TIME_IN_DAYS 를 정해 둡니다.

공식 문서

이 문서에서