Blob 快照Blob snapshots

快照是在某一时间点拍摄的只读版本的 Blob。A snapshot is a read-only version of a blob that's taken at a point in time.

备注

Blob 版本控制提供了一种更高级的方法来维护以前的 blob 版本。Blob versioning offers a superior way to maintain previous versions of a blob. 有关详细信息,请参阅 Blob 版本控制For more information, see Blob versioning.

关于 Blob 快照About blob snapshots

备注

本文中所述的功能现在可用于具有分层命名空间的帐户。The features described in this article are now available to accounts that have a hierarchical namespace. 若要查看限制,请参阅 Azure Data Lake Storage Gen2 中可用的 Blob 存储功能一文。To review limitations, see the Blob storage features available in Azure Data Lake Storage Gen2 article.

Blob 的快照与其基本 Blob 相同,不过,Blob URI 的后面追加了一个 DateTime 值,用于指示快照的生成时间。A snapshot of a blob is identical to its base blob, except that the blob URI has a DateTime value appended to the blob URI to indicate the time at which the snapshot was taken. 例如,如果页 Blob URI 为 http://storagesample.core.blob.chinacloudapi.cn/mydrives/myvhd,则快照 URI 将类似于 http://storagesample.core.blob.chinacloudapi.cn/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000ZFor example, if a page blob URI is http://storagesample.core.blob.chinacloudapi.cn/mydrives/myvhd, the snapshot URI is similar to http://storagesample.core.blob.chinacloudapi.cn/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z.

备注

所有快照共享基本 Blob 的 URI。All snapshots share the base blob's URI. 基本 Blob 与快照之间的唯一区别体现在追加的 DateTime 值。The only distinction between the base blob and the snapshot is the appended DateTime value.

一个 Blob 可以有任意数目的快照。A blob can have any number of snapshots. 快照将持续存在,直到它们被显式删除(独立删除或作为基本 Blob 的删除 Blob 操作的一部分删除)。Snapshots persist until they are explicitly deleted, either independently or as part of a Delete Blob operation for the base blob. 可以枚举与基本 Blob 关联的快照,以跟踪当前快照。You can enumerate the snapshots associated with the base blob to track your current snapshots.

创建 Blob 的快照时,会将该 Blob 的系统属性复制到具有相同值的快照。When you create a snapshot of a blob, the blob's system properties are copied to the snapshot with the same values. 基本 Blob 的元数据也会复制到快照,除非创建快照时为其指定了单独的元数据。The base blob's metadata is also copied to the snapshot, unless you specify separate metadata for the snapshot when you create it. 创建快照后,可以读取、复制或删除它,但无法修改它。After you create a snapshot, you can read, copy, or delete it, but you cannot modify it.

任何与基本 Blob 关联的租约都不会影响快照。Any leases associated with the base blob do not affect the snapshot. 无法获取快照上的租约。You cannot acquire a lease on a snapshot.

VHD 文件用于存储 VM 磁盘的当前信息和状态。A VHD file is used to store the current information and status for a VM disk. 可以将磁盘从 VM 分离或者关闭 VM,并拍摄其 VHD 文件的快照。You can detach a disk from within the VM or shut down the VM, and then take a snapshot of its VHD file. 可以在以后使用该快照文件检索该时间点的 VHD 文件并重新创建 VM。You can use that snapshot file later to retrieve the VHD file at that point in time and recreate the VM.

了解快照如何产生费用Understand how snapshots accrue charges

重要计费注意事项Important billing considerations

