Backups für die Notfallwiederherstellung und unveränderlichen Speicher¶

Backup¶

Ein Backup ist eine zeitpunktbezogener Snapshot eines Objekts.

• Das Objekt kann eine einzelne Tabelle, ein Schema oder eine ganze Datenbank sein.

• Ein bestimmtes Backup kann durch eine eindeutige ID identifiziert werden, die von Snowflake generiert wurde.

• Ein Backup kann nicht geändert werden. Es kann jedoch gelöscht werden, und der Ablaufzeitraum des Backups kann geändert werden (es sei denn, es wird eine Aufbewahrungssperre angewendet).

Im täglichen Betrieb interagieren Sie selten mit einzelnen Backups. Stattdessen verwalten Sie die Backup-Sets, die sie enthalten. Sie erhalten zum Beispiel eine Liste der Backups, indem Sie den Befehl SHOW BACKUPS IN BACKUP SET ausführen. Sie erstellen ein neues Backup, indem Sie einen ALTER BACKUP SET-Befehl ausführen.

Backup-Set¶

Ein Backup-Set ist ein Objekt auf Schemaebene, das einen Satz von Backups für eine bestimmte Datenbank, ein bestimmtes Schema oder eine bestimmte Tabelle enthält. Snowflake verfügt über SQL-Befehle zum CREATE, ALTER, DROP, SHOW und DESCRIBE von Backup-Sets.

Sie können mehrere Backup-Sets für dasselbe Objekt haben.

Der Lebenszyklus der Backups innerhalb eines Sets wird durch eine optionale Backup-Richtlinie bestimmt, die Sie an das Backup-Set anhängen können. Sie können Backups auch manuell zu einem Backup-Set hinzufügen oder daraus löschen. Ihre Möglichkeit, Backups zu löschen, wird durch andere Faktoren beeinflusst, insbesondere durch die Aufbewahrungssperre und gesetzliche Aufbewahrungsfrist.

Backup-Richtlinie¶

Eine Backup-Richtlinie ist ein Objekt auf Schemaebene, das die Einstellungen enthält, die den Lebenszyklus der Backups innerhalb eines Backup-Sets definieren. Zu diesen Einstellungen gehören Zeitplan, Ablauf und Aufbewahrungssperre.

• Der Zeitplan bestimmt, wann Backups erstellt werden. Der Zeitplan kann als Intervall in Minuten oder als Cron-Ausdruck definiert werden. Wenn der Zeitplan beispielsweise auf eine Stunde eingestellt ist, wird alle 60 Minuten ein Backup des Objekts erstellt.

• Die Ablaufzeit ist die Zeitspanne, für die das Backup gültig ist. Nach Ablauf eines Backups löscht Snowflake es automatisch, es sei denn, für dieses Backup gilt eine gesetzliche Aufbewahrungsfrist.

  Tipp

  Wenn für das Backup-Set keine Aufbewahrungssperre gilt und für das jeweilige Backup keine rechtlichen Aufbewahrungsfristen gelten, können Sie das Backup vor dem Ende der Ablaufzeit manuell löschen. Sie können Backups nacheinander manuell löschen, immer beginnend mit dem ältesten Backup, für das keine gesetzliche Aufbewahrungsfrist gilt.

Jede Backup-Richtlinie muss eine oder beide Eigenschaften des Zeitplans und des Ablaufzeitraums haben. Sie können zum Beispiel eine Richtlinie mit einem Zeitplan und einer Ablauffrist erstellen und Snowflake das Erstellen und Entfernen der Backups in allen Backup-Sets überlassen, auf die diese Richtlinie angewendet wird. Alternativ können Sie eine Richtlinie mit einem Zeitplan und ohne Ablauffrist erstellen, wenn Sie das Entfernen älterer Backups selbst verwalten möchten. Sie können aber auch eine Richtlinie mit einer Ablauffrist, aber ohne Zeitplan erstellen und dann die Erstellung von Backups selbst verwalten. Sie können keine Richtlinie ohne Zeitplan und ohne Ablauffrist erstellen.

Wenn Sie eine Backup-Richtlinie mit einem Backup-Set verknüpfen, können Sie dies tun, wenn Sie das Backup-Set erstellen. Sie können die Richtlinie auch später anwenden. Sie können ebenfalls ein Backup-Set haben, das keine zugehörige Backup-Richtlinie hat. In diesem Fall steuern Sie manuell, wann neue Backups erstellt werden und alte Backups ablaufen.

Sie können eine Backup-Richtlinie auf mehrere Backup-Sets anwenden. Wenn Sie eine Backup-Richtlinie ändern, wendet Snowflake die Änderungen auf alle Backup-Sets an, mit denen die Richtlinie verknüpft ist.

Aufbewahrungssperre¶

