how to backup or recovery classic storage account if upgrade to ARM fail

Question

Hi, my team uses a classic storage account, and we plan to upgrade to ARM

but I'm fear of encountering unexpected problems when upgrading in the production environment, I also find Rollback is not supported after the resources have been successfully migrated through the commit operation. from Frequently asked questions about classic to Azure Resource Manager migration - Azure Virtual Machines
so we have some questions want to ask:

1. our classic storage account contains blobs, queues, and tables, how can I backup these data before I upgrade to ARM
2. After I upgrade the classic storage account to ARM, Do I need to change the application settings?
3. Does Azure provide any solution to protect the upgrade workflow? if we encounter some issue when upgrading or the generated storage account has some error, how can I recover it? Because it is a production environment, we need to treat it carefully

Answer 1

Hello Guan Yingjie,

Thank you for posting your query here!

For backing up your Azure Storage Account:

You may configure and manage backup for Azure Blobs using Azure Backup.

For table storage you can refer Copy data to and from Azure Table storage by using Azure Data Factory

https://techcommunity.microsoft.com/t5/azure-paas-blog/copying-azure-table-storage-using-azure-data-factory-adf/ba-p/3062401

However, storage queues are similar to service bus queue. The messages are not designed to store permanent like blobs/files. Once the receiver processes the messages, they would be deleted. I don't think you can move any data from the queue only thing that would make sense is to create queues with the same names and point your applications to a new storage endpoint. A workaround can be done using a custom application.

1. List all queues from the source.
2. Create queues with the same names in the destination.
3. Read every message from the source and write them to the destination.

Coming to the migration process, it involves a "Prepare" step, which creates a new general-purpose v1 storage account in the Azure Resource Manager (ARM) model. During this step, you can simulate the transformation and compare the classic storage account to the new one. If satisfied, you can commit the migration, permanently deleting the classic account. If issues arise, you can choose to abort the migration, leaving the classic account unaffected.

Before you commit the migration, we recommend that you update your client applications to use the Azure Storage resource provider APIs. You can then test your updated code against the migrated storage account, while the classic account still exists.

Committing the migration is an idempotent operation. If it fails, retry the operation. If it continues to fail, you may need to create a support ticket.

During the migration process, Microsoft translates the representation of the storage account resource from the classic deployment model to the Azure Resource Manager deployment model. As a result, you need to use new tools, APIs, and SDKs to manage your storage accounts and related resources after the migration.

However, the data plane is unaffected by migration from the classic deployment model to the Azure Resource Manager model. Your applications can continue to read and write data from the storage account throughout the migration process, and you can access the new account the same way before, there is no need to do any reconfigures.

Your storage account URL and keys will not be changed and even at the period of migrating, your storage service is online. Basically, it is a seamless migration.

For further details kindly refer: https://learn.microsoft.com/en-us/azure/storage/common/classic-account-migration-process
https://learn.microsoft.com/en-us/azure/storage/common/classic-account-migrate

Please let us know if you have any further queries. I’m happy to assist you further.

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.