障害復旧向けのバックアップと不変ストレージ¶

バックアップ¶

バックアップ は、オブジェクトのポイントインタイムスナップショットを表します。

• オブジェクトは、単一のテーブル、スキーマ、またはデータベース全体のいずれかです。

• 特定のバックアップはSnowflakeによって生成された一意の ID で識別できます。

• バックアップは変更できません。ただし、削除は可能です。また、バックアップの有効期限は変更できます（保持ロック が適用されていない場合に限ります）。

日常業務では、個々のバックアップを操作することはほとんどありません。代わりに、それらを含む バックアップセット を管理します。たとえば、SHOW BACKUPS IN BACKUP SET コマンドを実行すると、バックアップのリストを取得できます。ALTER BACKUP SET コマンドを実行すると、新しいバックアップを作成できます。

バックアップセット¶

バックアップセット は、特定のデータベース、スキーマ、またはテーブルのバックアップのセットを含んでいるスキーマレベルのオブジェクトです。Snowflake には、バックアップセットについて CREATE、ALTER、DROP、SHOW、および DESCRIBE を実行する SQL コマンドがあります。

同じオブジェクトに対して複数のバックアップセットを持つことができます。

セット内のバックアップのライフサイクルは、バックアップセットに添付できるオプションの バックアップポリシー によって決定されます。バックアップセットにバックアップを手動で追加または削除することもできます。バックアップを削除する能力は、他の要因、特に 保持ロック と 法的保持 の影響を受けます。

バックアップポリシー¶

バックアップポリシー は、バックアップセット内のバックアップのライフサイクルを定義する設定を含むスキーマレベルのオブジェクトです。これらの設定には、スケジュール、有効期限、保持ロックが含まれます。

• スケジュール は、バックアップがいつ作成されるかを決定します。スケジュールは、分単位の間隔として、またはcron式として定義できます。たとえば、スケジュールが1時間に設定されている場合、オブジェクトのバックアップは60分ごとに作成されます。

• 有効期限 は、バックアップが有効な時間の長さです。バックアップの有効期限が切れると、その特定のバックアップに法的保持が適用されない限り、Snowflakeは自動的に削除します。

  Tip

  バックアップセットに保持ロックがなく、特定のバックアップに法的保持が適用されていない場合は、有効期限が終了する前にバックアップを手動で削除できます。手動で1度にバックアップを削除することができます。その際は、常に法的保持を持たない最も古いバックアップから始めます。

各バックアップポリシーには、スケジュールと有効期限プロパティのどちらかまたは両方が必要です。たとえば、スケジュールと有効期限付きのポリシーを作成し、そのポリシーが適用されるすべてのバックアップセットのバックアップのすべての作成と削除をSnowflakeに許可することができます。または、古いバックアップの削除を自分で管理する場合は、スケジュールありの有効期限なしのポリシーを作成することもできます。あるいは、有効期限があるがスケジュールがないポリシーを作成し、バックアップの作成を自分で管理することもできます。スケジュールなし、有効期限なしのポリシーは作成できません。

バックアップポリシーをバックアップセットに関連付ける場合は、バックアップセットの作成時に実行するか、後でポリシーを適用できます。あるいは、バックアップポリシーが関連付けられていないバックアップセットを使用することもできます。その場合は、新しいバックアップを取得するタイミングと古いバックアップを期限切れにするタイミングを手動で制御します。

バックアップポリシーは複数のバックアップセットに適用できます。バックアップポリシーを変更すると、Snowflakeはそのポリシーがアタッチされているすべてのバックアップセットに変更を適用します。

保持ロック¶

保持ロック は、定義された有効期限の間、バックアップを削除から保護します。保持ロック付きのバックアップを使用すると、規制コンプライアンスとサイバーレジリエンスに対応したバックアップが可能です。保持ロックを使用したバックアップセットには、次の制限が適用されます。

• バックアップは、ACCOUNTADMIN ロールを含む、どのロールでも削除できません。

• バックアップの有効期限を減らすことはできませんが、有効期限を増やすことはできます。

• セットに期限切れのバックアップがある場合は、バックアップセットをドロップすることはできません。

• 期限切れのバックアップがあるバックアップセットを含むスキーマをドロップすることはできません。

• 期限切れのバックアップがあるバックアップセットを含むデータベースをドロップすることはできません。

