Backups para recuperação em caso de desastre e armazenamento imutável¶

Backup¶

Um backup representa um instantâneo pontual de um objeto.

• O objeto pode ser uma única tabela, um esquema ou um banco de dados inteiro.

• Um backup específico pode ser identificado por um ID exclusivo gerado pelo Snowflake.

• Um backup não pode ser modificado. No entanto, ele pode ser excluído, e o período de expiração do backup pode ser modificado (a menos que um bloqueio de retenção seja aplicado).

Durante as operações diárias, você raramente interage com backups individuais. Em vez disso, você gerencia os conjuntos de backups que os contêm. Por exemplo, para obter uma lista de backups, execute o comando SHOW BACKUPS IN BACKUP SET. Execute o comando ALTER BACKUP SET para criar um novo backup.

Conjunto de backups¶

Um conjunto de backups é um objeto no nível do esquema que contém um conjunto de backups para um banco de dados, esquema ou tabela específicos. O Snowflake tem comandos SQL para CREATE, ALTER, DROP, SHOW e DESCRIBE conjuntos de backups.

Você pode ter vários conjuntos de backups para o mesmo objeto.

O ciclo de vida dos backups em um conjunto é determinado por uma política de backup opcional que você anexa ao conjunto de backups. Você também pode adicionar ou excluir backups manualmente de um conjunto de backups. Sua capacidade de excluir backups é afetada por outros fatores, em particular o bloqueio de retenção e a retenção legal.

Política de backup¶

Uma política de backup é um objeto no nível do esquema que contém as configurações que definem o ciclo de vida dos backups em um conjunto. Essas configurações incluem agendamento, expiração e bloqueio de retenção.

• O cronograma determina quando os backups são criados. Ele pode ser definido como um intervalo em minutos ou como uma expressão cron. Por exemplo, se o cronograma for definido como uma hora, um backup do objeto será feito a cada 60 minutos.

• O período de expiração é o tempo de validade do backup. Após a expiração de um backup, o Snowflake o exclui automaticamente, a menos que uma retenção legal seja aplicada ao backup específico.

  Dica

  Se o conjunto de backups não tiver um bloqueio de retenção e o backup específico não tiver uma retenção legal aplicada, você poderá excluir o backup manualmente antes do término do período de expiração. É possível excluir manualmente um backup de cada vez, começando sempre pelo mais antigo sem retenção legal.

Cada política de backup deve ter uma ou as duas propriedades de cronograma e de período de expiração. Por exemplo, você pode criar uma política com um cronograma e um período de expiração e deixar que o Snowflake cuide da criação e remoção dos backups de todos os conjuntos aos quais a política é aplicada. Se preferir, crie uma política com um cronograma e sem período de expiração se quiser gerenciar a remoção de backups mais antigos por conta própria. Como alternativa, você também pode criar uma política com um período de expiração, mas sem cronograma, e gerenciar a criação de backups por conta própria. Não é possível criar uma política sem agendamento e sem período de expiração.

Se você associar uma política de backup a um conjunto de backups, faça isso ao criar o conjunto de backups ou aplique a política mais tarde. Como alternativa, você pode ter um conjunto de backups sem uma política de backup associada. Nesse caso, você controla manualmente quando fazer novos backups e expirar os antigos.

Você pode aplicar uma política de backup a vários conjuntos de backups. Se você modificar uma política de backup, o Snowflake aplicará as alterações a todos os conjuntos de backups aos quais a política está anexada.

Bloqueio de retenção¶

Um bloqueio de retenção protege o backup contra exclusão pelo período de expiração definido. Você pode usar um backup com bloqueio de retenção para conformidade regulatória e resiliência cibernética de backups. As seguintes restrições se aplicam a um conjunto de backups com bloqueio de retenção:

• Os backups não podem ser excluídos por nenhuma função, incluindo ACCOUNTADMIN.

• Não é possível diminuir o período de expiração do backup, mas você pode aumentá-lo.

• Não é possível descartar um conjunto que tenha backups não expirados.

• Não é possível descartar um esquema que tenha um conjunto de backups com backups não expirados.

