用备份为 Snowflake 数据加一层保护

除了众所周知的 Time Travel 功能之外，Snowflake Backups 还提供了额外一层保护，以应对因不可预见情况导致的数据丢失。

Snowflake Backups使您能够创建 Snowflake 对象（如表、模式和数据库）的快照。备份可以手动或自动创建，并通过备份策略进行配置，该策略定义其计划与保留期。

备份适用于所有 Snowflake 版本。一些高级功能，如保留锁和带法律保留的备份，适用于 Business Critical Edition 或更高版本。

让我们用一个简单示例来探讨备份如何工作。我们假设已经有一个数据仓库，其中填充了 gold 层，包含供报告和应用程序使用的业务就绪数据。我们希望每天对整个 gold 模式创建备份，并将每个备份保留 30 天。

设置示例

我们不想使用 ACCOUNTADMIN 或其他高权限角色来执行备份操作。相反，我们将创建一个自定义的 BACKUP_ADMIN 角色，并仅授予它所需的权限：

USE ROLE USERADMIN;
-- Create the custom role
CREATE ROLE BACKUP_ADMIN;
-- Preserve the role hierarchy
GRANT ROLE BACKUP_ADMIN TO ROLE SYSADMIN;

USE ROLE SYSADMIN;
-- Create a custom warehouse
CREATE WAREHOUSE BACKUP_ADMIN_WH WAREHOUSE_SIZE = 'XSMALL' AUTO_SUSPEND = 60;
GRANT USAGE ON WAREHOUSE BACKUP_ADMIN_WH TO ROLE BACKUP_ADMIN;

对于此示例，我们将创建一个 GOLD 模式，并用来自 Snowflake 示例数据数据库的几个示例表填充它：

CREATE DATABASE DWH_DB;
-- Create the gold schema and populate with some sample data
CREATE SCHEMA GOLD;
CREATE TABLE GOLD.CUSTOMER AS
SELECT * FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER;
CREATE TABLE GOLD.ORDERS AS
SELECT * FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS;
CREATE TABLE GOLD.NATION AS
SELECT * FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.NATION;
-- Create the admin schema to store the backup-related objects
CREATE SCHEMA ADMIN;

接下来，我们将授予 BACKUP_ADMIN 角色对 GOLD 模式中对象的访问权限：

USE ROLE SYSADMIN;
GRANT USAGE ON DATABASE DWH_DB TO ROLE BACKUP_ADMIN;
GRANT USAGE ON SCHEMA DWH_DB.GOLD TO ROLE BACKUP_ADMIN;

创建备份策略

在创建备份之前，我们需要一个备份策略，它定义：

• 备份创建的频率
• 每个备份的保留时长

我们将把该策略存储在 ADMIN 模式中。

首先，自定义角色需要在此模式中创建备份策略的权限：

USE ROLE SECURITYADMIN;
GRANT USAGE ON SCHEMA DWH_DB.ADMIN TO ROLE BACKUP_ADMIN;
GRANT CREATE BACKUP POLICY ON SCHEMA DWH_DB.ADMIN TO ROLE BACKUP_ADMIN;

现在我们可以切换到自定义角色，并创建一个名为 DAILY_GOLD_BACKUP_POLICY 的备份策略，该策略每 24 小时创建一次备份并保留 30 天：

USE ROLE BACKUP_ADMIN;
USE WAREHOUSE BACKUP_ADMIN_WH;

CREATE BACKUP POLICY DWH_DB.ADMIN.DAILY_GOLD_BACKUP_POLICY
SCHEDULE = '24 HOUR'
EXPIRE_AFTER_DAYS = 30;

创建备份策略后，目前还没有任何操作发生。

创建备份集

我们还需要一个备份集，将要保护的对象与备份策略关联起来。备份集将存储在 ADMIN 模式中，因此自定义角色需要相应的权限：

USE ROLE SECURITYADMIN;
GRANT CREATE BACKUP SET ON SCHEMA DWH_DB.ADMIN TO ROLE BACKUP_ADMIN;

但这还不足以执行备份。我们还需要一项额外权限，因为创建备份策略的权限并不会自动允许该角色将该策略应用于备份集。为此，自定义角色还需要应用该策略的权限，我们使用 ACCOUNTADMIN 角色来授予该权限：

USE ROLE ACCOUNTADMIN;
GRANT APPLY ON BACKUP POLICY DWH_DB.ADMIN.DAILY_GOLD_BACKUP_POLICY
TO ROLE BACKUP_ADMIN;

尽管我们应尽可能避免将 ACCOUNTADMIN 角色用于常规任务，但这是少数需要它的地方之一。

回到自定义角色，我们现在可以使用之前创建的备份策略为模式 GOLD 创建备份集：

USE ROLE BACKUP_ADMIN;
CREATE BACKUP SET DWH_DB.ADMIN.GOLD_BACKUP_SET
FOR SCHEMA DWH_DB.GOLD
WITH BACKUP POLICY DWH_DB.ADMIN.DAILY_GOLD_BACKUP_POLICY;

我们现在有一个名为 GOLD_BACKUP_SET 的备份集，它使用名为 DAILY_GOLD_BACKUP_POLICY 的策略保护 GOLD 模式。

