Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Azure DP-203 Certification > Azure Storage Data Protection > Flashcards

Azure Storage Data Protection Flashcards

1
Q

Recommendations for basic data protection

A

If you are looking for basic data protection coverage for your storage account and the data that it contains, then Microsoft recommends taking the following steps to begin with:

  • Configure an Azure Resource Manager lock on the storage account to protect the account from deletion or configuration changes. Learn more…
  • Enable container soft delete for the storage account to recover a deleted container and its contents. Learn more…
  • Save the state of a blob at regular intervals:
    • For Blob Storage workloads, enable blob versioning to automatically save the state of your data each time a blob is overwritten. Learn more…
    • For Azure Data Lake Storage workloads, take manual snapshots to save the state of your data at a particular point in time. Learn more…

These options, as well as additional data protection options for other scenarios, are described in more detail in the following section.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Data protection by resource type (mention 4)

A

Data protection by resource type

The following table summarizes the Azure Storage data protection options according to the resources they protect.

Data protection optionProtects an account from deletionProtects a container from deletionProtects an object from deletionProtects an object from overwritesAzure Resource Manager lockYesNo1NoNoImmutability policy on a blob versionYes2Yes3YesYes4Immutability policy on a containerYes5YesYesYesContainer soft deleteNoYesNoNoBlob versioning6NoNoYesYesBlob soft deleteNoNoYesYesPoint-in-time restore6NoNoYesYesBlob snapshotNoNoNoYesRoll-your-own solution for copying data to a second account7NoYesYesYes

1 An Azure Resource Manager lock does not protect a container from deletion.
2 Storage account deletion fails if there is at least one container with version-level immutable storage enabled.
3 Container deletion fails if at least one blob exists in the container, regardless of whether policy is locked or unlocked.
4 Overwriting the contents of the current version of the blob creates a new version. An immutability policy protects a version’s metadata from being overwritten.
5 While a legal hold or a locked time-based retention policy is in effect at container scope, the storage account is also protected from deletion.
6 Not currently supported for Data Lake Storage workloads.
7 AzCopy and Azure Data Factory are options that are supported for both Blob Storage and Data Lake Storage workloads. Object replication is supported for Blob Storage workloads only.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is Soft Delete for Containers?

A

Soft delete for containers

Container soft delete protects your data from being accidentally deleted by maintaining the deleted data in the system for a specified period of time. During the retention period, you can restore a soft-deleted container and its contents to the container’s state at the time it was deleted. After the retention period has expired, the container and its contents are permanently deleted.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What are the 3 recommended data protection configurations?

A

Blob soft delete is part of a comprehensive data protection strategy for blob data. For optimal protection for your blob data, Microsoft recommends enabling all of the following data protection features:

  • Container soft delete, to restore a container that has been deleted. To learn how to enable container soft delete, see Enable and manage soft delete for containers.
  • Blob versioning, to automatically maintain previous versions of a blob. When blob versioning is enabled, you can restore an earlier version of a blob to recover your data if it’s erroneously modified or deleted. To learn how to enable blob versioning, see Enable and manage blob versioning.
  • Blob soft delete, to restore a blob, snapshot, or version that has been deleted. To learn how to enable blob soft delete, see Enable and manage soft delete for blobs.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

How does container soft delete works?

A

When you enable container soft delete, you can specify a retention period for deleted containers that is between 1 and 365 days. The default retention period is seven days. During the retention period, you can recover a deleted container by calling the Restore Container operation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Difference between Container Soft Delte and Blob Soft Delete

A

When you restore a container, the container’s blobs and any blob versions and snapshots are also restored. However, you can only use container soft delete to restore blobs if the container itself was deleted. To a restore a deleted blob when its parent container hasn’t been deleted, you must use blob soft delete or blob versioning.

Warning

Container soft delete can restore only whole containers and their contents at the time of deletion. You cannot restore a deleted blob within a container by using container soft delete. Microsoft recommends also enabling blob soft delete and blob versioning to protect individual blobs in a container.