以下列表包含创建快照时要考虑的要点。The following list includes key points to consider when creating a snapshot.

  • 不管唯一的块或页是在 Blob 还是快照中,存储帐户都会产生费用。Your storage account incurs charges for unique blocks or pages, whether they are in the blob or in the snapshot. 在更新快照所基于的 Blob 之前,你的帐户不会就与 Blob 关联的快照产生额外费用。Your account does not incur additional charges for snapshots associated with a blob until you update the blob on which they are based. 更新基本 Blob 后,它与其快照分离。After you update the base blob, it diverges from its snapshots. 发生这种情况时,需要支付每个 Blob 或快照中唯一块或页的费用。When this happens, you are charged for the unique blocks or pages in each blob or snapshot.
  • 在替换块 Blob 中的某个块后,会将该块作为唯一块进行收费。When you replace a block within a block blob, that block is subsequently charged as a unique block. 即使该块具有的块 ID 和数据与它在快照中所具有的 ID 和数据相同也是如此。This is true even if the block has the same block ID and the same data as it has in the snapshot. 重新提交块后,它将偏离它在任何快照中的对应部分,并且要为数据支付费用。After the block is committed again, it diverges from its counterpart in any snapshot, and you will be charged for its data. 对于使用相同数据更新的页 Blob 中的页面来说,情况也是如此。The same holds true for a page in a page blob that's updated with identical data.
  • 通过调用覆盖 blob 的全部内容的方法更新块 blob 将替换 blob 中的所有块。Updating a block blob by calling a method that overwrites the entire contents of the blob will replace all blocks in the blob. 如果你有与该 Blob 关联的快照,则基本 Blob 和快照中的所有块现在将发生偏离,你需要为这两个 Blob 中的所有块支付费用。If you have a snapshot associated with that blob, all blocks in the base blob and snapshot now diverge, and you will be charged for all the blocks in both blobs. 即使基本 Blob 和快照中的数据保持相同也是如此。This is true even if the data in the base blob and the snapshot remain identical.
  • Azure Blob 服务无法确定这两个块是否包含相同的数据。The Azure Blob service does not have a means to determine whether two blocks contain identical data. 每个上传和提交的块均被视为唯一的快,即使它具有相同的数据和块 ID 也是如此。Each block that is uploaded and committed is treated as unique, even if it has the same data and the same block ID. 由于唯一的块会产生费用,因此必须考虑到:在更新具有快照的 Blob 时,会产生额外的唯一块,因此也会产生额外的费用。Because charges accrue for unique blocks, it's important to consider that updating a blob that has a snapshot results in additional unique blocks and additional charges.

使用快照管理最大限度地降低成本Minimize costs with snapshot management

我们建议仔细管理快照,避免额外费用。We recommend managing your snapshots carefully to avoid extra charges. 遵循下述最佳做法可以将存储快照的费用降至最低:You can follow these best practices to help minimize the costs incurred by the storage of your snapshots:

  • 除非应用程序设计需要保留与 Blob 关联的快照,否则请在更新 Blob 时删除并重新创建这些快照,即使你使用相同的数据进行更新也是如此。Delete and re-create snapshots associated with a blob whenever you update the blob, even if you are updating with identical data, unless your application design requires that you maintain snapshots. 通过删除并重新创建 Blob 的快照,可以确保 Blob 和快照不会发生偏离。By deleting and re-creating the blob's snapshots, you can ensure that the blob and snapshots do not diverge.
  • 如果要保留 blob 的快照,请避免在更新 blob 时调用覆盖整个 blob 的方法。If you are maintaining snapshots for a blob, avoid calling methods that overwrite the entire blob when you update the blob. 而应更新尽可能少的块数,使成本保持低廉。Instead, update the fewest possible number of blocks in order to keep costs low.

快照计费方案Snapshot billing scenarios

下列方案说明了块 Blob 及其快照如何产生费用。The following scenarios demonstrate how charges accrue for a block blob and its snapshots.

定价和计费Pricing and billing

创建快照(它是 Blob 的只读副本)会导致帐户产生额外的数据存储费用。Creating a snapshot, which is a read-only copy of a blob, can result in additional data storage charges to your account. 在设计应用程序时,有必要了解在哪些情况下会产生这些费用,以便最大程度地减少费用。When designing your application, it is important to be aware of how these charges might accrue so that you can minimize costs.

Blob 快照和 blob 版本一样,按与活动数据相同的费率计费。Blob snapshots, like blob versions, are billed at the same rate as active data. 如何对快照(或版本)进行计费取决于是否已为基本 blob 或其任何快照显式设置层级。How snapshots are billed depends on whether you have explicitly set the tier for the base blob or for any of its snapshots (or versions). 有关 blob 层的详细信息,请参阅 Azure Blob 存储:热、冷和存档访问层For more information about blob tiers, see Azure Blob storage: hot, cool, and archive access tiers.

如果尚未更改 blob 或快照的层级,则会对该 blob 及其快照以及其具有的任何版本中不重复的数据块进行计费。If you have not changed a blob or snapshot's tier, then you are billed for unique blocks of data across that blob, its snapshots, and any versions it may have. 有关详细信息,请参阅在未显式设置 blob 层级时进行计费For more information, see Billing when the blob tier has not been explicitly set.

如果已更改了 blob 或快照的层级,则会对整个对象进行计费,而不考虑 blob 和快照是否最终在同一层级中。If you have changed a blob or snapshot's tier, then you are billed for the entire object, regardless of whether the blob and snapshot are eventually in the same tier again. 有关详细信息,请参阅在显式设置了 blob 层级时进行计费For more information, see Billing when the blob tier has been explicitly set.

有关 blob 版本的计费详细信息,请参阅 Blob 版本控制For more information about billing details for blob versions, see Blob versioning.

在未显式设置 blob 层级时进行计费Billing when the blob tier has not been explicitly set

如果没有为基本 blob 或其任何快照显式设置 blob 层级,则会针对 blob 及其快照以及其具有的任何版本中不重复的块或页面向你收费。If you have not explicitly set the blob tier for a base blob or any of its snapshots, then you are charged for unique blocks or pages across the blob, its snapshots, and any versions it may have. 对于跨 blob 及其快照共享的数据,只会收费一次。Data that is shared across a blob and its snapshots is charged only once. 当 blob 更新时,基本 blob 中的数据与其快照中存储的数据将会相异,并且会按块或页面对不重复的数据进行收费。When a blob is updated, then data in a base blob diverges from the data stored in its snapshots, and the unique data is charged per block or page.

在替换块 Blob 中的某个块后,会将该块作为唯一块进行收费。When you replace a block within a block blob, that block is subsequently charged as a unique block. 即使该块具有的块 ID 和数据与它在快照中所具有的 ID 和数据相同也是如此。This is true even if the block has the same block ID and the same data as it has in the snapshot. 重新提交块后,它将与它在快照中的对应部分相异,并且你要为其数据付费。After the block is committed again, it diverges from its counterpart in the snapshot, and you will be charged for its data. 对于使用相同数据更新的页 Blob 中的页面来说,情况也是如此。The same holds true for a page in a page blob that's updated with identical data.

Blob 存储无法确定两个块是否包含相同的数据。Blob storage does not have a means to determine whether two blocks contain identical data. 每个上传和提交的块均被视为唯一的块,即使它具有相同的数据和块 ID 也是如此。Each block that is uploaded and committed is treated as unique, even if it has the same data and the same block ID. 由于不重复的块会产生费用,因此请务必记住,在 Blob 具有快照或版本时更新该 Blob 将导致产生更多不重复的块和额外费用。Because charges accrue for unique blocks, it's important to keep in mind that updating a blob when that blob has snapshots or versions will result in additional unique blocks and additional charges.

当 blob 具有快照时,请对块 blob 调用更新操作,以使它们更新尽可能少的块。When a blob has snapshots, call update operations on block blobs so that they update the least possible number of blocks. 允许对块进行精细控制的写入操作是放置块放置块列表The write operations that permit fine-grained control over blocks are Put Block and Put Block List. 另一方面,放置 Blob 操作会替换 blob 的全部内容,因此可能会导致额外的费用。The Put Blob operation, on the other hand, replaces the entire contents of a blob and so may lead to additional charges.

下列方案说明了未显式设置 blob 层级时块 Blob 及其快照将如何产生费用。The following scenarios demonstrate how charges accrue for a block blob and its snapshots when the blob tier has not been explicitly set.

方案 1Scenario 1

在方案 1 中,基本 Blob 自创建快照后未进行更新,因此仅唯一块 1、2 和 3 会产生费用。In scenario 1, the base blob has not been updated after the snapshot was taken, so charges are incurred only for unique blocks 1, 2, and 3.

图 1:显示了如何对基本 blob 和快照中不重复的块进行计费。

方案 2Scenario 2

在方案 2 中,已更新基本 Blob,但未更新快照。In scenario 2, the base blob has been updated, but the snapshot has not. 已更新块 3,即使它包含相同的数据和 ID,它也与快照中的块 3 不同。Block 3 was updated, and even though it contains the same data and the same ID, it is not the same as block 3 in the snapshot. 因此,帐户需要为四个块支付费用。As a result, the account is charged for four blocks.

图 2:显示了如何对基本 blob 和快照中不重复的块进行计费。

方案 3Scenario 3

在方案 3 中,已更新基本 Blob,但未更新快照。In scenario 3, the base blob has been updated, but the snapshot has not. 块 3 已替换为基础 Blob 中的块 4,但快照仍反映块 3。Block 3 was replaced with block 4 in the base blob, but the snapshot still reflects block 3. 因此,帐户需要为四个块支付费用。As a result, the account is charged for four blocks.

图 3:显示了如何对基本 blob 和快照中不重复的块进行计费。

方案 4Scenario 4

在方案 4 中,已完全更新基本 Blob,并且其中不包含任何原始块。In scenario 4, the base blob has been completely updated and contains none of its original blocks. 因此,帐户需要为所有八个唯一块支付费用。As a result, the account is charged for all eight unique blocks.

图 4:显示了如何对基本 blob 和快照中不重复的块进行计费。

提示

请避免调用覆盖整个 blob 的方法,而应更新单个块以使成本保持低廉。Avoid calling methods that overwrite the entire blob, and instead update individual blocks to keep costs low.

在显式设置了 blob 层级时进行计费Billing when the blob tier has been explicitly set

如果为 blob 或快照(或版本)显式设置了 blob 层级,则会针对新层级中对象的完整内容长度计费,而不考虑它是否与原始层级中的对象共享块。If you have explicitly set the blob tier for a blob or snapshot (or version), then you are charged for the full content length of the object in the new tier, regardless of whether it shares blocks with an object in the original tier. 你还需要为原始层级中最早版本的完整内容长度付费。You are also charged for the full content length of the oldest version in the original tier. 对于保留在原始层级中的任何版本或快照,都将针对其可能共享的不重复的块收费,如在未显式设置 blob 层级时进行计费中所述。Any versions or snapshots that remain in the original tier are charged for unique blocks that they may share, as described in Billing when the blob tier has not been explicitly set.

将 blob 移到新层级Moving a blob to a new tier

下表描述了将 blob 或快照移动到新层级时的计费行为。The following table describes the billing behavior for a blob or snapshot when it is moved to a new tier.

当针对以下项显式设置了 blob 层级时When blob tier is set explicitly on� 你需要为以下项付费Then you are billed for...
带有快照的基本 blobA base blob with a snapshot 新层级中的基本 blob 和原始层级中最旧的快照,以及其他快照中的任何不重复的块。1The base blob in the new tier and the oldest snapshot in the original tier, plus any unique blocks in other snapshots.1
具有先前版本和快照的基本 blobA base blob with a previous version and a snapshot 新层级中的基本 blob、原始层级中的最早版本、原始层级中的最早快照,以及其他版本或快照中的任何不重复的块1The base blob in the new tier, the oldest version in the original tier, and the oldest snapshot in the original tier, plus any unique blocks in other versions or snapshots1.
快照A snapshot 新层级中的快照和原始层级中的基本 blob,以及其他快照中的任何不重复的块。1The snapshot in the new tier and the base blob in the original tier, plus any unique blocks in other snapshots.1

1如果有其他先前版本或快照尚未从其原始层级中移出,则会根据这些版本或快照包含的不重复的块的数量对它们进行收费,如在未显式设置 blob 层级时进行计费中所述。1If there are other previous versions or snapshots that have not been moved from their original tier, those versions or snapshots are charged based on the number of unique blocks they contain, as described in Billing when the blob tier has not been explicitly set.

下图说明了当包含快照的 blob 移到另一个层级时,如何针对对象进行计费。The following diagram illustrates how objects are billed when a blob with snapshots is moved to a different tier.

此图显示了当对包含快照的 blob 显式分层时,如何针对对象进行计费。

为 blob、版本或快照显式设置层级的操作不能撤消。Explicitly setting the tier for a blob, version, or snapshot cannot be undone. 如果你将 blob 移动到新层级,然后将其移回其原始层级,则即使该对象与原始层级中的其他对象共享块,也会针对该对象的完整内容长度向你收费。If you move a blob to a new tier and then move it back to its original tier, you are charged for the full content length of the object even if it shares blocks with other objects in the original tier.

显式设置 blob、版本或快照层级的操作包括:Operations that explicitly set the tier of a blob, version, or snapshot include:

在启用了软删除的情况下删除 blobDeleting a blob when soft delete is enabled

在启用了 blob 软删除的情况下,如果删除或覆盖已显式设置其层级的基本 blob,则软删除的 blob 的任何先前版本都将按完整内容长度进行计费。When blob soft delete is enabled, if you delete or overwrite a base blob that has had its tier explicitly set, then any previous versions or snapshots of the soft-deleted blob are billed at full content length. 有关如何结合使用 blob 版本控制和软删除的详细信息,请参阅 Blob 版本控制和软删除For more information about how blob versioning and soft delete work together, see Blob versioning and soft delete.

下表描述了软删除的 blob 的计费行为,具体取决于是启用还是禁用了版本控制。The following table describes the billing behavior for a blob that is soft-deleted, depending on whether versioning is enabled or disabled. 启用版本控制后,软删除 blob 时将创建一个新版本。When versioning is enabled, a new version is created when a blob is soft-deleted. 禁用版本控制后,软删除 blob 时将创建一个软删除快照。When versioning is disabled, soft-deleting a blob creates a soft-delete snapshot.

当你覆盖已显式设置了其层级的基本 blob 时When you overwrite a base blob with its tier explicitly set� 你需要为以下项付费Then you are billed for...
如果同时启用了 blob 软删除和版本控制If blob soft delete and versioning are both enabled 所有现有版本(按完整内容长度),不考虑层级。All existing versions at full content length regardless of tier.
如果启用了 blob 软删除但禁用了版本控制If blob soft delete is enabled but versioning is disabled 所有现有软删除快照(按完整内容长度),不考虑层级。All existing soft-delete snapshots at full content length regardless of tier.

后续步骤Next steps