We have an Azure Blob storage account which is geo redundant. For a reason we can't explain some files have been deleted over the night, we suspect an issue with the file provider we are using (This is an Umbraco application using https://github.com/idseefeld/UmbracoAzureBlobStorage).
We updated the package to the latest version and we hope it does not happen again. However, is it possible to retrieve the files from a secondary location, is there any snapshots?
However, is it possible to retrieve the files from a secondary
location, is there any snapshots?
If the file is deleted from the primary location, in the next geo-replication cycle it will be removed from secondary location as well. So I don't think you will be able to recover the files from secondary location. You may find this blog post useful: https://www.simple-talk.com/cloud/cloud-data/cloud-storage-replication-is-not-backup/.
One possible solution would be to reach out to Azure support and ask them if they can restore the deleted files for you. Typically if you reach out to them soon after the accidental deletes, they would be able to restore the files for you.
Related
Is there a way to restore a Cosmos DB container after I accidentally deleted it? I just confused the live environment with a local Cosmos DB emulator.
When I go to the Settings - Backup & Restore it says:
Your account is on periodic backup mode. You can now change to continuous mode for a better backup and restore experience. Change to continuous mode
Does it mean that it is still somehow possible to revert the delete operation? But I can not find an option to revert the deletion.
For Cosmos DB containers configured with periodic backup (as you've mentioned is the case here), Microsoft has very prescriptive guidance on how to potentially restore the data. TL;DR - you should file a support request with the Microsoft Azure support team as soon as is feasible (being sure to include all information they need as indicated in the linked article). Their word choice in the linked document strongly indicates a time-sensitive aspect to this, and a relatively short window in which you need to lodge such a request to ensure the best possible outcome.
I've reproduced the relevant bits from the linked documentation below for convenience/posterity (emphases mine):
Request data restore from a backup
If you accidentally delete your
database or a container, you can file a support ticket or call the
Azure support to restore the data from automatic online backups. Azure
support is available for selected plans only such as Standard,
Developer, and plans higher than those. Azure support is not available
with Basic plan.
To restore a specific snapshot of the backup, Azure Cosmos DB requires
that the data is available during the backup cycle for that snapshot.
You should have the following details before requesting a restore:
Have your subscription ID ready.
Based on how your data was accidentally deleted or modified, you
should prepare to have additional information. It is advised that you
have the information available ahead to minimize the back-and-forth
that can be detrimental in some time sensitive cases.
If the entire Azure Cosmos DB account is deleted, you need to provide
the name of the deleted account. If you create another account with
the same name as the deleted account, share that with the support team
because it helps to determine the right account to choose. It's
recommended to file different support tickets for each deleted account
because it minimizes the confusion for the state of restore.
If one or more databases are deleted, you should provide the Azure
Cosmos DB account, and the Azure Cosmos DB database names and specify
if a new database with the same name exists.
If one or more containers are deleted, you should provide the Azure
Cosmos DB account name, database names, and the container names. And
specify if a container with the same name exists.
If you have accidentally deleted or corrupted your data, you should
contact Azure support within 8 hours so that the Azure Cosmos DB team
can help you restore the data from the backups. Before you create a
support request to restore the data, make sure to increase the backup
retention for your account to at least seven days. It’s best to
increase your retention within 8 hours of this event. This way the
Azure Cosmos DB support team will have enough time to restore your
account.
In addition to Azure Cosmos DB account name, database names, container
names, you should specify the point in time to which the data can be
restored to. It is important to be as precise as possible to help us
determine the best available backups at that time. It is also
important to specify the time in UTC.
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
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
My Azure WebApp stores data in Azure Storage Tables and Blob storage.
There is a backup functionnality, but as I understood it just does not support azure tables/blobs... however I would like to automatically backup my tables to protect against accidental data corruption by users or by a software issue...
I would like to backup MyProdTables in MyBackupBlob container. Is there away to do it actually?
I read something about AZCopy, but it seems working with virtual machine's hard drives, but we have the WebApplication as a Service, so I am not sure that it will work in our case...
Edit: There is a partial (negative) MS feedback on the question, as mentioned in this answer, but it focused rather on migration and entire account snapshots. I am rather focused on the table storage, and maybe even the possibility of backuping individual tables... is strange that is nothing possible in this field, cause MS Azure Storage Explorer can easily backup the tables as CSV files.
There is no built-in backup feature for blobs and tables, as you've surmised. However: blobs do offer snapshots (a point-in-time snapshot may be taken at any time).
There are also Shared Access Signatures (and Policies) to limit exposure to your storage. And you can even protect the storage account itself from deletion.
As for AzCopy: that has nothing to do with VM disks. That's specifically for moving content in and out of blobs and tables.
I wonder is there's an inbuilt way in azure to backup a blob account, or just a container if that can't be done. Looked into azure backup service but can't find the option for doing it, just options to backup VM.
Alternatively I can write my custom back up strategy, but not sure if it's the case that I can't find that option inbuilt.
Thanks,
There is no blob backup facility. You'll need to make your own backups (e.g. making copies of blobs, either to the same storage account or a different one). You can take snapshots, but as #Gaurav points out in comments, snapshots are tied to the original blob, so if you delete the original, you delete the snapshots.
I answered a similar question regarding backups and Table Storage, as well, here.