Eine Aufbewahrungssperre schützt ein Backup für die definierte Ablauffrist vor dem Löschen. Sie können ein Backup mit einer Aufbewahrungssperre für Backups zur Einhaltung gesetzlicher Bestimmungen und zur Cyber-Ausfallsicherheit verwenden. Die folgenden Einschränkungen gelten für ein Backup-Set mit Aufbewahrungssperre:

• Backups können von keiner Rolle gelöscht werden, auch nicht von der ACCOUNTADMIN-Rolle.

• Sie können die Ablauffrist des Backups nicht verkürzen, aber Sie können die Ablauffrist verlängern.

• Sie können ein Backup-Set nicht löschen, wenn noch nicht abgelaufene Backups im Set vorhanden sind.

• Sie können ein Schema, das ein Backup-Set mit nicht abgelaufenen Backups enthält, nicht löschen.

• Sie können eine Datenbank, die ein Backup-Set mit nicht abgelaufenen Backups enthält, nicht löschen.

• Sie können ein Konto, das eine Datenbank mit einem Backup-Set enthält, in dem noch nicht abgelaufene Backups vorhanden sind, nicht löschen.

Gesetzliche Aufbewahrungsfrist¶

Das Feature Gesetzliche Aufbewahrungsfrist von Snowflake-Backups verhindert, dass Backups überschrieben oder gelöscht werden. Auf diese Weise können Sie Snowflake-Datenbanken, -Schemas oder -Tabellen auf der Grundlage Ihrer eigenen rechtlichen Anforderungen erhalten.

Mit Snowflake können Sie für bestimmte Backups eine gesetzliche Aufbewahrungsfrist festlegen. Wenn ein Snowflake-Backup unter gesetzliche Aufbewahrungsfristen fällt, gelten die folgenden Bedingungen:

• Niemand kann das Backup ändern.

• Niemand kann das Backup löschen. Das gilt auch dann, wenn die Frist EXPIRE_AFTER_DAYS des Backups abgelaufen ist.

• Der Zugriff auf das Backup wird protokolliert und ist überprüfbar.

• Die gesetzliche Aufbewahrungsfrist kann im Gegensatz zu einer Aufbewahrungssperre von einem berechtigten Benutzer entfernt werden.

Übersicht zum Backup-Lebenszyklus¶

Das folgende Diagramm zeigt, wie die Snowflake-Objekte, Backups, Backup-Sets und Backup-Richtlinien miteinander in Beziehung stehen. Das Diagramm enthält die einfachste Art von Backup: ein Backup für eine einzelne Tabelle. Jeder Backup-Vorgang erstellt ein neues Backup. Alle Backups für dieses bestimmte Objekt sind in einem Backup-Set zusammengefasst. Das automatische Hinzufügen und Entfernen von Backups im Backup-Set wird von der Backup-Richtlinie geregelt. Um die Informationen aus einem Backup wiederherzustellen, verwenden Sie einen CREATE-Befehl, um ein neues Objekt aus einem bestimmten Backup zu erstellen.

Einschränkungen für Backups¶

Sie können maximal zwei Datenbank-Backup-Sets für eine bestimmte Datenbank erstellen. Ebenso können Sie maximal zwei Schema-Backup-Sets für ein bestimmtes Schema und zwei Tabellen-Backup-Sets für eine bestimmte Tabelle erstellen. Ein Objekt kann immer noch in mehr als zwei Backup-Sets vorkommen. Eine Tabelle kann zum Beispiel ein oder zwei zugeordnete Tabellen-Backup-Sets haben. Dieselbe Tabelle kann auch in einem oder zwei Schema-Backup-Sets und einem oder zwei Datenbank-Backup-Sets enthalten sein.

Referenzen von Tabellen auf andere Objekte¶

Objekte, wie z. B. Ansichten oder Funktionen, können im Backup auf Objekte außerhalb des Schemas oder der Datenbank verweisen. Um sicherzustellen, dass solche Referenzen nach der Wiederherstellung aus einem Backup weiterhin funktionieren, verwenden Sie eine der folgenden Strategien:

• Wenn sich die Tabellen und die anderen Objekte, auf die sie verweisen, alle in demselben Schema oder derselben Datenbank befinden, erstellen Sie ein Backup-Set für das gesamte Schema oder die gesamte Datenbank. Auf diese Weise stellt Snowflake alle verbundenen Objekte auf einmal wieder her, wenn Sie aus dem Backup wiederherstellen.

• Wenn Objekte in einem Backup-Set auf Objekte verweisen, die nicht im Backup-Set enthalten sind, sollten Sie beachten, dass bei Wiederherstellung eines Backups die Referenzen von den wiederhergestellten Objekten auf die ursprünglichen Objekte aus der anderen Datenbank oder dem anderen Schema verweisen. Wenn Sie diese anderen Objekte nach der Erstellung des Backups gelöscht oder deren Eigenschaften geändert haben, können beim Zugriff auf die wiederhergestellten Objekte Fehler auftreten.

