I have created the Azure Cosmos DB Account in West US region. But, for some reasons, I would like to move it to East US. Is this possible?
Moving the ARM tracked resource (i.e. the account) is not currently supported and today customers will need to create a new account and manually migrate data.
There is a doc here that describes the steps to do this.
PS: This capability will be available in the future.
Related
Team,
When i migrated the storage account from one subscription to another using a migration tool(mig-az) it did not migrate the underlying tables, queues and blobs storage. Is that an inherent nature of migration?
is there a way to copy over the tables to the storage account in newer subscription? When doing the copy, would there be any downtime to the resources in the older subscription? Would the data in the older sub be lost?
Having a brief read of the Github page for Mig-Az, this seems to be a tool that just creates ARM templates from existing resources and allows you to apply them elsewhere. If this is the case, then it's only going to create a storage account, not any of the underlying resources or data, this is the nature of ARM templates.
If both your subscriptions are under the same Azure AD tenant then you can just move them using the Azure portal, there is an option in the resource group to move resources. See here for instructions.
If the subscriptions are under different tenants then you are going to need to manually move your data.
Is there a feature in Azure to move blobs in Hot/Cool tiers to Archive automatically if they haven't been used in a period of time?
For example, if I have a blob stored in Archive, I access it by rehydrating it to Hot/Cool. Once I am done, is there a way Azure can automatically downtier it?
Moving to another tier not accessed blobs is possible using native functionality but for the moment this is limited to France Central, Canada East, and Canada Central as the feature is in preview.
In order to use the Last accessed option, select Access tracking enabled on the Lifecycle Management page in the Azure portal.
And then define a rule based on the Last accessed
More details you may find here
This is now generally available as of 2019 from Microsoft. Now you can -
Automatically change the blob tier after N days.
Automatically remove the blob after N days.
Azure Blob lifecycle management overview
All tier changes must be performed by you; there is no automatic tier-change method built-in. You'll need to make a specific call to set the tier for each tier change (note - I pointed to the REST API, but various language-specific SDKs wrap the call as well).
Please see this Azure Feedback question for updates on automated object lifecycle policies for Azure Storage Blobs (as well as a description of a workaround using Logic Apps). The question pertains to blob TTL, but tiering policies will also be possible with both the workaround and ultimately using the policy framework.
We have SQL Azure databases currently in the SouthEast Asia region under an older subscription (Subscription 1).
My questions are:
Is there a way to migrate the database server & associated databases into a new Azure subscription (Subscription 2) and into the SouthEast Australia region, while maintaining the same server name?
Will this migration change the existing schema, i.e. will it add tracking columns to the existing database tables?
Thanks in advance,
Shailen
Yes, you can do this using the SQL Database REST API's. There is a sample of this here.
I have more than one Azure subscriptions, one for myself and others for clients. Can I change the subscription for one of my storage accounts so that it's associated to one of my other subscriptions?
Cannot find a way to do it through the Azure Management Portal. Perhaps it can be done with PowerShell?
Thanks!
I think you're best approach would be to contact Microsoft Windows Azure support to see if they can help.
I wanted to post some updated guidance in case anyone else runs into this issue. To move a storage account, you can do it easily for V1 or V2. You can move Classic Storage but its not easy and I would suggest upgrading it to the newer ARM based V1 or V2 storage account. This assume within the region. Moving to a subscription in another region is a different matter. This answer is probably very different that it would have been back in 2014.
Move Azure Storage account to another region
Move classic storage
Move V1 or V2 Storage
Move to another region
Migrate classic storage to ARM
I'm trying to get up-and-going with Windows Azure. I understand that I need to create a "Storage Account". However, what I'm confused about is, how I should set it up. For instance, my Azure subscription is set to my company name. I intend to have multiple ASP.NET web applications (web roles) associated with my subscription. Each web application will have its own database.
My question is, should each web application have its own storage account? Or should only one storage account be used for all of my projects?
Thank you!
There's no one way to answer this, but here are some thoughts to help your decision:
Each storage account is limited to 100TB. If you feel that you will push the limits of this across multiple websites, then create multiple storage accounts for sure.
To make billing easier, I'd suggest separate storage accounts
Storage accounts have an SLA of a few thousand transactions per second across the entire storage account. For performance purposes, it's probably better to have separate storage accounts
Consider putting your diagnostic data in a separate storage account. This way, you can safely give your Storage Account key to a 3rd-party like ParaLeap (creators of AzureWatch) for monitoring your app, while not giving away the key to real customer data, for instance.
If you need more than 5 storage accounts, you'll need to contact Customer Support to increase this number.
Windows Azure Storage server is for simple blob storage. This is for when your app needs a file store. Any application, not just Azure web roles, can target a storage service. It's kind of like Amazon S3 if you're familiar with that.
Storage services are not required to run Azure applications. You just need a "compute" instance.