When you restore a container, you must restore it to its original name. If the original name has been used to create a new container, then you will not be able to restore the soft-deleted container.

The following diagram shows how a deleted container can be restored when container soft delete is enabled:

After the retention period has expired, the container is permanently deleted from Azure Storage and can’t be recovered. The clock starts on the retention period at the point that the container is deleted. You can change the retention period at any time, but keep in mind that an updated retention period applies only to newly deleted containers. Previously deleted containers will be permanently deleted based on the retention period that was in effect at the time that the container was deleted.

Disabling container soft delete doesn’t result in permanent deletion of containers that were previously soft-deleted. Any soft-deleted containers will be permanently deleted at the expiration of the retention period that was in effect at the time that the container was deleted.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Container soft delete is available for the following types of storage accounts:

A

Container soft delete is available for the following types of storage accounts:

  • General-purpose v2 and v1 storage accounts
  • Block blob storage accounts
  • Blob storage accounts
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What is Soft delete for blobs?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What is Blob Soft Delete?

A

Blob soft delete protects an individual blob, snapshot, or version from accidental deletes or overwrites by maintaining the deleted data in the system for a specified period of time. During the retention period, you can restore a soft-deleted object to its state at the time it was deleted. After the retention period has expired, the object is permanently deleted.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Explain briefly how blod soft delete works

A

How blob soft delete works

When you enable blob soft delete for a storage account, you specify a retention period for deleted objects of between 1 and 365 days. The retention period indicates how long the data remains available after it’s deleted or overwritten. The clock starts on the retention period as soon as an object is deleted or overwritten.

While the retention period is active, you can restore a deleted blob, together with its snapshots, or a deleted version by calling the Undelete Blob operation. The following diagram shows how a deleted object can be restored when blob soft delete is enabled:

You can change the soft delete retention period at any time. An updated retention period applies only to data that was deleted after the retention period was changed. Any data that was deleted before the retention period was changed is subject to the retention period that was in effect when it was deleted.

Attempting to delete a soft-deleted object doesn’t affect its expiry time.

If you disable blob soft delete, you can continue to access and recover soft-deleted objects in your storage account until the soft delete retention period has elapsed.

Blob versioning is available for general-purpose v2, block blob, and Blob storage accounts. Storage accounts with a hierarchical namespace aren’t currently supported.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

How are deletions handled when soft delete is enabled?

A

How deletions are handled when soft delete is enabled

When blob soft delete is enabled, deleting a blob marks that blob as soft-deleted. No snapshot is created. When the retention period expires, the soft-deleted blob is permanently deleted.

If a blob has snapshots, the blob can’t be deleted unless the snapshots are also deleted. When you delete a blob and its snapshots, both the blob and snapshots are marked as soft-deleted. No new snapshots are created.

You can also delete one or more active snapshots without deleting the base blob. In this case, the snapshot is soft-deleted.

If a directory is deleted in an account that has the hierarchical namespace feature enabled on it, the directory and all its contents are marked as soft-deleted. Only the soft-deleted directory can be accessed. In order to access the contents of the soft-deleted directory, the soft-deleted directory needs to be undeleted first.

Soft-deleted objects are invisible unless they’re explicitly displayed or listed. For more information about how to list soft-deleted objects, see Manage and restore soft-deleted blobs.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

How are overwrites handled when soft delete is enabled?

A

How overwrites are handled when soft delete is enabled

Important

This section doesn’t apply to accounts that have a hierarchical namespace.

Calling an operation such as Put Blob, Put Block List, or Copy Blob overwrites the data in a blob. When blob soft delete is enabled, overwriting a blob automatically creates a soft-deleted snapshot of the blob’s state prior to the write operation. When the retention period expires, the soft-deleted snapshot is permanently deleted.