• 期限切れのバックアップを持つバックアップセットがあるデータベースを含むアカウントをドロップすることはできません。

法的保持¶

Snowflakeバックアップの 法的保持 機能は、バックアップが上書きされたり削除されたりするのを防ぎます。そうすることで、独自の法的要件に基づいてSnowflakeデータベース、スキーマ、またはテーブルを保持できます。

Snowflakeを使用すると、特定のバックアップに法的保持を設定できます。Snowflakeバックアップが法的保持の対象である場合は、以下の条件が適用されます。

• 誰もバックアップを変更できません。

• 誰もバックアップを削除できません。これは、バックアップが EXPIRE_AFTER_DAYS 期間を経過した場合でも当てはまります。

• バックアップへのアクセスはログに記録され、監査可能です。

• 法的保持は、保持ロックとは異なり、権限ユーザーによって削除できます。

バックアップライフサイクルの概要¶

次の図は、Snowflakeオブジェクト、バックアップ、バックアップセット、およびバックアップポリシーが互いにどのように関連しているかを示しています。この図には、最も単純な種類のバックアップである、単一のテーブルに対するバックアップが含まれています。バックアップ操作ごとに、新しいバックアップが作成されます。その特定のオブジェクトのすべてのバックアップは、バックアップセットにグループ化されます。バックアップセット内のバックアップの自動追加および削除は、バックアップポリシーで制御されます。バックアップから情報を回復するには、CREATE コマンドを使用して特定のバックアップから新しいオブジェクトを作成します。

バックアップの技術的制限¶

現在は、特定のデータベースに対して最大2つのデータベースバックアップセットを作成できます。同様に、特定のスキーマに対して最大2つのスキーマバックアップセットを、特定のテーブルに対して2つのテーブルバックアップセットを作成できます。オブジェクトは、2つ以上のバックアップセットに引き続き表示される可能性があります。たとえば、あるテーブルに、1つまたは2つの関連するバックアップセットがある場合があります。同じテーブルが1つまたは2つのスキーマバックアップセットと、1つまたは2つのデータベースバックアップセットにも含まれている場合もあります。

テーブルから他のオブジェクトへの参照¶

ビューや関数などのオブジェクトは、バックアップ内のスキーマやデータベースの外部にあるオブジェクトを参照できます。バックアップから復元した後もそのような参照が引き続き機能するようにするには、以下のいずれかの戦略を使用します。

• テーブルとそれらが参照するその他のオブジェクトがすべて同じスキーマまたは同じデータベースにある場合は、スキーマまたはデータベース全体のバックアップセットを作成します。そうすれば、Snowflakeはバックアップから復元する際に、相互接続されたすべてのオブジェクトを一度に復元します。

• バックアップセット内のオブジェクトがバックアップセットに含まれていないオブジェクトを参照している場合は、バックアップが復元されると、復元されたオブジェクトからの参照は他のデータベースまたはスキーマにある元のオブジェクトをポイントすることに注意してください。バックアップの取得後に、これらの他のオブジェクトをドロップしたり、プロパティを変更したりすると、復元されたオブジェクトへのアクセス時にエラーが発生する可能性があります。

• アカウントレベルのオブジェクトの場合、復元されたオブジェクトからの参照は*すべて*、元のアカウントレベルのオブジェクトを指します。これは、アカウントレベルのオブジェクトがバックアップの一部ではないためです。たとえば、スキーマバックアップには、セキュリティ統合を参照するシークレットが含まれている場合があります。セキュリティ統合はアカウントレベルのオブジェクトであり、バックアップに含めることはできません。

データベースとスキーマのバックアップに含まれるオブジェクトのタイプ¶

次のテーブルは、データベースまたはスキーマのバックアップに含まれるオブジェクトのリストです。

Snowflakeがオブジェクトとバックアップセットを関連付ける方法¶

データベース、スキーマ、またはテーブルのバックアップセットを作成すると、Snowflakeはバックアップセットをそのデータベース、スキーマ、またはテーブルの内部 ID に関連付けます。元のオブジェクトを削除すると、そのバックアップセットにバックアップを追加することはできません。この動作は、同じ名前のオブジェクトを再作成したり、バックアップから復元されたオブジェクトと置き換えたりした場合にも当てはまります。

代わりに元のオブジェクトの名前を変更した場合は、同じバックアップセットにバックアップを追加して、そのオブジェクトのバックアップを引き続き作成できます。その場合、 SHOWBACKUPSETS の出力は、名前が変更されたオブジェクトの OBJECT_NAME 値を反映するように変更されます。