• Bei Objekten auf Kontoebene verweisen alle Referenzen von wiederhergestellten Objekten immer auf das ursprüngliche Objekt auf Kontoebene. Das liegt daran, dass die Objekte auf Kontoebene nicht Teil eines Backups sind. Ein Schema-Backup könnte zum Beispiel ein Geheimnis enthalten, das auf eine Sicherheitsintegration verweist. Die Sicherheitsintegration ist ein Objekt auf Kontoebene und kann nicht in ein Backup aufgenommen werden.

Objekttypen in Datenbank- und Schema-Backups¶

In der folgenden Tabelle sind die Objekte aufgeführt, die in einem Datenbank- oder Schema-Backup enthalten sind:

Wie Snowflake Objekte mit den dazugehörigen Backup-Sets verknüpft¶

Wenn Sie ein Backup-Set für eine Datenbank, ein Schema oder eine Tabelle erstellen, verknüpft Snowflake das Backup-Set mit der internen ID dieser Datenbank, dieses Schemas oder dieser Tabelle. Wenn Sie das ursprüngliche Objekt löschen, können Sie diesem Backup-Set keine weiteren Backups hinzufügen. Dieses Verhalten gilt auch dann, wenn Sie ein Objekt mit demselben Namen neu erstellen oder es durch ein Objekt ersetzen, das aus einem Backup wiederhergestellt wurde.

Wenn Sie stattdessen das ursprüngliche Objekt umbenennen, können Sie weitere Backups davon erstellen, indem Sie weitere Backups zum selben Backup-Set hinzufügen. In diesem Fall ändert sich die Ausgabe von SHOW BACKUP SETS, um den OBJECT_NAME-Wert des umbenannten Objekts zu berücksichtigen.

Wenn Sie Backups einer Tabelle erstellen möchten, diese Tabelle aber häufig löschen und neu erstellen, z. B. über CREATE OR REPLACE-Anweisungen, nehmen Sie sie in ein Backup-Set für das Schema oder die Datenbank auf, die die Tabelle enthält. Auf diese Weise können Sie unabhängig von den Änderungen an der Tabelle weiterhin dasselbe Backup-Set verwenden.

Wenn Sie eine Tabelle aus einem Backup wiederherstellen, beginnt die wiederhergestellte Tabelle mit einem anderen Namen als die ursprüngliche Tabelle. Angenommen, Sie möchten den Inhalt der ursprünglichen Tabelle vollständig durch die Backup-Daten ersetzen und weiterhin dasselbe Backup-Set für weitere Backups derselben Tabelle verwenden. Verwenden Sie in diesem Fall die Anweisung TRUNCATE oder DELETE zum Entfernen des Inhalts der ursprünglichen Tabelle sowie die Anweisung INSERT … SELECT zum Kopieren der Daten aus der wiederhergestellten Tabelle. Löschen Sie nicht die ursprüngliche Tabelle, und benennen Sie die wiederhergestellte Tabelle nicht in den Namen der ursprünglichen Tabelle um.

Backups und Verschlüsselung¶

Die Daten in Backup-Sets sind durch dieselbe End-to-End-Verschlüsselung geschützt wie andere Snowflake-Objekte und -Tabellendaten. Weitere Informationen zur Snowflake-Verschlüsselung finden Sie unter Erläuterungen zur End-to-End-Verschlüsselung in Snowflake.

Die Schlüsselrotation gilt auch für die Daten in Backups.

Backups und Datenherkunft¶

Snowflake behält nicht die Datenherkunft-Metadaten bei Datenbank-, Schema- und Tabellen-Backups bei. Nachdem Sie ein Objekt aus einem Backup wiederhergestellt haben, können Sie Snowsight nicht mehr verwenden, um Herkunftsinformationen für die wiederhergestellten Daten anzuzeigen.

Erforderliche Berechtigungen erteilen, um Backup-Richtlinien und -Sets zu erstellen¶

Zum Aktivieren der Rolle myrole, um eine Backup-Richtlinie im Schema myschema zu erstellen, führen Sie die folgende Anweisung aus:

GRANT CREATE BACKUP POLICY ON SCHEMA policy_schema TO ROLE myrole;

Zum Aktivieren der Rolle myrole, um ein Backup-Set im Schema myschema zu erstellen, führen Sie die folgende Anweisung aus:

GRANT CREATE BACKUP SET ON SCHEMA policy_schema TO ROLE myrole;

Einer Rolle die APPLY-Berechtigung für eine Backup-Richtlinie erteilen¶

Zum Aktivieren der Rolle myrole, um die Backup-Richtlinie hourly_backup_policy auf ein Backup-Set anzuwenden, führen Sie die folgende Anweisung aus:

GRANT APPLY ON BACKUP POLICY hourly_backup_policy TO ROLE myrole;