• Não é possível descartar um banco de dados que tenha um conjunto de backups com backups não expirados.

• Não é possível descartar uma conta que tenha um banco de dados com um conjunto de backups com backups não expirados.

Retenção legal¶

O recurso de suspensão legal dos backups do Snowflake evita substituir ou excluir backups. Dessa forma, você pode preservar bancos de dados, esquemas ou tabelas do Snowflake com base em seus próprios requisitos legais.

O Snowflake permite que você aplique uma retenção legal a backups específicos. Quando um backup do Snowflake está sob retenção legal, as seguintes condições se aplicam:

• Ninguém pode modificar o backup.

• Ninguém pode excluir o backup. Isso é válido mesmo quando o backup já ultrapassou o período EXPIRE_AFTER_DAYS.

• O acesso ao backup é registrado em log e auditável.

• A retenção legal pode ser removida por um usuário privilegiado, diferentemente de um bloqueio de retenção.

Visão geral do ciclo de vida do backup¶

O diagrama a seguir mostra como os objetos, os backups, os conjuntos de backups e as políticas de backup do Snowflake se relacionam. O diagrama envolve o tipo mais simples de backup: um para uma única tabela. Cada operação de backup produz um backup novo. Todos os backups de um determinado objeto são agrupados em um conjunto de backups. A adição e a remoção automáticas de backups do conjunto são controladas pela política de backup. Para recuperar as informações de um backup, use o comando CREATE para criar um objeto novo de um backup específico.

Limitações dos backups¶

Você pode criar no máximo dois conjuntos de backups de banco de dados para um banco de dados específico. Da mesma forma, você pode criar no máximo dois conjuntos de backups de esquema para um esquema específico e dois conjuntos de backups de tabela para uma tabela específica. Um objeto ainda pode aparecer em mais de dois conjuntos de backups. Por exemplo, uma tabela pode ter um ou dois conjuntos de backups de tabela associados. A mesma tabela também pode estar incluída em um ou dois conjuntos de backups de esquema, e um ou dois conjuntos de backups de banco de dados.

Referências de tabelas a outros objetos¶

Objetos, como exibições ou funções, podem fazer referência a objetos fora do esquema ou do banco de dados no backup. Para garantir que essas referências continuem funcionando após a restauração de um backup, siga uma destas estratégias:

• Se as tabelas e os outros objetos aos quais elas se referem estiverem todos no mesmo esquema ou banco de dados, crie um conjunto de backups para todo o esquema ou banco de dados. Dessa forma, o Snowflake restaura todos os objetos interconectados de uma vez quando você faz a restauração a partir do backup.

• Se os objetos em um conjunto de backups fizerem referência a objetos que não estão incluídos no conjunto de backups, esteja ciente de que, quando um backup for restaurado, as referências dos objetos restaurados apontarão para os objetos originais do outro banco de dados ou esquema. Se você descartou esses outros objetos ou alterou as propriedades deles depois de fazer o backup, pode encontrar erros ao acessar os objetos restaurados.

• Para objetos em nível de conta, todas as referências de objetos restaurados sempre apontam para o objeto original em nível de conta. Isso ocorre porque os objetos no nível da conta não fazem parte de nenhum backup. Por exemplo, um backup de esquema pode conter um segredo que se refere a uma integração de segurança. A integração de segurança é um objeto no nível da conta e não pode ser incluída em nenhum backup.

Tipos de objetos em backups de banco de dados e esquema¶

A tabela a seguir lista os objetos incluídos em um backup de banco de dados ou esquema:

Como o Snowflake associa objetos aos conjuntos de backups deles¶

Quando você cria um conjunto de backups para um banco de dados, um esquema ou uma tabela, o Snowflake associa o conjunto de backups ao ID interno do banco de dados, do esquema ou da tabela. Se você excluir o objeto original, não poderá adicionar outros backups ao conjunto de backups. Esse comportamento se aplica mesmo quando você recria um objeto com o mesmo nome ou o substitui por um restaurado de um backup.

