{
	"id": "0a865ef7-02f6-442f-9c52-22dfb7fbc9d4",
	"created_at": "2026-04-06T00:14:38.749643Z",
	"updated_at": "2026-04-10T03:20:17.451745Z",
	"deleted_at": null,
	"sha1_hash": "039d5491ed4fe2949688287b80314ec3c2b70a5f",
	"title": "Blob snapshots - Azure Storage",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 103999,
	"plain_text": "Blob snapshots - Azure Storage\r\nBy normesta\r\nArchived: 2026-04-05 17:32:02 UTC\r\nA snapshot is a read-only version of a blob that's taken at a point in time.\r\nNote\r\nBlob versioning offers a superior way to maintain previous versions of a blob. For more information, see Blob\r\nversioning.\r\nAbout blob snapshots\r\nA snapshot of a blob is identical to its base blob, except that the blob URI has a DateTime value appended to the\r\nblob URI to indicate the time at which the snapshot was taken. For example, if a page blob URI is\r\nhttp://storagesample.core.blob.windows.net/mydrives/myvhd , the snapshot URI is similar to\r\nhttp://storagesample.core.blob.windows.net/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z .\r\nNote\r\nAll snapshots share the base blob's URI. The only distinction between the base blob and the snapshot is the\r\nappended DateTime value.\r\nA blob can have any number of snapshots. Snapshots persist until they're explicitly deleted, either independently\r\nor as part of a Delete Blob operation for the base blob. You can enumerate the snapshots associated with the base\r\nblob to track your current snapshots.\r\nWhen you create a snapshot of a blob, the blob's system properties are copied to the snapshot with the same\r\nvalues. The base blob's metadata is also copied to the snapshot, unless you specify separate metadata for the\r\nsnapshot when you create it. After you create a snapshot, you can read, copy, or delete it, but you can't modify it.\r\nAny leases associated with the base blob don't affect the snapshot. You can't acquire a lease on a snapshot.\r\nYou can create a snapshot of a blob in the hot or cool tier. Snapshots on blobs in the archive tier aren't supported.\r\nA VHD file is used to store the current information and status for a VM disk. You can detach a disk from within\r\nthe VM or shut down the VM, and then take a snapshot of its VHD file. You can use that snapshot file later to\r\nretrieve the VHD file at that point in time and recreate the VM.\r\nPricing and billing\r\nCreating a snapshot, which is a read-only copy of a blob, can result in extra data storage charges to your account.\r\nWhen designing your application, it's important to be aware of how these charges might accrue so that you can\r\nhttps://docs.microsoft.com/en-us/azure/storage/blobs/snapshots-overview\r\nPage 1 of 6\n\nminimize costs.\r\nBlob snapshots, like blob versions, are billed at the same rate as active data. How snapshots are billed depends on\r\nwhether you have explicitly set the tier for the base blob or for any of its snapshots (or versions). For more\r\ninformation about blob tiers, see Access tiers for blob data.\r\nIf you haven't changed a blob or snapshot's tier, then you're billed for unique blocks of data across that blob, its\r\nsnapshots, and any versions it may have. For more information, see Billing when the blob tier hasn't been\r\nexplicitly set.\r\nIf you have changed a blob or snapshot's tier, then you're billed for the entire object, regardless of whether the\r\nblob and snapshot are eventually in the same tier again. For more information, see Billing when the blob tier has\r\nbeen explicitly set.\r\nFor storage accounts that leverage the smart tier public preview, versions and snapshots are billed at full content\r\nlength. For more information, see Optimize costs with smart tier.\r\nFor more information about billing details for blob versions, see Blob versioning.\r\nMinimize costs with snapshot management\r\nMicrosoft recommends managing your snapshots carefully to avoid extra charges. You can follow these best\r\npractices to help minimize the costs incurred by the storage of your snapshots:\r\nDelete and re-create snapshots associated with a blob whenever you update the blob, even if you're\r\nupdating with identical data, unless your application design requires that you maintain snapshots. By\r\ndeleting and re-creating the blob's snapshots, you can ensure that the blob and snapshots don't diverge.\r\nIf you're maintaining snapshots for a blob, avoid calling methods that overwrite the entire blob when you\r\nupdate the blob. Instead, update the fewest possible number of blocks in order to keep costs low.\r\nBilling when the blob tier hasn't been explicitly set\r\nIf you have not explicitly set the blob tier for a base blob or any of its snapshots, then you're charged for unique\r\nblocks or pages across the blob, its snapshots, and any versions it may have. Data that is shared across a blob and\r\nits snapshots is charged only once. When a blob is updated, then data in a base blob diverges from the data stored\r\nin its snapshots, and the unique data is charged per block or page.\r\nWhen you replace a block within a block blob, that block is later charged as a unique block. This is true even if the\r\nblock has the same block ID and the same data as it has in the snapshot. After the block is committed again, it\r\ndiverges from its counterpart in the snapshot, and you'll be charged for its data. The same holds true for a page in a\r\npage blob that's updated with identical data.\r\nBlob storage doesn't have a means to determine whether two blocks contain identical data. Each block that is\r\nuploaded and committed is treated as unique, even if it has the same data and the same block ID. Because charges\r\naccrue for unique blocks, it's important to keep in mind that updating a blob when that blob has snapshots or\r\nversions results in extra unique blocks and extra charges.\r\nhttps://docs.microsoft.com/en-us/azure/storage/blobs/snapshots-overview\r\nPage 2 of 6\n\nWhen a blob has snapshots, call update operations on block blobs so that they update the least possible number of\r\nblocks. The write operations that permit fine-grained control over blocks are Put Block and Put Block List. The\r\nPut Blob operation, on the other hand, replaces the entire contents of a blob and so may lead to extra charges.\r\nThe following scenarios demonstrate how charges accrue for a block blob and its snapshots when the blob tier has\r\nnot been explicitly set.\r\nScenario 1\r\nIn scenario 1, the base blob hasn't been updated after the snapshot was taken, so charges are incurred only for\r\nunique blocks 1, 2, and 3.\r\nScenario 2\r\nIn scenario 2, the base blob has been updated, but the snapshot hasn't. Block 3 was updated, and even though it\r\ncontains the same data and the same ID, it isn't the same as block 3 in the snapshot. As a result, the account is\r\ncharged for four blocks.\r\nScenario 3\r\nIn scenario 3, the base blob has been updated, but the snapshot hasn't. Block 3 was replaced with block 4 in the\r\nbase blob, but the snapshot still reflects block 3. As a result, the account is charged for four blocks.\r\nScenario 4\r\nIn scenario 4, the base blob has been completely updated and contains none of its original blocks. As a result, the\r\naccount is charged for all eight unique blocks.\r\nhttps://docs.microsoft.com/en-us/azure/storage/blobs/snapshots-overview\r\nPage 3 of 6\n\nTip\r\nAvoid calling methods that overwrite the entire blob, and instead update individual blocks to keep costs low.\r\nBilling when the blob tier has been explicitly set\r\nIf you have explicitly set the blob tier for a blob or snapshot (or version), then you're charged for the full content\r\nlength of the object in the new tier, regardless of whether it shares blocks with an object in the original tier. You're\r\nalso charged for the full content length of the oldest version in the original tier. Any versions or snapshots that\r\nremain in the original tier are charged for unique blocks that they may share, as described in Billing when the blob\r\ntier hasn't been explicitly set.\r\nMoving a blob to a new tier\r\nThe following table describes the billing behavior for a blob or snapshot when it's moved to a new tier.\r\nWhen blob tier is set\r\nexplicitly on...\r\nThen you're billed for...\r\nA base blob with a\r\nsnapshot\r\nThe base blob in the new tier and the oldest snapshot in the original tier, plus\r\nany unique blocks in other snapshots.1\r\nA base blob with a previous\r\nversion and a snapshot\r\nThe base blob in the new tier, the oldest version in the original tier, and the\r\noldest snapshot in the original tier, plus any unique blocks in other versions or\r\nsnapshots1.\r\nA snapshot\r\nThe snapshot in the new tier and the base blob in the original tier, plus any\r\nunique blocks in other snapshots.1\r\n1\r\nIf there are other previous versions or snapshots that haven't been moved from their original tier, those versions\r\nor snapshots are charged based on the number of unique blocks they contain, as described in Billing when the blob\r\ntier hasn't been explicitly set.\r\nThe following diagram illustrates how objects are billed when a blob with snapshots is moved to a different tier.\r\nhttps://docs.microsoft.com/en-us/azure/storage/blobs/snapshots-overview\r\nPage 4 of 6\n\nExplicitly setting the tier for a blob, version, or snapshot can't be undone. If you move a blob to a new tier and\r\nthen move it back to its original tier, you're charged for the full content length of the object even if it shares blocks\r\nwith other objects in the original tier.\r\nOperations that explicitly set the tier of a blob, version, or snapshot include:\r\nSet Blob Tier\r\nPut Blob with tier specified\r\nPut Block List with tier specified\r\nCopy Blob with tier specified\r\nDeleting a blob when soft delete is enabled\r\nWhen blob soft delete is enabled, if you delete or overwrite a base blob that has had its tier explicitly set, then any\r\nprevious versions or snapshots of the soft-deleted blob are billed at full content length. For more information\r\nabout how blob versioning and soft delete work together, see Blob versioning and soft delete.\r\nThe following table describes the billing behavior for a blob that is soft-deleted, depending on whether versioning\r\nis enabled or disabled. When versioning is enabled, a new version is created when a blob is soft-deleted. When\r\nversioning is disabled, soft-deleting a blob creates a soft-delete snapshot.\r\nhttps://docs.microsoft.com/en-us/azure/storage/blobs/snapshots-overview\r\nPage 5 of 6\n\nWhen you overwrite a base blob with its tier\r\nexplicitly set...\r\nThen you're billed for...\r\nIf blob soft delete and versioning are both\r\nenabled\r\nAll existing versions at full content length regardless of\r\ntier.\r\nIf blob soft delete is enabled but versioning is\r\ndisabled\r\nAll existing soft-delete snapshots at full content length\r\nregardless of tier.\r\nFeature support\r\nSupport for this feature might be impacted by enabling Data Lake Storage Gen2, Network File System (NFS) 3.0\r\nprotocol, or the SSH File Transfer Protocol (SFTP). If you've enabled any of these capabilities, see Blob Storage\r\nfeature support in Azure Storage accounts to assess support for this feature.\r\nImportant\r\nThe Snapshots Preview for accounts that have the hierarchical namespace feature enabled is no longer accepting\r\nnew customers. We encourage you to consider alternative mechanisms. (Examples: Soft delete for blobs, AzCopy,\r\nVaulted Backup [Preview])\r\nNext steps\r\nBlob versioning\r\nCreate and manage a blob snapshot in .NET\r\nBack up Azure unmanaged VM disks with incremental snapshots\r\nSource: https://docs.microsoft.com/en-us/azure/storage/blobs/snapshots-overview\r\nhttps://docs.microsoft.com/en-us/azure/storage/blobs/snapshots-overview\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/azure/storage/blobs/snapshots-overview"
	],
	"report_names": [
		"snapshots-overview"
	],
	"threat_actors": [],
	"ts_created_at": 1775434478,
	"ts_updated_at": 1775791217,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/039d5491ed4fe2949688287b80314ec3c2b70a5f.pdf",
		"text": "https://archive.orkl.eu/039d5491ed4fe2949688287b80314ec3c2b70a5f.txt",
		"img": "https://archive.orkl.eu/039d5491ed4fe2949688287b80314ec3c2b70a5f.jpg"
	}
}