Time Travel, Fail-safe, 제로 카피 클론 (보존 기간과 복구)
실수로 지운 데이터를 되살리는 Time Travel, Snowflake 만 꺼낼 수 있는 Fail-safe 7일, 저장 비용 없이 환경을 복제하는 제로 카피 클론의 동작과 보존 기간 설정, 저장 비용 함정을 정리합니다.
한눈에 보기
| 기능 | 기간 | 누가 꺼내나 | 저장 비용 |
|---|---|---|---|
| Time Travel | 0~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 Travel | Fail-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를 정해 둡니다.