テーブルのバックアップを作成したいが、CREATE OR REPLACE ステートメントなどによりそのテーブルを頻繁にドロップして再作成している場合は、テーブルを含むスキーマまたはデータベースのバックアップセットにそのテーブルを含めます。そうすることで、テーブルの変更に関係なく、同じバックアップセットを使い続けることができます。

バックアップからテーブルを復元すると、復元されたテーブルは元の名前とは異なる名前で起動します。元のテーブルの内容をバックアップデータで完全に置き換え、同じテーブルのさらなるバックアップには同じバックアップセットを使用し続けると想定します。その場合は、元のテーブルの内容を削除するには TRUNCATE または DELETE ステートメントを使用し、復元されたテーブルからデータをコピーするには INSERT ... SELECT ステートメントを使用します。元のテーブルはドロップしないで、復元されたテーブルの名前を元のテーブルの名前に変更します。

バックアップと暗号化¶

バックアップセット内のデータは、他のSnowflakeオブジェクトやテーブルデータと同じエンドツーエンドの暗号化によって保護されます。Snowflakeの暗号化の詳細については、 Snowflakeのエンドツーエンド暗号化について をご参照ください。

キーのローテーションは、バックアップ内のデータにも適用されます。

バックアップとデータ系統¶

Snowflakeは、データベース、スキーマ、テーブルバックアップを含む データ系統 メタデータを保存しません。バックアップからオブジェクトを復元した後は、復元されたデータの系統情報を表示するために Snowsight は使用できません。

バックアップポリシーおよびセットの作成に必要な権限の付与¶

ロール 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 権限のロールへの付与¶

ロール myrole がバックアップセットにスキーマ hourly_backup_policy を適用できるようにするには、次のステートメントを実行します。

GRANT APPLY ON BACKUP POLICY hourly_backup_policy TO ROLE myrole;

ロールに APPLY BACKUPRETENTION 権限を付与する¶

バックアップセットに保持ロック付きのバックアップポリシーを適用する権限をロールに付与することができます。

ACCOUNTADMIN ロールを持つユーザーのみがこの権限を付与できます。

ロール retention_lock_admin_role がバックアップセットに保持ロック付きのバックアップポリシーを適用できるようにするには、次のステートメントを実行します。

GRANT APPLY BACKUP RETENTION LOCK ON ACCOUNT TO ROLE retention_lock_admin_role;

スケジュールされた保持ロック付きのバックアップを作成する¶

スケジュールに従って保持ロック付きのバックアップを自動的に作成するバックアップセットを作成します。保持ロックは、誰かが（権限を持つユーザーであっても）、このポリシーがアタッチされているバックアップセットのバックアップを削除したり変更したりすることを防ぎます。

アカウントに APPLY BACKUP RETENTION LOCK 権限を持つロールのみが、保持ロック付きのバックアップポリシーを作成できます。

1. 有効期限が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';
   

   Copy

2. テーブル t2 についてバックアップポリシー daily_backup_policy_with_lock を使用するバックアップセットを作成します。

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

   Copy

3. スキーマ s2 についてバックアップポリシー daily_backup_policy_with_lock を使用するバックアップセットを作成します。

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

   Copy

4. データベース d2 についてバックアップポリシー daily_backup_policy_with_lock を使用するバックアップセットを作成します。

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

   Copy

バックアップを手動で作成する¶

バックアップは、いつでもバックアップセットに手動で追加できます。これを実行すると、バックアップセットに関連付けられているデータベース、スキーマ、またはテーブルのバックアップが作成されます。バックアップセットにバックアップポリシーによってスケジュールされたバックアップも含まれているかどうかに関係なく、手動でバックアップを作成できます。バックアップセットに関連付けられたバックアップポリシーがあり、そのポリシーが有効期限を定義している場合、その有効期間は手動バックアップにも適用されます。

次の例では、テーブルバックアップセット t1_backups を作成してから、そこに最初のバックアップを追加します。

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

次の例では、1時間ごとにバックアップするバックアップポリシーと、そのポリシーを使用するテーブルバックアップセット 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;

Copy