Em vez disso, se você renomear o objeto original, poderá continuar fazendo mais backups dele adicionando outros backups ao mesmo conjunto. Nesse caso, a saída de SHOW BACKUP SETS será alterada para refletir o valor OBJECT_NAME do objeto renomeado.

Se você deseja fazer backups de uma tabela, mas costuma remover e recriar essa tabela, talvez por meio das instruções CREATE OR REPLACE, inclua a tabela em um conjunto de backups para o esquema ou o banco de dados que a contém. Dessa forma, é possível continuar usando o mesmo conjunto de backups, independentemente das alterações na tabela.

Ao restaurar uma tabela de um backup, ela começa com um nome diferente do original. Suponha que você queira substituir completamente o conteúdo da tabela original pelos dados do backup e continuar usando o mesmo conjunto de backups para mais backups dessa mesma tabela. Nesse caso, use uma instrução TRUNCATE ou DELETE para remover o conteúdo da tabela original e uma instrução INSERT … SELECT para copiar os dados da tabela restaurada. Não exclua a tabela original e renomeie a tabela restaurada com o nome da original.

Backups e criptografia¶

Os dados dos conjuntos de backups são protegidos pela mesma criptografia de ponta a ponta que os demais objetos e dados de tabelas do Snowflake. Para obter mais informações sobre a criptografia do Snowflake, consulte Explicação da criptografia de ponta a ponta no Snowflake.

A rotação de chaves também se aplica aos dados em backups.

Backups e linhagem de dados¶

O Snowflake não preserva metadados de linhagem de dados com backups de banco de dados, esquema e tabela. Depois de restaurar um objeto de um backup, você não poderá usar o Snowsight para visualizar informações de linhagem dos dados restaurados.

Concessão dos privilégios necessários para criar políticas e conjuntos de backups¶

Para permitir que a função myrole crie uma política de backup no esquema myschema, execute a seguinte instrução:

GRANT CREATE BACKUP POLICY ON SCHEMA policy_schema TO ROLE myrole;

Para permitir que a função myrole crie um conjunto de backups no esquema myschema, execute a seguinte instrução:

GRANT CREATE BACKUP SET ON SCHEMA policy_schema TO ROLE myrole;

Concessão do privilégio APPLY em uma política de backup para uma função¶

Para permitir que a função myrole aplique a política de backup hourly_backup_policy a um conjunto de backups, execute a seguinte instrução:

GRANT APPLY ON BACKUP POLICY hourly_backup_policy TO ROLE myrole;

Conceder o privilégio APPLY BACKUP RETENTION LOCK a uma função¶

Você pode conceder a uma função o privilégio para aplicar políticas de backup com bloqueio de retenção em conjuntos de backups.

Somente um usuário com a função ACCOUNTADMIN pode conceder esse privilégio.

Para permitir que a função retention_lock_admin_role aplique uma política de backup com bloqueio de retenção a um conjunto de backups, execute a seguinte instrução:

GRANT APPLY BACKUP RETENTION LOCK ON ACCOUNT TO ROLE retention_lock_admin_role;

Criação de backups agendados com bloqueio de retenção¶

Crie um conjunto de backups que gere backups automaticamente com bloqueio de retenção conforme um cronograma. O bloqueio de retenção impede que qualquer pessoa, até mesmo usuários privilegiados, exclua ou modifique backups em conjuntos de backups ao qual a política foi anexada.

Somente uma função que tenha o privilégio APPLY BACKUP RETENTION LOCK na conta pode criar uma política de backup com bloqueio de retenção.

1. Crie uma política com um bloqueio de retenção que faça backup diário com período de expiração de 90 dias:

   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. Crie um conjunto de backups para a tabela t2 com a política de backup daily_backup_policy_with_lock:

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

   Copy

3. Crie um conjunto de backups para o esquema s2 com a política de backup daily_backup_policy_with_lock:

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

   Copy

4. Crie um conjunto de backups para o banco de dados d2 com a política de backup daily_backup_policy_with_lock:

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

   Copy

Criação manual de backups¶

Você pode adicionar manualmente um backup a um conjunto de backups a qualquer momento. Esse procedimento faz backup do banco de dados, do esquema ou da tabela associados ao conjunto de backups. Você pode criar backups manualmente, sem considerar se o conjunto de backups também tem ou não backups agendados por uma política de backup. Se houver uma política de backup associada ao conjunto de backups, e ela definir um período de expiração, esse período também se aplicará ao backup manual.

O exemplo a seguir cria um conjunto de backups de tabela t1_backups e adiciona o primeiro backup a ele:

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

O exemplo a seguir cria uma política de backup com backups por hora, um conjunto de backups de tabela t2_backups que usa a política e, em seguida, adiciona um backup manual ao conjunto de 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;

Você pode executar comandos semelhantes para adicionar um backup a um conjunto de backups de esquema ou banco de dados. Substitua o nome do conjunto de backups de esquema ou banco de dados no comando ALTER BACKUP SET.

Suspensão da política de backup em um conjunto de backups¶

Ao suspender a política de backup em um conjunto de backups, você impede que a política seja usada para criar novos backups agendados nesse conjunto. Você também suspende a expiração dos backups existentes no conjunto de backups que usa a política de backup. Outros conjuntos de backups que usam a mesma política não são afetados.

O exemplo a seguir suspende uma política de backup no conjunto de backups t2_backups:

ALTER BACKUP SET t2_backups SUSPEND BACKUP POLICY;

Copy

Você também pode suspender seletivamente os processos apenas de criação ou apenas de expiração do conjunto de backups. O exemplo a seguir suspende a criação de novos backups no conjunto de backups t3_backups e suspende a expiração de backups antigos do conjunto de backups t4_backups:

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

Copy

Para obter mais informações sobre o comando ALTER BACKUP SET, consulte ALTER BACKUP SET.

Retomada da política de backup em um conjunto de backups¶

Você pode retomar as políticas de backup suspensas. Isso retoma a criação e a expiração de backups de acordo com a política de backup. Se um backup atingir o tempo de expiração enquanto a política estiver suspensa, o Snowflake o excluirá assim que a política for retomada.

O exemplo a seguir retoma uma política de backup no conjunto de backups t1_backup:

ALTER BACKUP SET t1_backups
  RESUME BACKUP POLICY;

Você também pode retomar seletivamente os processos apenas de criação ou apenas de expiração do conjunto de backups. O exemplo a seguir retoma a criação de novos backups no conjunto de backups t3_backups e retoma a expiração de backups antigos do conjunto de backups t4_backups:

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

Para obter mais informações sobre o comando ALTER BACKUP SET, consulte ALTER BACKUP SET.

Restauração de um backup¶

Você pode restaurar um objeto de um conjunto de backups usando o ID do backup específico. Por exemplo, para restaurar a tabela t1 do conjunto de backups t1_backups no esquema atual, execute as seguintes instruções:

1. Encontre o ID do backup da tabela a ser restaurado na coluna 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. Encontre o ID do backup do esquema a ser restaurado na coluna 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. Encontre o ID do backup do banco de dados a ser restaurado na coluna 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. Restaure o backup da tabela t1 feito em 2024-08-19 18:12:33:

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

   Copy

5. Restaure o backup do esquema s1 feito em 2024-08-19 18:12:33:

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

   Copy

6. Restaure o backup do banco de dados d1 feito em 2024-08-19 18:12:33:

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

   Copy

Exclusão do backup de um conjunto de backups¶

Para qualquer conjunto de backups, você só pode excluir o backup mais antigo que não tem uma retenção legal. Para fazer isso, especifique o ID do backup. Você pode encontrar os backups que não têm retenção legal examinando a propriedade is_under_legal_hold. Você pode encontrar o backup mais antigo examinando a propriedade created_on.

Nota

Não será possível excluir um backup de um conjunto se uma política de backup com bloqueio de retenção estiver anexada ao conjunto, ou se esse backup específico tiver uma retenção legal aplicada.

O backup que você excluir do conjunto de backups deve ser o mais antigo do conjunto.

1. Encontre o ID do backup da tabela a ser excluído na coluna backup_id na saída a seguir. Classificar em ordem crescente pela coluna created_on coloca o backup mais antigo em primeiro lugar. Você pode adicionar LIMIT 1 ao comando SELECT para retornar apenas a linha com os detalhes do backup mais antigo.

   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. Exclua o backup t1_backups criado em 2024-08-19 17:12:28 usando o backup_id:

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

   Copy

3. Encontre o ID do backup do esquema a ser excluído na coluna backup_id na seguinte saída:

   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. Exclua o backup s1_backups criado em 2024-08-19 17:12:28 usando o backup_id:

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

   Copy

5. Encontre o ID do backup do banco de dados a ser excluído na coluna backup_id na seguinte saída:

   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. Exclua o backup d1_backups criado em 2024-08-19 17:12:28 usando o backup_id:

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

   Copy

7. Tente excluir um backup mais recente de d1_backups criado em 2024-08-19 21:12:55. Observe como o Snowflake impede que você exclua um backup diferente daquele mais antigo no conjunto de backups.

   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.
   

Exclusão de um conjunto de backups¶

Você pode excluir um conjunto de backups usando o comando DROP BACKUP SET.

Excluir o conjunto de backups t1_backups:

DROP BACKUP SET t1_backups;

Excluir o conjunto de backups s1_backups:

DROP BACKUP SET s1_backups;

Excluir o conjunto de backups d1_backups:

DROP BACKUP SET d1_backups;

Localização de todos os conjuntos que contêm backups de uma tabela específica¶

O exemplo a seguir mostra como encontrar todos os conjuntos de backups que contêm uma tabela específica em um determinado esquema e banco de dados. O comando SHOW TABLES usa um operador de pipe para recuperar os nomes do banco de dados, esquema e tabela e armazená-los em variáveis. A saída SHOW BACKUP SETS é filtrada para mostrar os conjuntos de backups que fazem backup do banco de dados que contém a tabela, ou do esquema que contém a tabela, ou que contêm essa única tabela.

A saída filtrada de SHOW BACKUP SETS mostra que há dois conjuntos de backups para o banco de dados my_big_important_database, um conjunto de backups para o esquema my_big_important_database.public e um conjunto de backups para a tabela 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  |
+-------------+------------------+---------------------------+-------------+---------------------------+

Criação de backup para uma tabela com dependências¶

Os exemplos a seguir mostram como você pode criar um backup para uma tabela que faça referência a uma sequência e uma chave estrangeira em um esquema diferente. Para nos prepararmos, criamos o esquema other_schema contendo uma sequência e uma tabela. Em seguida, criamos a tabela principal no esquema public, referenciando a sequência e a outra tabela.

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

A saída GET_DDL() mostra as referências que apontam para o outro esquema:

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

Em seguida, criamos o conjunto de backups para a tabela e adicionamos um backup a ele:

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

A saída SHOW BACKUPS contém o valor backup_id a ser usado para a operação de restauração:

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

Restauramos essa tabela com um nome novo e confirmamos que a tabela restaurada se refere aos objetos no outro esquema:

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

Para ilustrar o que acontece se o objeto referenciado não existir mais, descartamos a sequência e restauramos a tabela novamente a partir do mesmo backup:

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;

Consultar a tabela ainda funciona:

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

No entanto, operações como GET_DDL(), DESCRIBE e INSERT falham porque dependem de uma sequência que não existe mais:

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.

Criação de backup para uma tabela dinâmica¶

Uma tabela dinâmica sempre envolve uma referência a alguma outra tabela. Por esse motivo, talvez você prefira usar backups de esquema ou de banco de dados para tabelas dinâmicas, para que as tabelas original e dinâmica possam ser incluídas no mesmo backup.

Se você criar um backup para uma tabela dinâmica, inclua a palavra-chave DYNAMIC no comando CREATE BACKUP SET e no comando CREATE TABLE ao restaurar de um backup. O exemplo a seguir configura a tabela dinâmica, um conjunto de backups para essa tabela e cria o primeiro backup:

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;

O exemplo a seguir mostra como determinar IDs para os backups criados em vários momentos. Neste caso, o backup mais recente é a primeira linha do conjunto de resultados. Em seguida, você usa o ID do backup no comando 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>';

Adicionar e remover retenções legais¶

Antes de trabalhar com retenções legais em backups do Snowflake, aprenda a finalidade e os requisitos delas. Para obter mais informações, consulte Retenção legal.

Suponha que a equipe jurídica ou de conformidade da sua organização envie uma solicitação de retenção para litígio, especificando quais tipos de dados precisam ser preservados. Nesse caso, você pode seguir um processo como este:

• Você trabalha com a equipe jurídica para identificar onde os dados relevantes estão armazenados e quais conjuntos de backups contêm os objetos associados.

• Você aplica uma retenção legal a um backup dentro do período aplicável em um conjunto de backups. Isso desabilita a expiração automática nesse backup. Você pode aplicar uma retenção legal a um backup que o Snowflake criou automaticamente com base em um cronograma ou que você criou manualmente. A retenção legal é aplicada sem considerar se o conjunto de backups tem ou não uma política de backup, um período de expiração ou um bloqueio de retenção associado.

• Você executa operações de atualização para todas as contas secundárias em que o banco de dados que contém o conjunto de backups é replicado. Dessa forma, a retenção legal e o backup associado são preservados em todas as operações de failover e failback.

• Você usa os controles de acesso e logs do Snowflake para auditar o acesso aos dados que estão sob retenção legal.

• Após a conclusão do processo judicial e a aprovação da remoção da retenção legal pela equipe jurídica, um usuário com o privilégio APPLY LEGAL HOLD libera a retenção legal. Em seguida, a automação normal para a expiração é retomada.

Este exemplo mostra a sequência de comandos SQL que você pode usar durante o ciclo de vida de uma retenção legal para um backup em um conjunto de backups específico. Você encontra o identificador do backup relevante usando o comando SHOW BACKUPS IN BACKUP SET e verificando a coluna "is_under_legal_hold" para ver se já existe uma retenção legal em vigor. Em seguida, você adiciona ou remove a retenção legal do backup específico.

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;

Replicação de objetos relacionados ao backup¶

Ao usar a replicação em combinação com backups de banco de dados, esquema e tabela, você especifica os bancos de dados que contêm os conjuntos e as políticas de backups em seus grupos de replicação e de failover. Você pode controlar como seus objetos relacionados a backups são replicados organizando os grupos de replicação e de failover e escolhendo quais bancos de dados e esquemas contêm os conjuntos e as políticas de backups. Para obter mais informações, consulte Backup replication for database, schema, and table backups.

Os conjuntos e as políticas de backups são objetos de banco de dados. O Snowflake replica os conjuntos e as políticas de backups junto com os bancos de dados e os esquemas que os contêm.

O Snowflake minimiza o tempo e o uso de armazenamento de backups usando um mecanismo semelhante à clonagem, para que cada backup não exija uma nova cópia completa de todos os dados da tabela. Se o conjunto de backups fizer parte de um grupo de failover diferente do banco de dados, do esquema ou da tabela à qual o conjunto de backups se aplica, haverá uma transferência completa única dos dados na primeira atualização desse grupo de replicação ou de failover.

Quando um grupo de replicação ou de failover inclui um conjunto de backups, o aumento na latência de atualização é proporcional ao número de backups criados desde a última atualização.

Se você definir um período de expiração para backups mais antigos, a exclusão automática ocorrerá na conta primária. Esses backups expirados serão removidos da conta secundária quando você executar uma operação de atualização.

Portanto, você pode ajustar a replicação para objetos relacionados a backups seguindo estas práticas:

• Para minimizar a chance de falhas de atualização, coloque o conjunto e a política de backup opcional nos mesmos banco de dados e esquema. Se isso não for prático, coloque-os no mesmo grupo de replicação ou de failover. Dessa forma, todos esses objetos relacionados serão replicados ao mesmo tempo.

• Para maximizar a flexibilidade de quais objetos relacionados a backups são replicados e o cronograma de replicação, coloque o conjunto e a política de backup opcional em um banco de dados diferente do banco de dados, do esquema ou da tabela associados. Dessa forma, você pode especificar se os objetos relacionados a backups serão replicados e com que frequência.

• Se você aplicar uma política com um período de expiração para backups mais antigos, torne o período de expiração mais longo que o intervalo entre as operações de atualização da replicação. Dessa forma, cada backup novo será replicado para a conta secundária pelo menos uma vez antes de expirar.

• Logo após adicionar uma retenção legal, execute operações de atualização em todas as contas secundárias em que o banco de dados que contém o conjunto de backups foi replicado. Dessa forma, a retenção legal e o backup associado são preservados em todas as operações de failover e failback.

• Suponha que você coloque uma política e um conjunto de backups associado em bancos de dados que fazem parte de grupos diferentes de replicação ou de failover. Nesse caso, faça a atualização inicial do grupo que contém a política de backup primeiro. Caso contrário, a operação de atualização falhará porque você não pode criar um conjunto de backups sem a política de backup associada na conta secundária.

  Nota

  Colocar o conjunto de backups em um grupo de replicação ou de failover diferente daquele do objeto do conjunto requer uma transferência completa de todos os dados, durante a primeira atualização do grupo que contém o conjunto.

  Se você restaurar um backup de esquema ou de banco de dados em uma conta secundária, as referências aos objetos no esquema ou banco de dados restaurado poderão não ser resolvidas corretamente, a menos que os objetos referenciados façam parte do mesmo grupo de failover que o do backup.

Monitoramento de backups e operações de backup¶

Você pode determinar quais objetos relacionados ao backup existem, as propriedades deles e quanto armazenamento eles usam consultando as seguintes exibições.

Esquema de informações:

• Exibição BACKUP_POLICIES

• Exibição BACKUP_SETS

• Exibição BACKUPS

Uso da conta:

• Exibição BACKUP_OPERATION_HISTORY

• Exibição BACKUP_POLICIES

• Exibição BACKUP_SETS

• Exibição BACKUP_STORAGE_USAGE

• Exibição BACKUPS

Uso da organização:

• Exibição BACKUP_OPERATION_HISTORY

• Exibição BACKUP_POLICIES

• Exibição BACKUP_SETS

• Exibição BACKUPS

Política de backup¶

• CREATE BACKUP POLICY

• ALTER BACKUP POLICY

• DROP BACKUP POLICY

• SHOW BACKUP POLICIES

Conjunto de backups¶

• CREATE BACKUP SET

• ALTER BACKUP SET

• DROP BACKUP SET

• SHOW BACKUP SETS

Backups¶

Você não executa um comando CREATE BACKUP propriamente dito. Para criar um novo backup, execute ALTER BACKUP SET … ADD BACKUP. Se preferir, quando você associar o conjunto de backups a uma política de backup que tenha um cronograma, o Snowflake criará backups no conjunto automaticamente com base no cronograma especificado. Para excluir um backup mais antigo, execute ALTER BACKUP SET … DELETE BACKUP. Essas operações exigem que você especifique o identificador de um backup específico. Você encontra os identificadores dos backups, junto com outras informações, como a data de criação dos backups, usando o comando a seguir.

• SHOW BACKUPS IN BACKUP SET

Restauração de objetos dos backups¶

Use a sintaxe CREATE object_kind FROM BACKUP SET para restaurar cada tipo de objeto a partir do tipo apropriado de conjunto de backups.

Outros backups no conjunto de backups usam o objeto original, não o restaurado. Isso se aplica mesmo que você renomeie o objeto restaurado com o mesmo nome do original. Se quiser continuar usando o mesmo conjunto de backups após uma restauração, restaure o objeto com um nome novo e transfira os dados de volta ao objeto original.

• CREATE DATABASE FROM BACKUP SET

• CREATE SCHEMA FROM BACKUP SET

• CREATE TABLE FROM BACKUP SET

Exibições¶

As exibições do sistema a seguir contêm metadados relacionados a backups, conjuntos de backups e políticas de backup.