本页面简要介绍了 Google Cloud NetApp Volumes 卷快照功能。
关于快照
NetApp Volumes 可帮助您通过快照管理数据使用情况,快照可快速恢复丢失的数据。快照是卷内容的某个时间点版本。它们是卷资源,是对数据的即时捕获,仅会占用修改后数据的空间。由于数据会随时间而变化,因此快照通常会随着时间的推移而占用更多空间。
注意事项
请考虑以下事项:
快照属性
快照具有以下功能:
即时捕获:快照可在确切的时间点即时捕获卷内的数据。
节省空间:快照只会覆盖已修改或已删除的数据并保留现有未更改的数据,因此只会消耗少量数据。
可作为文件系统读取:所有快照都可以通过标准文件系统接口轻松访问,并作为每个时间点的只读文件。
快速创建克隆:您可以在几秒钟内克隆一个卷。从快照创建新卷所需的时间与创建新空卷所需的时间相同,不受卷或快照大小的影响。克隆是新的卷,存储池需要有足够的可用容量来容纳它。
快速恢复快照:无论卷大小如何,您都可以在几分钟内将卷恢复为快照版本。创建快照后对卷做过的更改会被撤消,包括较新的快照。
快照类型
快照有三种类型:
手动快照:您手动创建和删除的快照。
安排好的快照:借助安排好的快照,您可以自动创建或删除快照。您可以通过以下格式的名称识别已安排的快照:
<schedule>-<timestamp>
<schedule>
:每小时、每周或每月<timestamp>
:以世界协调时间 (YYYY-MM-DD at HH:MM:SS UTC
) 显示
内部快照:NetApp Volumes 用于支持复制和备份操作的快照。您无法手动删除内部快照。您可以通过名称来识别内部快照。根据您查看快照的方式,内部快照可能具有不同的名称:
在 Google Cloud 控制台、Google Cloud CLI 和 API 响应中,内部快照使用
replication-<timestamp>
命名惯例。如果您使用 NFS 或 SMB 访问快照,内部快照将使用
snapmirror.<uuid>.<timestamp>.
命名惯例。
快照容量
在使用快照之前,请考虑以下有关快照容量的事项:
对于大多数数据集,额外 20% 的容量足以将快照保留最多四周。随着数据的过时,用于恢复的可能性会降低。
覆盖快照中的所有数据会消耗大量卷容量,这会影响预配卷容量。
快照时间表
常见的快照时间表如下:
在 48 小时内拍摄的每小时快照
30 天内拍摄的每日快照
可选在 60 天的时间段内拍摄每周快照
每小时快照属性
每小时快照可满足 1 小时的恢复点目标。
快照用例
以下部分介绍了您可以使用快照来解决数据管理难题的场景。
应用克隆:您可以使用快照和应用克隆功能,以便更快地进行更多测试迭代,而无需考虑克隆大小和数据结构。
卷恢复:如果卷上的数据损坏或被删除,您可以将快照与 NetApp Volumes 备份搭配使用,以恢复个别文件或目录。由于快照仅存在于卷中,因此它们本身无法完全保护卷免遭丢失。
数据版本控制:快照可帮助您保留同一数据集的多个版本。
应用和数据升级:在升级应用之前,您可以使用 NetApp 卷来捕获数据当前状态的快照。这样一来,如果升级失败,您就可以还原到之前的状态并恢复文件。
勒索软件防护:NetApp Volumes 有助于防范勒索软件攻击导致的数据丢失。由于快照是只读的且无法加密,因此有助于防范可能已安装卷的已被入侵虚拟机中不必要的数据加密或删除。如果发生大量数据丢失或数据泄露,您可以使用快照在几秒钟内将整个卷还原到之前的状态。
您还可以根据较早的快照创建可用的卷克隆,以便在调查数据是否在遭到勒索软件攻击后发生更改或损坏之前恢复操作。这两种方法都可以让您在几分钟内使用所有数据。
应用一致性恢复点:您可以使用 NetApp 卷来获取应用一致性快照,这些快照是在操作系统和应用将数据的当前状态写入存储空间后创建的。应用一致性快照可为应用提供明确的恢复点,并可用于创建应用的一致克隆。由于快照是通过客户端以只读方式访问的,因此用户可以立即恢复数据,从而显著缩短恢复时间。
崩溃一致快照:您还可以使用崩溃一致快照来恢复数据,这种方法适用于大多数应用。不过,存储空间中的某些数据在恢复时可能不是最新数据,因为这些数据会先保留在操作系统和应用缓存中一段时间,然后再写入存储空间。
逻辑空间用量:NetApp Volumes 空间用量反映了活跃文件系统中的数据以及快照保留的已删除块。删除引用这些块的最新快照后,NetApp Volumes 会立即释放保留的快照块。您的卷会继续占用预配的空间,其中包括快照保留的已删除数据。
快照空间使用示例
以下示例详细介绍了如何管理快照空间要求:
用户预配了 5 TiB 的卷,并将 3 TiB 的数据写入该卷。
结果:客户端看到 2 TiB 的可用空间。
客户端创建一个快照,然后删除 1 TiB 的数据。
5 TiB 容量 - 2 TiB 用户数据 - 1 TiB 快照数据
结果:客户端仍然只会看到 2 TiB 的可用空间。这是因为系统需要保留快照引用的 1 TiB 已删除数据。该容量会计入分配的容量。
NetApp Volumes 会删除快照。
结果:系统释放了 1 TiB 的快照数据,客户端看到了 3 TiB 的可用空间。