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).
Related
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 .
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 have a Windows VM that was built on the old "classic" model which I would like to change to the ARM model. I have used the automated methods however this doesn't give me the control I desire (the names of all the components are messy).
I have deleted the original VM leaving only the VHD in the storage account.
I have created a Managed Disk (MD) using the VHD as the source blob.
I have created a VM using the MD
When I look at the MD in the Azure portal, it still references the "Source Blob" but i'm not sure if this means the MD is still reliant on the blob and storage account or if it's just legacy/reference info.
What I need to know is, can I delete the original storage account containing the VHD now that I have a MD?
Take a backup first and then delete the backup
We use some
block blobs to store some durable resources and then
page blobs to store event data
We need to backup the blobs, so I tried to use AzCopy. It works ok on my dev machine, but it fails on other slow machine with error "The remote server returned an error: (412) The condition specified using HTTP conditional header(s) is not met.." almost every time.
We write to page blobs quite often (might be up to several times in a second, but this is not so common case), so this might be the reason.
Is there any better strategy how to backup the changing blobs? Or is there any way how to bypass the problem with ETag used by AzCopy?
A changed ETag will always halt a copy, since a changing ETag signifies that the source has changed.
The general approach to blob backup is subjective, but objectively:
blob copies within Azure itself, in the same region, from Storage account to Storage account, are going to be significantly faster than trying to copy a blob to an on-premises location (due to general Internet latency) or even copying from storage account to local disk on a VM.
Blobs support snapshots (which take place relatively instantly). If you create a snapshot, the snapshot remains unchanged, allowing you to then execute a copy operation against the snapshot instead of the actual blob itself (using AzCopy in your case) without fear of the source data changing during the copy. Note: You can create as many snapshots as you want; just be careful, since storage size grows as the underlying original blob changes.
I have a VHD in a container which was mounted by an instance (a DotNetNuke accelerator). But now the instance is stopped so the VHD is not mounted anymore.
The problem is I can't rename this VHD with any UI client. "CloudBerry Explorer for Azure Blob Storage" shows an error when I try to rename it of
This operation is not permitted because the blob has snapshots.
I tried to list snapshots in VisualStudio but it only returns the blob's name...
I tried to mount the VHD in an instance and create a file and it works!?
I'm going crazy. :)
I've managed to remove blob which has snapshots by using Microsoft Azure Storage Explorer. Steps are:
You navigate to the blob in question
Right click -> Manage Snapshots
Delete all the snapshots and the blob will disappear also
The error is accurate. If you get that, it means the blob actually has snapshots. When you mount a blob you are most likely mounting the current version and not a past snapshot. You can enumerate the snapshots using the REST API (use the 'include=snapshots option) to prove this to yourself.
If you really want to delete the blob with minimal hassle, I would suggest using https://www.myazurestorage.com (safe site from Microsoft DPE). It will enumerate your snapshots automatically and allow you to delete them. Once they are all deleted, you can also delete the blob.