由于我们的备份策略配置为每 24 小时运行一次，我们可以明天回来检查它是否已执行。但我们不想等那么久，我们应该有一种方法来测试我们的备份配置。

我们可以手动向备份集添加一个备份：

USE ROLE BACKUP_ADMIN;
ALTER BACKUP SET DWH_DB.ADMIN.GOLD_BACKUP_SET ADD BACKUP;

然后我们可以使用 SHOW BACKUPS 命令查看备份集中可用的备份：

SHOW BACKUPS IN BACKUP SET DWH_DB.ADMIN.GOLD_BACKUP_SET;

每个备份都有自己的 BACKUP_ID、创建时间、过期时间和其他属性。该备份表示当时整个 GOLD 模式的状态。

当 Snowflake 创建备份时会发生什么？

创建备份并不意味着 Snowflake 会创建数据的物理副本。它使用我们熟悉的零拷贝机制，因为克隆时也使用该机制。

与数据对象的克隆一样，备份也会引用在备份创建时表示数据的不可变存储对象。只要未过期的备份仍引用它们，Snowflake 就不会删除它们，就像克隆对象一样。

这使得创建每日数据恢复点在存储上的效率显著高于每晚物理复制整个模式。

从备份恢复数据

现在让我们想象发生了意外情况，例如意外更新、删除或数据损坏，我们想从备份恢复数据。

假设一个表被 ETL 流程意外截断：

TRUNCATE TABLE DWH_DB.GOLD.ORDERS;

幸运的是，我们有一个备份可以从中恢复它。让我们查找可用的备份：

SHOW BACKUPS IN BACKUP SET DWH_DB.ADMIN.GOLD_BACKUP_SET;

从该命令的输出中，我们获取要使用的备份的 BACKUP_ID（目前我们只有之前手动创建的一个备份，但将来我们通常会有许多备份，每天一个）。

然后我们可以将备份恢复到新模式中（首先为执行恢复的角色授予创建新模式的权限）：

USE ROLE SYSADMIN;
GRANT CREATE SCHEMA ON DATABASE DWH_DB TO ROLE BACKUP_ADMIN;

USE ROLE BACKUP_ADMIN;
CREATE SCHEMA DWH_DB.GOLD_RESTORED
FROM BACKUP SET DWH_DB.ADMIN.GOLD_BACKUP_SET
IDENTIFIER 'b25e6c31-a760-4317-b75a-2835a694763a';

然后我们可以检查模式是否已创建，以及它是否包含所有表，包括被意外截断的 ORDERS 表，该表应该有数据，因为它是从备份恢复的。

然后我们可以随意处理恢复的数据，例如将备份的 ORDERS 表中的数据插入到 GOLD 模式中。

将备份与 Time Travel 进行比较

此时，显而易见的问题是：我们难道不能使用 Time Travel 恢复表中的数据吗？答案当然是，可以。对于很快被发现的意外 TRUNCATE，Time Travel 很可能是首选恢复措施。

但备份并非仅仅为了替代 Time Travel。它们为一组表提供了具有各自计划和保留生命周期的显式恢复点。这些功能相互补充。

使用保留锁保护备份

我们的备份当前在 30 天后过期，但具有足够权限的管理员仍可以在到期前删除它们。为了获得更强的保护，您需要支持保留锁的 Snowflake Business Critical Edition。

例如，在创建备份策略时，我们可以指定 WITH RETENTION LOCK：

CREATE BACKUP POLICY DWH_DB.ADMIN.DAILY_GOLD_LOCKED_POLICY
    WITH RETENTION LOCK
    SCHEDULE = '24 HOUR'
    EXPIRE_AFTER_DAYS = 30;

受保留锁策略保护的备份集不能提前删除其备份，即使是 ACCOUNTADMIN 角色也不行。

总结

Snowflake 备份与 Time Travel、Fail-safe 和复制等功能一起，提供另一层数据保护。它们允许我们为表、架构或数据库创建显式恢复点，并通过备份策略管理其生命周期。

正如我们在本示例中所见，实施备份策略只需要几个组件：定义计划和保留期的备份策略、标识应保护内容的备份集，以及负责管理备份的角色所需的相应权限。一旦配置完成，Snowflake 会根据策略负责创建和使恢复点过期。

然而，在这个简单示例中，我们尚未涵盖一些重要注意事项：

• 架构或数据库中包含的并非每个对象都会包含在其备份中。 例如，临时表、外部表、Iceberg 表、混合表、物化视图、暂存区、管道、流以及一些其他对象类型不会被备份。用户和角色等账户级对象也不包括在内。如果你的对象引用了正在备份的数据库或架构之外的资源，那么在规划恢复时也需要考虑这些依赖关系。
• 备份与源位于同一云区域。 因此，不应将其视为跨区域灾难恢复的替代方案。对于需要防范区域或云提供商中断的场景，可以将备份与 Snowflake 复制结合使用。

有关更多信息，请参阅 Snowflake 备份 文档。

我是 Maja Ferle，Snowflake Data Superhero，也是 In516ht 的高级顾问。你可以通过 LinkedIn 与我联系，或阅读我的最新著作 Snowflake Data Engineering。

Protecting Your Snowflake Data with Backups 最初发表于 Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science（Medium），人们正在那里通过突出显示并回应此故事来继续对话。