Soft-deleted snapshots are invisible unless soft-deleted objects are explicitly displayed or listed. For more information about how to list soft-deleted objects, see Manage and restore soft-deleted blobs.

To protect a copy operation, blob soft delete must be enabled for the destination storage account.

Blob soft delete doesn’t protect against operations to write blob metadata or properties. No soft-deleted snapshot is created when a blob’s metadata or properties are updated.

Blob soft delete doesn’t afford overwrite protection for blobs in the archive tier. If a blob in the archive tier is overwritten with a new blob in any tier, then the overwritten blob is permanently deleted.

For premium storage accounts, soft-deleted snapshots don’t count toward the per-blob limit of 100 snapshots.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Blob soft delete and versioning, how does it work?

A

If blob versioning and blob soft delete are both enabled for a storage account, then overwriting a blob automatically creates a new previous version that reflects the blob’s state before the write operation. The new version isn’t soft-deleted and isn’t removed when the soft-delete retention period expires. No soft-deleted snapshots are created.

If blob versioning and blob soft delete are both enabled for a storage account, then when you delete a blob, the current version of the blob becomes a previous version, and there’s no longer a current version. No new version is created and no soft-deleted snapshots are created. All previous versions are retained until they are explicitly deleted, either with a direct delete operation or via a lifecycle management policy.

Enabling soft delete and versioning together protects previous blob versions as well as current versions from deletion. When soft delete is enabled, explicitly deleting a previous version creates a soft-deleted version that is retained until the soft-delete retention period elapses. After the soft-delete retention period has elapsed, the soft-deleted blob version is permanently deleted.

You can use the Undelete Blob operation to restore soft-deleted versions during the soft-delete retention period. The Undelete Blob operation always restores all soft-deleted versions of the blob. It isn’t possible to restore only a single soft-deleted version.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Microsoft recommends enabling both xxx and xxx for your storage accounts for optimal data protection

A

versioning and blob soft delete

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What is Versioning in Storage Data Protection?

A

Blob versioning

You can enable Blob storage versioning to automatically maintain previous versions of an object. When blob versioning is enabled, you can access earlier versions of a blob to recover your data if it is modified or deleted.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Explain briefly how Versioning in Storagte Data Protection works

A

How blob versioning works

A version captures the state of a blob at a given point in time. Each version is identified with a version ID. When blob versioning is enabled for a storage account, Azure Storage automatically creates a new version with a unique ID when a blob is first created and each time that the blob is subsequently modified.

A version ID can identify the current version or a previous version. A blob can have only one current version at a time.

When you create a new blob, a single version exists, and that version is the current version. When you modify an existing blob, the current version becomes a previous version. A new version is created to capture the updated state, and that new version is the current version. When you delete a blob, the current version of the blob becomes a previous version, and there is no longer a current version. Any previous versions of the blob persist.

The following diagram shows how versions are created on write operations, and how a previous version may be promoted to be the current version:

Blob versions are immutable. You cannot modify the content or metadata of an existing blob version.

Having a large number of versions per blob can increase the latency for blob listing operations. Microsoft recommends maintaining fewer than 1000 versions per blob. You can use lifecycle management to automatically delete old versions. For more information about lifecycle management, see Optimize costs by automating Azure Blob Storage access tiers.

Blob versioning is available for standard general-purpose v2, premium block blob, and legacy Blob storage accounts. Storage accounts with a hierarchical namespace enabled for use with Azure Data Lake Storage Gen2 are not currently supported.

17
Q

Explain briefly Versioning on write operations

A

Versioning on write operations

When blob versioning is turned on, each write operation to a blob creates a new version. Write operations include Put Blob, Put Block List, Copy Blob, and Set Blob Metadata.

If the write operation creates a new blob, then the resulting blob is the current version of the blob. If the write operation modifies an existing blob, then the current version becomes a previous version, and a new current version is created to capture the updated blob.