Einer Rolle die Berechtigung APPLY BACKUP RETENTION LOCK erteilen¶

Sie können einer Rolle die Berechtigung erteilen, Backup-Richtlinien mit einer Aufbewahrungssperre auf Backup-Sets anzuwenden.

Nur ein Benutzer mit der ACCOUNTADMIN-Rolle kann diese Berechtigung erteilen.

Zum Aktivieren der Rolle retention_lock_admin_role, um eine Backup-Richtlinie mit einer Aufbewahrungssperre auf ein Backup-Set anzuwenden, führen Sie die folgende Anweisung aus:

GRANT APPLY BACKUP RETENTION LOCK ON ACCOUNT TO ROLE retention_lock_admin_role;

Geplante Backups mit einer Aufbewahrungssperre erstellen¶

Erstellen Sie ein Backup-Set, das automatisch Backups mit einer Aufbewahrungssperre nach einem Zeitplan erstellt. Die Aufbewahrungssperre verhindert, dass Benutzende, also auch berechtigte Benutzende, Backups in einem Backup-Set löschen oder ändern können, mit dem die Richtlinie verknüpft ist.

Nur eine Rolle, die die Berechtigung APPLY BACKUP RETENTION LOCK für das Konto hat, kann eine Backup-Richtlinie mit einer Aufbewahrungssperre erstellen.

1. Erstellen Sie eine Richtlinie mit einer Aufbewahrungssperre, die ein tägliches Backup mit einem Ablaufzeitraum von 90 Tagen erstellt:

   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. Erstellen Sie ein Backup-Set für Tabelle t2 mit der Backup-Richtlinie daily_backup_policy_with_lock:

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

   Copy

3. Erstellen Sie ein Backup-Set für das Schema s2 mit der Backup-Richtlinie daily_backup_policy_with_lock:

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

   Copy

4. Erstellen Sie ein Backup-Set für die Datenbank d2 mit der Backup-Richtlinie daily_backup_policy_with_lock:

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

   Copy

Backups manuell erstellen¶

Sie können ein Backup jederzeit manuell zu einem Backup-Set hinzufügen. Dadurch wird ein Backup der Datenbank, des Schemas oder der Tabelle erstellt, die mit dem Backup-Set verknüpft ist. Sie können Backups manuell erstellen, unabhängig davon, ob das Backup-Set auch Backups enthält, die durch eine Backup-Richtlinie geplant sind. Wenn mit dem Backup-Set eine Backup-Richtlinie verknüpft ist und die Richtlinie einen Ablaufzeitraum definiert, gilt dieser Ablaufzeitraum auch für das manuelle Backup.

Im folgenden Beispiel wird ein Tabellen-Backup-Set t1_backups erstellt und anschließend das erste Backup hinzugefügt:

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

Das folgende Beispiel erstellt eine Backup-Richtlinie mit stündlichen Backups, ein Tabellen-Backup-Set t2_backups, das die Richtlinie verwendet, und fügt anschließend ein manuelles Backup zum Backup-Set hinzu:

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;

Sie können ähnliche Befehle ausführen, um ein Backup zu einem Schema- oder Datenbank-Backup-Set hinzuzufügen. Ersetzen Sie den Namen des Schema- oder Datenbank-Backups, das im Befehl ALTER BACKUP SET festgelegt wurde.

Backup-Richtlinien für Backup-Sets aussetzen¶

Wenn Sie eine Backup-Richtlinie für ein Backup-Set aussetzen, verhindern Sie, dass die Backup-Richtlinie verwendet wird, um neue geplante Backups in diesem Backup-Set zu erstellen. Sie setzen auch den Ablauf von vorhandenen Backups in diesem Backup-Set aus, die die Backup-Richtlinie verwenden. Andere Backup-Sets, die dieselbe Richtlinie verwenden, sind davon nicht betroffen.

Im folgenden Beispiel wird eine Backup-Richtlinie für das Backup-Set t2_backups ausgesetzt:

ALTER BACKUP SET t2_backups SUSPEND BACKUP POLICY;

Copy

Sie können auch selektiv nur die Erstellung oder nur die Ablaufvorgänge des Backup-Sets aussetzen. Im folgenden Beispiel wird das Erstellen neuer Backups im Backup-Set t3_backups ausgesetzt, und das Ablaufen alter Backups aus dem Backup-Set t4_backups wird ebenfalls ausgesetzt:

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

Copy

Weitere Informationen über den Befehl ALTER BACKUP SET finden Sie unter ALTER BACKUP SET.

Backup-Richtlinien für Backup-Sets fortsetzen¶

Sie können ausgesetzte Backup-Richtlinien fortsetzen. Dadurch werden die Erstellung und der Ablauf von Backups gemäß der Backup-Richtlinie fortgesetzt. Wenn ein Backup das Ablaufdatum erreicht hat, während die Richtlinie ausgesetzt war, löscht Snowflake diese Backups, sobald die Richtlinie fortgesetzt wird.