バックアップセットの作成プロセスのみ、または有効期限切れプロセスのみを選択的に一時停止することもできます。次の例では、バックアップセット t3_backups の新しいバックアップの作成を一時停止し、バックアップセット t4_backups の古いバックアップの有効期限切れ処理を一時停止します。

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

Copy

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 SUSPEND BACKUP CREATION POLICY;
ALTER BACKUP SET t4_backups SUSPEND BACKUP EXPIRATION POLICY;

ALTER BACKUP SET コマンドの詳細については、 ALTER BACKUP SET をご参照ください。

バックアップを復元する¶

特定のバックアップの ID を使用して、バックアップセットからオブジェクトを復元できます。たとえば、現在のスキーマでテーブル t1 をバックアップセット t1_backups から復元するには、次のステートメントを実行します。

1. 復元するテーブルバックアップの ID を backup_id 列で探します。

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

   Copy

   +-------------------------------+--------------------------------------+-------------------------------+
   | 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 |
   +-------------------------------+--------------------------------------+-----------+-------------------+
   

2. 復元するスキーマバックアップの ID を backup_id 列で探します。

   SHOW BACKUPS IN BACKUP SET s1_backups;
   

   Copy

   +-------------------------------+--------------------------------------+-------------------------------+
   | 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 |
   +-------------------------------+--------------------------------------+-------------------------------+
   

3. 復元するデータベースバックアップの ID を backup_id 列で探します。

   SHOW BACKUPS IN BACKUP SET d1_backups;
   

   Copy

   +-------------------------------+--------------------------------------+-------------------------------+
   | 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 |
   +-------------------------------+--------------------------------------+-------------------------------+
   

4. 2024-08-19 18:12:33に取得されたテーブル t1 のバックアップを復元します。

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

   Copy

5. 2024-08-19 18:12:33に取得されたスキーマ s1 のバックアップを復元します。

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

   Copy

6. 2024-08-19 18:12:33に取得されたデータベース d1 のバックアップを復元します。

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

   Copy

バックアップセットからバックアップを削除する¶

バックアップセットについては、法的保持を持たない最も古いバックアップのみを削除できます。バックアップ ID を指定して実行します。is_under_legal_hold プロパティを調べると、法的保持を持たないバックアップを見つけることができます。created_on プロパティを調べると、最も古いバックアップを見つけることができます。

注釈

保持ロック付きのバックアップポリシーがそのバックアップセットにアタッチされている場合や、その特定のバックアップに法的保持が適用されている場合は、そのバックアップセットからバックアップを削除することはできません。

バックアップセットから削除するバックアップは、セット内の最も古いバックアップである必要があります。

1. 削除するテーブルバックアップの ID を次の出力の backup_id 列から見つけます。created_on 列で昇順に並べ替えると、最も古いバックアップが最初に配置されます。LIMIT 1 を SELECT コマンドに追加すると、バックアップの詳細を含む最も古い行のみが返されます。

   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";
   

   Copy

   +-------------------------------+--------------------------------------+-------------------------------+
   | 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 |
   +-------------------------------+--------------------------------------+-------------------------------+
   

2. 2024-08-19 17:12:28に作成された t1_backups バックアップを、 backup_id を使用して削除します。

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

   Copy

3. 削除するスキーマバックアップの ID を次の出力の backup_id 列から見つけます。

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

   Copy

   +-------------------------------+--------------------------------------+-------------------------------+
   | 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 |
   +-------------------------------+--------------------------------------+-------------------------------+
   

4. 2024-08-19 17:12:28に作成された s1_backups バックアップを、 backup_id を使用して削除します。

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

   Copy

5. 削除するデータベースバックアップの ID を次の出力の backup_id 列から見つけます。

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

   Copy

   +-------------------------------+--------------------------------------+-------------------------------+
   | 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 |
   +-------------------------------+--------------------------------------+-------------------------------+
   

6. 2024-08-19 17:12:28に作成された d1_backups バックアップを、 backup_id を使用して削除します。

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

   Copy

7. 2024-08-19 21:12:55に作成された、より新しい d1_backups バックアップの削除を試行します。Snowflakeがバックアップセット内の最も古いバックアップ以外のバックアップの削除を防ぐ仕組みに注目します。

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

   Copy

   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 コマンドを使用してバックアップセットを削除できます。

t1_backups バックアップセットを削除します。

DROP BACKUP SET t1_backups;

s1_backups バックアップセットを削除します。

DROP BACKUP SET s1_backups;

d1_backups バックアップセットを削除します。