The following diagram shows how write operations affect blob versions. For simplicity, the diagrams shown in this article display the version ID as a simple integer value. In reality, the version ID is a timestamp. The current version is shown in blue, and previous versions are shown in gray.

Note

A blob that was created prior to versioning being enabled for the storage account does not have a version ID. When that blob is modified, the modified blob becomes the current version, and a version is created to save the blob’s state before the update. The version is assigned a version ID that is its creation time.

When blob versioning is enabled for a storage account, all write operations on block blobs trigger the creation of a new version, with the exception of the Put Block operation.

For page blobs and append blobs, only a subset of write operations trigger the creation of a version. These operations include:

The following operations do not trigger the creation of a new version. To capture changes from those operations, take a manual snapshot:

All versions of a blob must be of the same blob type. If a blob has previous versions, you cannot overwrite a blob of one type with another type unless you first delete the blob and all of its versions.

18
Q

Explain brielfy Versioning on delete operations

A

Versioning on delete operations

When you call the Delete Blob operation without specifying a version ID, the current version becomes a previous version, and there is no longer a current version. All existing previous versions of the blob are preserved.

The following diagram shows the effect of a delete operation on a versioned blob:

To delete a specific version of a blob, provide the ID for that version on the delete operation. If blob soft delete is also enabled for the storage account, the version is maintained in the system until the soft delete retention period elapses.

Writing new data to the blob creates a new current version of the blob. Any existing versions are unaffected, as shown in the following diagram.

19
Q

Disabling blob versioning xxxxxxxx existing blobs, versions, or snapshots….

A

Disabling blob versioning does not delete existing blobs, versions, or snapshots. When you turn off blob versioning, any existing versions remain accessible in your storage account. No new versions are subsequently created.

20
Q

What happens after blob versioning is disabled?

A

After versioning is disabled, modifying the current version creates a blob that is not a version. All subsequent updates to the blob will overwrite its data without saving the previous state. All existing versions persist as previous versions.

You can read or delete versions using the version ID after versioning is disabled. You can also list a blob’s versions after versioning is disabled.

The following diagram shows how modifying a blob after versioning is disabled creates a blob that is not versioned. Any existing versions associated with the blob persist.

21
Q

What is Point-in-time restore for block blobs?

A

Point-in-time restore for block blobs

Point-in-time restore provides protection against accidental deletion or corruption by enabling you to restore block blob data to an earlier state. Point-in-time restore is useful in scenarios where a user or application accidentally deletes data or where an application error corrupts data. Point-in-time restore also enables testing scenarios that require reverting a data set to a known state before running further tests.

Point-in-time restore is supported for general-purpose v2 storage accounts in the standard performance tier only. Only data in the hot and cool access tiers can be restored with point-in-time restore.

To learn how to enable point-in-time restore for a storage account, see Perform a point-in-time restore on block blob data.

22
Q

What are blob snapshots?

A

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.

For example, if a page blob URI is http://storagesample.core.blob.windows.net/mydrives/myvhd,

the snapshot URI is similar to http://storagesample.core.blob.windows.net/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z.

Note

All snapshots share the base blob’s URI. The only distinction between the base blob and the snapshot is the appended DateTime value.

A blob can have any number of snapshots. Snapshots persist until they are explicitly deleted, either independently or as part of a Delete Blob operation for the base blob. You can enumerate the snapshots associated with the base blob to track your current snapshots.

When you create a snapshot of a blob, the blob’s system properties are copied to the snapshot with the same values. 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.

Any leases associated with the base blob do not affect the snapshot. You cannot acquire a lease on a snapshot.

You can create a snapshot of a blob in the Hot or Cool tier. Snapshots on blobs in the Archive tier are not supported.

A VHD file is used to store the current information and status for a VM disk. You can detach a disk from within the VM or shut down the VM, and then take a snapshot of its VHD file. You can use that snapshot file later to retrieve the VHD file at that point in time and recreate the VM.

Azure DP-203 Certification (14 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions