I have enabled soft delete for blobs, containers as well as point in time restore on my storage account. If I delete my blobs, container or even the entire storage account, it can still be restored it seems. So what does the new Operational Backup for Azure Blobs actually add?
https://learn.microsoft.com/en-us/azure/backup/blob-backup-overview
https://learn.microsoft.com/en-us/azure/storage/blobs/soft-delete-blob-overview
Soft delete protection is limited than Operational back up and has to enable additional settings in
order for additional protection.
But it is useful when only individual blobs are to be protected
instead of storage account level protection.
As You can use blob soft delete only to restore an individual blob,
snapshot, directory (in a hierarchical namespace) or version. To
restore a container and its contents, container soft delete must also
be enabled for the storage account.
Operational backup is configured and managed at the storage account level, and applies to all block blobs within the storage
account and uses a backup policy and can select to store multiple
storage accounts at a time or Select containers or Selected prefix
matches to restore a subset of blobs.
It does the Continuous back up instead of x no of back ups i.e;
you don’t need to schedule any backups and is stored within the
storage account local back up.
Operational backup prevents the blobs from deleting and overwriting as it enforces delete locks on protected blobs and also backs up even if it is not deleted where as soft delete doesn’t stop from deletion but the blobs deleted can be restored and retained it till a period of time .
Data loss is less in Operational back up as Blob point-in-time restore allows restoring blob data to an earlier state. This, in turn, uses soft delete, change feed and blob versioning to retain data for the **specified duration**.
Blob soft delete The clock starts on the retention period as soon as an object is deleted or overwritten .So you can restore a soft-deleted object to its state only at the time it was deleted.
Soft delete does not afford overwrite protection for blobs in the
archive tier. Versioning is not supported for accounts that have a
hierarchical namespace.
For the blobs whose operational back up is enabled and has already soft delete enabled has its back up for extra 5 days if retention policy of op backup is less than soft delete time.Else it will remain unchanged.
Soft delete allows to undelete the blob before restore time after it is deleted or overwritten. Where as operational back up doesn’t allow deletion itself and monitoring is possible with central back up store management.
Note: Operational backup supports operations on block blobs only and
operations on containers can’t be restored. If you delete a container
from the storage account by calling the Delete Container operation,
that container can’t be restored with a restore operation. It’s
suggested you enable soft delete to enhance data protection and
recovery.
So soft delete can be used for minor protection for blob level with selective versioning changes and additional container protection where as operational backup is all together in single pack with extra protection which restores the version ,overwrites or deletion at whatever time you set it .
Related
Snapshots cause a lot of cost. In some of my storage accounts I don't need them.
But I can't find a place where I can turn it off.
How can I disable snapshots completely from a storage account in Azure?
It's not a feature that can be turned off completely; Although to make snapshots you would have to explicitly write code to create them, unless you have soft delete enabled. In that case an overwrite will create a snapshot in deleted state but it'll be automatically removed once the soft delete time expires.
Another option would be the lifecycle management. There you can make a rule to automatically delete snapshots once they are more than X days old. That check runs daily so the storage costs are only extended by a few days.
Navigate to your storage account's blob and look for your snapshots under Snapshots. From there, you may manage them.
https://i.imgur.com/P2LRras.png
If you've already established a resource for it, go to that resource's page and delete it.
https://i.imgur.com/qLvFe3v.png
I have a Azure Storage Account and I have enabled soft delete for blobs.
Is is possible to call instant deletion (ignore the soft deletion period) for some specific blobs?
I am using Azure.Storage.Blob v12.7.0, but DeleteBlobIfExistsAsync or DeleteAsync have no extra parameters that I can use.
Unfortunately at the moment there is no built-in feature to permanent delete blobs with enabled soft-delete option (ignore the soft deletion period).
https://feedback.azure.com/forums/217298-storage/suggestions/35076274-permanent-deletion-of-soft-deleted-blobs-gdpr
There is a workaround:
Disable the soft-deleted option.
Select the Blob Containers via Microsoft Azure Storage Explorer, choose Active and deleted blobs.
Undelete the deleted blobs and then remove it again
Then blob is permanently deleted
This approach is described here
https://github.com/MicrosoftDocs/azure-docs/issues/13064
You can automate the above workaround with Azure.Storage.Blob v12.7.0
Why would I need to create a blob snapshot and incur additional cost if Azure already provides GRS(Geo redundant storage) or ZRS (Zone redundant storage)?
Redundancy (ZRS/GRS/RAGRS) provides means to achieve high availability of your resources (blobs in your scenario). By enabling redundancy you are ensuring that a copy of your blob is available in another region/zone in case primary region/zone is not available. It also ensures against data corruption of the primary blob.
When you take a snapshot of your blob, a readonly copy of that blob in its current state is created and stored. If needed, you can restore a blob from a snapshot. This scenario is well suited if you want to store different versions of the same blob.
However, please keep in mind that neither redundancy nor snapshot is backup because if you delete base blob, all the snapshots associated with that blob are deleted and all the copies of that blob available in other zones/regions are deleted as well.
I guess you need to understand the difference between Backup and Redundancy.
Backups make sure if something is lost, corrupted or stolen, that a copy of the data is available at your disposal.
Redundancy makes sure that if something fails—your computer fails, a drive gets fried, or a server freezes and you are able to work regardless of the problem. Redundancy means that all your changes are replicated to another location. In case of a failover, your slave can theoretically function as a master and serve the (hopefully) latest state of your file system.
You could also turn soft delete on. That would keep a copy of every blob for every change made to it, even if someone deletes it. Then you set the retention period for those blobs so they would be automatically removed after some period of time.
https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-soft-delete
I am thinking of using Azure Blob Storage for document management system which I am developing. All Blobs ( images,videos, word/excel/pdf etc) will be stored in Azure Blob storage. As I understand, I need to create container and these files can be stored within the container.
I would like to know how to safeguard against accidental/malicious deletion of the container. If a container is deleted, all the files it contains will be lost. I am trying to figure out how to put backup and recovery mechanism in place for my storage account so that it is always guaranteed that if something happens to a container, I can recover files inside it.
Is there any way provided by Microsoft Azure for such backup and recovery or Do I need explicitly write a code in such a way that files are stored in two separate Blob storage account.
Anyone with access to your storage account's key (primary or secondary; there are two keys for a storage account) can manipulate the storage account in any way they see fit. The only way to ensure nothing happens? Don't give anyone access to the key(s). If you place the storage account within a resource group that only you have permissions on, you'll at least prevent others with access to the subscription from discovering the storage account and accessing it.
Within the subscription itself, you can place a lock on the actual resource (the storage account), so that nobody with access to the subscription accidentally deletes the entire storage account.
Note: with storage account keys, you do have the ability to regenerate the keys at any time. So if you ever suspected a key was compromised, you can perform a re-gen action.
Backups
There are several backup solutions offered for blob storage in case if containers get deleted.more product info can be found here:https://azure.microsoft.com/en-us/services/backup/
Redundancy
If you are concerned about availability, "The data in your Microsoft Azure storage account is always replicated to ensure durability and high availability. Replication copies your data, either within the same data center, or to a second data center, depending on which replication option you choose." , there are several replication options:
Locally redundant storage (LRS)
Zone-redundant storage (ZRS)
Geo-redundant storage (GRS)
Read-access geo-redundant storage (RA-GRS)
More details can be found here:
https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy
Managing Access
Finally, managing access to your storage account would be the best way to secure and ensure you'll avoid any loss on your data. You can provide read access only if you don't want anyone to delete files,folders etc.. through the use of SAS: Shared Access Signatures, allows you to create policies and provide access based on Read, Write, List, Delete, etc.. A quick GIF demo can be seen here: https://azure.microsoft.com/en-us/updates/manage-stored-access-policies-for-storage-accounts-from-within-the-azure-portal/
We are using blob to store documents and for documents management.
To prevent deletion of the blob, you can now enable soft deletion as described in here:
https://azure.microsoft.com/en-us/blog/soft-delete-for-azure-storage-blobs-ga/
You can also create your own automation around powershell,azcopy to do incremental and full backups.
The last element would be to use RA-GRS blobs where you can read from a secondary blob in read mode in another region in case the data center goes down.
Designing Highly Available Applications using RA-GRS
https://learn.microsoft.com/en-us/azure/storage/common/storage-designing-ha-apps-with-ragrs?toc=%2fazure%2fstorage%2fqueues%2ftoc.json
Use Microsoft's Azure Storage Explorer. It will allow you to download the full contents of blob containers including folders and subfolders with blobs. Conversely, you can upload to containers in the same way. Simple and free!
I used CloudXplorer to create a snapshot on the VHD of a VM I was doing some installs on. The installs went okay, so is it okay to delete the snapshots or do I need to somehow merge them in to ensure I can backup my current VM state?
Snapshots are just a point-in-time representation of a blob (in your case, a page blob storing your vhd). It's read-only, and it's disposable. If a page in the vhd's page blob is changed, then a new page is created for the snapshot, to represent the original state of the blob. Once you delete the snapshot, the list of pages, along with any created pages to preserve the snapshot's state, are deleted (and with no impact on the original blob).
Note that you won't be able to delete the original blob until you first delete all of its snapshots (and you can also delete blob+snapshots at once).