DROP BACKUP SET d1_backups;

特定のテーブルのバックアップを含むすべてのバックアップセットを検索する¶

次の例は、特定のスキーマとデータベース内の特定のテーブルを含むすべてのバックアップセットを検索する方法を示しています。その SHOWTABLES コマンドは、パイプ演算子を使用して、データベース、スキーマ、テーブルの名前を取得し、変数に保存します。その SHOW BACKUP SETS 出力はフィルタリングされ、テーブルを含むデータベース、テーブルを含むスキーマ、またはその単一のテーブル自体をバックアップするバックアップセットを表示します。

フィルタリングされた SHOW BACKUP SETS の出力を見ると、データベース``my_big_important_database`` のデータベースバックアップセットが2つ、スキーマ my_big_important_database.public のスキーマバックアップセットが1つ、およびテーブル my_big_important_database.public.my_small_secondary_table のテーブルバックアップセットが1つあります。

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;

その SHOWBACKUPS 出力には、復元する操作に使用する 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 TABLE OR REPLACE 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.

動的テーブルのバックアップを作成する¶

動的テーブルには常に他のテーブルへの参照があります。そのため、動的テーブルにはスキーマバックアップまたはデータベースバックアップを使用して、元のテーブルと動的テーブルを同じバックアップに含めることができます。

動的テーブルのテーブルバックアップを作成する場合は、 DYNAMIC キーワードを CREATE BACKUP SET コマンドに含め、バックアップから復元するときには CREATE TABLE コマンドにも含めます。次の例では、動的テーブルと、そのテーブルのテーブルバックアップセットを設定し、最初のバックアップを作成します。

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;

次の例は、さまざまな時間に作成されたバックアップのバックアップ IDs を特定する方法を示しています。この場合、最新のバックアップは結果セットの最初の行になります。次に、バックアップの ID を CREATE DYNAMIC TABLE コマンドで使用します。

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>';

法的保持を追加および削除する¶

Snowflakeバックアップの法的保持を扱う前に、その目的と要件について学びます。詳細については、 法的保持 をご参照ください。

組織の法律上またはコンプライアンスチームが、どのようなデータを保持する必要があるかを指定する請求、このデータを使用してデータを提供するとします。その場合は、次のようなプロセスに従うことができますː

• 法務チームと協力して、関連するデータが格納されている場所、および関連オブジェクトが含まれているバックアップセットを特定します。

• バックアップセット内の該当する時間枠のバックアップに法的保持を設定します。そうすると、そのバックアップの自動有効期限処理が無効になります。スケジュールに基づいてSnowflakeが自動的に作成した、または手動で作成したバックアップに法的保持を設定できます。法的保持は、バックアップセットに関連するバックアップポリシー、有効期限、または保持ロックがあるかどうかに関係なく適用されます。

• そのバックアップセットを含むデータベースが複製されているセカンダリアカウントのリフレッシュ操作を実行します。そうすることで、法的保持と関連するバックアップは、フェールオーバーとフェールバックの操作すべてで保持されます。

• Snowflakeのアクセス制御とログを使用して、法的保持にあるデータへのアクセスを監査します。

• 法的ケースが終了し、法的チームが法的保持を削除することを承認すると、APPLYLEGALHOLD 権限を持つユーザーは法的保持をリリースします。その後、期限切れの通常の自動化が再開されます。

この例は、特定のバックアップセット内のバックアップに対する法的保持のライフサイクル中に使用する可能性のある 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;

バックアップ関連オブジェクトを複製する¶

データベース、スキーマ、およびテーブルのバックアップと組み合わせて複製を使用する場合は、複製グループとフェールオーバーグループでバックアップセットとバックアップポリシーを含むデータベースを指定します。複製グループとフェールオーバーグループを整理すること、またバックアップセットとバックアップポリシーを含むデータベースとスキーマを選択することで、バックアップ関連のオブジェクトの複製方法を制御できます。詳細については、 Backup replication for database, schema, and table backups をご参照ください。

バックアップセットとバックアップポリシーはデータベースオブジェクトです。Snowflakeは、バックアップセット、バックアップポリシー、およびそれらを含むデータベースとスキーマを複製します。

Snowflakeは、クローン作成と同様のメカニズムを使用して、バックアップの時間とストレージの使用量を最小限に抑えるため、各バックアップは、すべてのテーブルデータの完全な新しいコピーを必要としません。バックアップセットが、バックアップセットが適用されるデータベース、スキーマ、またはテーブルとは異なるフェールオーバーグループの一部である場合は、その複製グループまたはフェールオーバーグループの最初のリフレッシュ時に、1回限りのデータの完全転送が発生します。

複製グループまたはフェールオーバーグループにバックアップセットが含まれている場合、リフレッシュレイテンシの増加は、最後のリフレッシュ以降に作成されたバックアップの数に比例します。

古いバックアップの有効期限を定義すると、プライマリアカウントで自動削除が行われます。これらの期限切れのバックアップは、リフレッシュ操作を実行すると、セカンダリアカウントから削除されます。

したがって、次のプラクティスに従うと、バックアップ関連オブジェクトの複製を微調整できます。

• リフレッシュ失敗の可能性を最小限に抑えるには、バックアップセットとオプションのバックアップポリシーを同じデータベースとスキーマ内に配置します。それが現実的でない場合は、それらを同じ複製グループまたはフェールオーバーグループに配置します。そうすることで、これらの関連オブジェクトはすべて同時に複製されます。

• 複製されるバックアップ関連オブジェクトと複製スケジュールに関する柔軟性を最大化するには、バックアップセットとオプションのバックアップポリシーを関連するデータベース、スキーマ、またはテーブルとは異なるデータベースに配置します。そうすることで、バックアップ関連オブジェクトを複製するかどうか、およびその頻度を指定できます。

• 古いバックアップに有効期間を持つポリシーを適用する場合は、有効期間を複製のリフレッシュ操作の間隔よりも長くします。このようにすると、新しいすべてのバックアップが、期限切れ前に少なくとも1回、セカンダリアカウントに複製されます。

• 法的保持を追加した後、すぐに、バックアップセットを含むデータベースが複製されているすべてのセカンダリアカウントでリフレッシュ操作を実行します。そうすることで、法的保持と関連するバックアップは、フェールオーバーとフェールバックの操作すべてで保持されます。

• 別の複製グループまたはフェールオーバーグループの一部であるデータベースに、バックアップポリシーと関連するバックアップセットを配置したとします。その場合は、バックアップポリシーを含むグループの初期リフレッシュを最初に実行してください。そうしないと、セカンダリアカウントに関連するバックアップポリシーがないバックアップセットを作成できないために、リフレッシュ操作は失敗します。

  注釈

  バックアップセットをバックアップセットのオブジェクトとは異なる複製グループまたはフェールオーバーグループに配置すると、バックアップセットを含むグループの最初のリフレッシュ時に、すべてのデータの完全転送が必要になります。

  セカンダリアカウントでスキーマバックアップまたはデータベースバックアップを復元する場合は、参照されるオブジェクトがバックアップと同じフェールオーバーグループに属している場合を除き、復元されたスキーマまたはデータベース内のオブジェクト参照が正しく解決されない可能性があります。

バックアップおよびバックアップ操作を監視する¶

次のビューをクエリすると、存在するバックアップ関連オブジェクト、それらのプロパティ、およびストレージの使用量を判断できます。

情報スキーマ：

• BACKUP_POLICIES ビュー

• BACKUP_SETS ビュー

• BACKUPS ビュー

アカウント使用状況：

• BACKUP_OPERATION_HISTORY ビュー

• BACKUP_POLICIES ビュー

• BACKUP_SETS ビュー

• BACKUP_STORAGE_USAGE ビュー

• BACKUPS ビュー

組織の使用状況：

• BACKUP_OPERATION_HISTORY ビュー

• BACKUP_POLICIES ビュー

• BACKUP_SETS ビュー

• BACKUPS ビュー

バックアップポリシー¶

• CREATE BACKUP POLICY

• ALTER BACKUP POLICY

• DROP BACKUP POLICY

• SHOW BACKUP POLICIES

バックアップセット¶

• CREATE BACKUP SET

• ALTER BACKUP SET

• DROP BACKUP SET

• SHOW BACKUP SETS

バックアップ¶

実際の CREATEBACKUP コマンドを実行するわけではありません。新しいバックアップを作成するには、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 SCHEMAFROM BACKUPSET

• CREATE TABLE FROM BACKUP SET

ビュー¶

次のシステムビューには、バックアップ、バックアップセット、およびバックアップポリシーに関連するメタデータが含まれています。