Das folgende Beispiel setzt eine Backup-Richtlinie für das Backup-Set t1_backup fort:

ALTER BACKUP SET t1_backups
  RESUME BACKUP POLICY;

Sie können auch selektiv nur die Erstellung oder nur den Ablaufvorgang des Backup-Sets fortsetzen. Im folgenden Beispiel wird das Erstellen neuer Backups im Backup-Set t3_backups fortgesetzt, und das Ablaufen alter Backups aus dem Backup-Set t4_backups wird ebenfalls fortgesetzt:

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

Weitere Informationen über den Befehl ALTER BACKUP SET finden Sie unter ALTER BACKUP SET.

Backups wiederherstellen¶

Sie können ein Objekt aus einem Backup-Set wiederherstellen, indem Sie die ID des jeweiligen Backups verwenden. Um beispielsweise die Tabellen-t1 aus dem Backup-Set t1_backups im aktuellen Schema wiederherzustellen, führen Sie die folgenden Anweisungen aus:

1. Suchen Sie die ID des Tabellen-Backups, das wiederhergestellt werden soll, in der Spalte 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. Suchen Sie die ID des Schema-Backups, das wiederhergestellt werden soll, in der Spalte 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. Suchen Sie die ID des Datenbank-Backups, das wiederhergestellt werden soll, in der Spalte 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. Backup für die Tabelle t1, das am 19.08.2024 um 18:12:33 erstellt wurde, wiederherstellen:

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

   Copy

5. Backup für das Schema s1, das am 19.08.2024 um 18:12:33 erstellt wurde, wiederherstellen:

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

   Copy

6. Backup für die Datenbank d1, das am 19.08.2024 um 18:12:33 erstellt wurde, wiederherstellen:

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

   Copy

Backups aus Backup-Sets löschen¶

Bei jedem Backup-Set können Sie nur das älteste Backup löschen, für das es keine gesetzliche Aufbewahrungsfrist gibt. Dazu geben Sie die Backup-ID an. Sie können die Backups suchen, die keine gesetzliche Aufbewahrungsfrist haben, indem Sie die is_under_legal_hold-Eigenschaft überprüfen. Sie können das älteste Backup suchen, indem Sie die created_on-Eigenschaft überprüfen.

Bemerkung

Sie können kein Backup aus einem Backup-Set löschen, wenn eine Backup-Richtlinie mit einer Aufbewahrungssperre mit diesem Backup-Set verknüpft ist oder wenn auf dieses Backup eine gesetzliche Aufbewahrungsfrist angewendet wird.

Das Backup, das Sie aus dem Backup-Set löschen, muss das früheste Backup im Set sein.

1. Suchen Sie die ID des zu löschenden Tabellen-Backups in der folgenden Ausgabe in der Spalte backup_id. Durch die Sortierung in aufsteigender Reihenfolge in der Spalte created_on wird das älteste Backup an die erste Stelle gesetzt. Sie könnten LIMIT 1 zum SELECT-Befehl hinzufügen, um nur die Zeile mit den Details des ältesten Backups zurückzugeben.

   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. Löschen Sie das Backup t1_backups, erstellt am 19.08.2024 17:12:28, anhand der``backup_id``:

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

   Copy

3. Suchen Sie die ID des zu löschenden Schema-Backups in der folgenden Ausgabe in der Spalte 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. Löschen Sie das Backup s1_backups, erstellt am 19.08.2024 17:12:28, anhand der``backup_id``:

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

   Copy

5. Suchen Sie die ID des zu löschenden Datenbank-Backups in der folgenden Ausgabe in der Spalte 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. Löschen Sie das Backup d1_backups, erstellt am 19.08.2024 17:12:28, anhand der``backup_id``:

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

   Copy

7. Versuchen Sie, ein neueres d1_backups-Backup zu löschen, das am 19.08.2024 um 21:12:55 erstellt wurde. Beachten Sie, wie Snowflake verhindert, dass Sie ein Backup löschen, das nicht das älteste im Backup-Set ist.

   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.
   

Backup-Sets löschen¶

Sie können ein Backup-Set mit dem Befehl DROP BACKUP SET löschen.

Löschen Sie das Backup-Set t1_backups:

DROP BACKUP SET t1_backups;

Löschen Sie das Backup-Set s1_backups:

DROP BACKUP SET s1_backups;

Löschen Sie das Backup-Set d1_backups:

DROP BACKUP SET d1_backups;

Alle Backup-Sets suchen, die Backups einer bestimmten Tabelle enthalten¶

Das folgende Beispiel zeigt, wie Sie alle Backup-Sets suchen, die eine bestimmte Tabelle innerhalb eines bestimmten Schemas und einer bestimmten Datenbank enthalten. Der Befehl SHOW TABLES verwendet einen Pipe-Operator, um die Namen von Datenbank, Schema und Tabelle abzurufen und sie in Variablen zu speichern. Die Ausgabe von SHOW BACKUP SETS wird gefiltert, um die Backup-Sets anzuzeigen, die die Datenbank sichern, welche die Tabelle enthält, oder das Schema, das die Tabelle enthält, oder die diese einzelne Tabelle enthält.

Die gefilterte Ausgabe von SHOW BACKUP SETS zeigt, dass es zwei Datenbank-Backup-Sets für die Datenbank my_big_important_database, ein Schema-Backup-Set für das Schema my_big_important_database.public und ein Tabellen-Backup-Set für die Tabelle my_big_important_database.public.my_small_secondary_table gibt.

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

Backups für Tabellen mit Abhängigkeiten erstellen¶

Die folgenden Beispiele zeigen, wie Sie ein Tabellen-Backup für eine Tabelle erstellen können, die auf eine Sequenz und einen Fremdschlüssel in einem anderen Schema verweist. Zur Vorbereitung erstellen wir das Schema other_schema, das eine Sequenz und eine Tabelle enthält. Dann wird im Schema public die Haupttabelle erstellt, die sich auf die Sequenz und die andere Tabelle bezieht.

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

Die Ausgabe GET_DDL () zeigt die Referenzen an, die auf das andere Schema verweisen:

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

Als Nächstes erstellen wir das Backup-Set für die Tabelle und fügen ein Backup hinzu:

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

Die Ausgabe SHOW BACKUPS enthält den backup_id-Wert, der für die Wiederherstellungsoperation verwendet werden soll:

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

Wir stellen diese Tabelle unter einem neuen Namen wieder her und bestätigen, dass die wiederhergestellte Tabelle auf die Objekte im anderen Schema verweist:

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

Um zu veranschaulichen, was passiert, wenn das referenzierte Objekt nicht mehr existiert, löschen wir die Sequenz und stellen dann die Tabelle aus demselben Backup wieder her:

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;

Das Abfragen der Tabelle funktioniert immer noch:

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

Allerdings schlagen Vorgänge wie GET_DDL(), DESCRIBE und INSERT fehl, weil sie von einer Sequenz abhängen, die nicht mehr existiert:

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.

Backups für dynamische Tabellen erstellen¶

Eine dynamische Tabelle enthält immer einen Verweis auf eine andere Tabelle. Aus diesem Grund können Sie es vorziehen, für dynamische Tabellen Schema-Backups oder Datenbank-Backups zu verwenden, sodass die ursprüngliche Tabelle und die dynamische Tabelle in demselben Backup enthalten sein können.

Wenn Sie ein Tabellen-Backup für eine dynamische Tabelle erstellen, fügen Sie das Schlüsselwort DYNAMIC in den Befehl CREATE BACKUP SET und in den Befehl CREATE TABLE ein, wenn Sie von einem Backup wiederherstellen. Im folgenden Beispiel wird die dynamische Tabelle sowie ein Tabellen-Backup-Set für diese Tabelle eingerichtet und das erste Backup erstellt:

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;

Das folgende Beispiel zeigt, wie Sie die Backup-IDs für Backups ermitteln, die zu verschiedenen Zeitpunkten erstellt wurden. In diesem Fall ist das neueste Backup die erste Zeile im Resultset. Dann verwenden Sie die ID des Backups im Befehl 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>';

Gesetzliche Aufbewahrungsfristen hinzufügen und entfernen¶

Bevor Sie mit gesetzlichen Aufbewahrungsfristen für Snowflake-Backups arbeiten, sollten Sie sich über den Zweck und die Anforderungen informieren. Weitere Informationen dazu finden Sie unter Gesetzliche Aufbewahrungsfrist.

Angenommen, die Rechtsabteilung oder das Compliance-Team Ihrer Organisation sendet eine Anforderung zur Aufbewahrungsfrist, in der angegeben wird, welche Datentypen aufbewahrt werden müssen. In diesem Fall könnten Sie einem Prozess wie folgt folgen:

• Sie arbeiten mit der Rechtsabteilung zusammen, um herauszufinden, wo die relevanten Daten gespeichert sind und welche Backup-Sets die zugehörigen Objekte enthalten.

• Sie legen für ein Backup aus dem entsprechenden Zeitrahmen in einem Backup-Set eine gesetzliche Aufbewahrungsfrist fest. Dadurch wird das automatische Ablaufen dieses Backups deaktiviert. Sie können für ein Backup, das Snowflake automatisch auf der Grundlage eines Zeitplans erstellt hat oder das Sie manuell erstellt haben, eine gesetzliche Aufbewahrungsfrist festlegen. Die gesetzliche Aufbewahrungsfrist gilt unabhängig davon, ob für das Backup-Set eine verknüpfte Backup-Richtlinie, ein Ablaufzeitraum oder eine Aufbewahrungssperre vorhanden ist.

• Sie führen Aktualisierungsvorgänge für alle sekundären Konten durch, in die die Datenbank, die das Backup-Set enthält, repliziert ist. Auf diese Weise bleiben die gesetzliche Aufbewahrungsfrist und das zugehörige Backup bei allen Failover- und Failback-Vorgängen erhalten.

• Sie verwenden die Zugriffssteuerung und Protokolle von Snowflake, um den Zugriff auf die Daten zu prüfen, die unter die gesetzliche Aufbewahrungsfrist fallen.

• Sobald der Fall abgeschlossen ist und die Rechtsabteilung die Entfernung der gesetzlichen Aufbewahrungsfrist genehmigt hat, gibt ein Benutzer mit der Berechtigung APPLY LEGAL HOLD die gesetzliche Aufbewahrungsfrist frei. Dann wird die normale Automatisierung für das Ablaufen fortgesetzt.

Dieses Beispiel zeigt die Sequenz von SQL-Befehlen, die Sie während des Lebenszyklus einer gesetzlichen Aufbewahrungsfrist für ein Backup innerhalb eines bestimmten Backup-Sets verwenden können. Sie finden den Bezeichner des entsprechenden Backups durch Verwendung des Befehls SHOW BACKUPS IN BACKUP SET und Überprüfung der Spalte "is_under_legal_hold", um zu sehen, ob bereits eine gesetzliche Aufbewahrungsfrist vorhanden ist. Dann fügen Sie die gesetzliche Aufbewahrungsfrist zum spezifischen Backup hinzu oder entfernen sie.

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-bezogene Objekte replizieren¶

Wenn Sie die Replikation in Kombination mit Datenbank-, Schema- und Tabellen-Backups verwenden, geben Sie in Ihren Replikationsgruppen und Failover-Gruppen die Datenbanken an, die die Backup-Sets und Backup-Richtlinien enthalten. Sie können steuern, wie Ihre Backup-bezogenen Objekte repliziert werden, indem Sie Ihre Replikationsgruppen und Failover-Gruppen organisieren und auswählen, welche Datenbanken und Schemas Ihre Backup-Sets und Backup-Richtlinien enthalten. Weitere Informationen dazu finden Sie unter Backup replication for database, schema, and table backups.

Die Backup-Sets und Backup-Richtlinien sind Datenbankobjekte. Snowflake repliziert die Backup-Sets und Backup-Richtlinien zusammen mit den Datenbanken und Schemas, die sie enthalten.

Snowflake minimiert den Zeit- und Speicherverbrauch von Backups durch einen Mechanismus ähnlich dem Klonen, sodass nicht für jedes Backup eine komplett neue Kopie aller Tabellendaten erforderlich ist. Wenn das Backup-Set Teil einer anderen Failover-Gruppe ist als die Datenbank, das Schema oder die Tabelle, für die das Backup-Set gilt, erfolgt einmalig eine vollständige Übertragung der Daten bei der ersten Aktualisierung dieser Replikations- oder Failover-Gruppe.

Wenn eine Replikationsgruppe oder Failover-Gruppe ein Backup-Set enthält, erhöht sich die Aktualisierungslatenz proportional zur Anzahl der Backups, die seit der letzten Aktualisierung erstellt wurden.

Wenn Sie einen Ablaufzeitraum für ältere Backups definieren, erfolgt die automatische Löschung auf dem primären Konto. Diese abgelaufenen Backups werden aus dem zweiten Konto entfernt, wenn Sie einen Aktualisierungsvorgang ausführen.

Daher können Sie die Replikation für Backup-bezogene Objekte genauer abstimmen, indem Sie folgende Praktiken ausführen:

• Um die Wahrscheinlichkeit von Aktualisierungsfehlern zu minimieren, speichern Sie das Backup-Set und die optionale Backup-Richtlinie in derselben Datenbank und demselben Schema. Wenn das nicht praktisch ist, legen Sie diese Dinge in dieselbe Replikationsgruppe oder Failover-Gruppe. Auf diese Weise werden alle verwandten Objekte gleichzeitig repliziert.

• Um die Flexibilität bei der Replikation von Backup-bezogenen Objekten und beim Replikationsplan zu maximieren, speichern Sie das Backup-Set und die optionale Backup-Richtlinie in einer anderen Datenbank als der zugehörigen Datenbank, dem zugehörigen Schema oder der zugehörigen Tabelle. Auf diese Weise können Sie festlegen, ob und wie oft die Backup-bezogenen Objekte repliziert werden sollen.

• Wenn Sie eine Richtlinie mit einem Ablaufzeitraum für ältere Backups anwenden, wählen Sie einen Ablaufzeitraum länger als das Intervall zwischen den Aktualisierungsvorgängen der Replikation aus. Auf diese Weise wird jedes neue Backup vor Ablauf mindestens einmal auf das zweite Konto repliziert.

• Führen Sie unmittelbar nach dem Hinzufügen einer gesetzlichen Aufbewahrungsfrist Aktualisierungsvorgänge für alle Sekundärkonten durch, in die die Datenbank, die das Backup-Set enthält, repliziert wird. Auf diese Weise bleiben die gesetzliche Aufbewahrungsfrist und das zugehörige Backup bei allen Failover- und Failback-Vorgängen erhalten.

• Angenommen, Sie setzen eine Backup-Richtlinie und ein zugehöriges Backup-Set in Datenbanken, die Teil verschiedener Replikationsgruppen oder Failover-Gruppen sind. Stellen Sie in diesem Fall sicher, dass Sie die erste Aktualisierung zuerst in der Gruppe durchführen, die die Backup-Richtlinie enthält. Andernfalls schlägt der Aktualisierungsvorgang fehl, weil Sie kein Backup-Set erstellen können, dem die zugehörige Backup-Richtlinie im Sekundärkonto fehlt.

  Bemerkung

  Wenn Sie das Backup-Set in eine andere Replikations- oder Failover-Gruppe als das Objekt des Backup-Sets setzen möchten, müssen Sie bei der ersten Aktualisierung der Gruppe, die das Backup-Set enthält, alle Daten vollständig übertragen.

  Wenn Sie ein Schema-Backup oder ein Datenbank-Backup in einem sekundären Konto wiederherstellen, werden Verweise auf Objekte innerhalb des wiederhergestellten Schemas oder der wiederhergestellten Datenbank möglicherweise nicht ordnungsgemäß aufgelöst, es sei denn, die referenzierten Objekte sind Teil derselben Failover-Gruppe wie das Backup.

Backups und Backup-Vorgänge überwachen¶

Sie können festlegen, welche Backup-bezogenen Objekte vorhanden sind, welche Eigenschaften sie haben und wie viel Speicherplatz sie verbrauchen, indem Sie die folgenden Ansichten abfragen.

Informationsschema:

• Ansicht BACKUP_POLICIES

• Ansicht BACKUP_SETS

• Ansicht BACKUPS

Kontonutzung:

• Ansicht BACKUP_OPERATION_HISTORY

• Ansicht BACKUP_POLICIES

• Ansicht BACKUP_SETS

• Ansicht BACKUP_STORAGE_USAGE

• Ansicht BACKUPS

Organisationsnutzung:

• Ansicht BACKUP_OPERATION_HISTORY

• Ansicht BACKUP_POLICIES

• Ansicht BACKUP_SETS

• Ansicht BACKUPS

Backup-Richtlinie¶

• CREATE BACKUP POLICY

• ALTER BACKUP POLICY

• DROP BACKUP POLICY

• SHOW BACKUP POLICIES

Backup-Set¶

• CREATE BACKUP SET

• ALTER BACKUP SET

• DROP BACKUP SET

• SHOW BACKUP SETS

Backups¶

Sie führen keinen tatsächlichen CREATE BACKUP-Befehl aus. Um ein neues Backup zu erstellen, führen Sie ALTER BACKUP SET … ADD BACKUP aus. Oder wenn Sie das Backup-Set mit einer Backup-Richtlinie verknüpfen, die einen Zeitplan hat, erstellt Snowflake automatisch Backups im Backup-Set auf der Grundlage des angegebenen Zeitplans. Um ein älteres Backup zu löschen, führen Sie ALTER BACKUP SET … DELETE BACKUP aus. Für solche Vorgänge müssen Sie den Bezeichner für ein bestimmtes Backup angeben. Sie können die Bezeichner des Backups zusammen mit anderen Informationen suchen, z. B. wann das jeweilige Backup erstellt wurde, indem Sie den folgenden Befehl verwenden.

• SHOW BACKUPS IN BACKUP SET

Objekte aus Backups wiederherstellen¶

Sie verwenden die Syntax CREATE object_kind FROM BACKUP SET, um jede Art von Objekt aus dem entsprechenden Typ von Backup-Set wiederherzustellen.

Weitere Backups im Backup-Set verwenden das ursprüngliche Objekt, nicht das wiederhergestellte Objekt. Dies gilt auch dann, wenn Sie das wiederhergestellte Objekt in denselben Namen wie das ursprüngliche Objekt umbenennen. Wenn Sie nach einer Wiederherstellung dasselbe Backup-Set weiter verwenden möchten, stellen Sie das Objekt unter einem neuen Namen wieder her und übertragen dann die Daten zurück in das ursprüngliche Objekt.

• CREATE DATABASE FROM BACKUP SET

• CREATE SCHEMA FROM BACKUP SET

• CREATE TABLE FROM BACKUP SET

Ansichten¶

Die folgenden Systemansichten enthalten Metadaten zu Backups, Backup-Sets und Backup-Richtlinien.