I suggest you ...

storage stamp option

Provide the option to define storage accounts to use the same of different storage stamps. we have scenarios where the ability to define same or different stamps make an huge impact in the end result.

52 votes
Sign in
Sign in with: oidc
Signed in as (Sign out)
You have left! (?) (thinking…)
Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: oidc
Signed in as (Sign out)
  • Chris commented  ·   ·  Flag as inappropriate

    This is especially relevant when dealing with ReadAccessible-GeoReplicatedStorage for disaster recovery.

    If there are problems with a region which don't trigger GRS Failover we will likely be copying many TB of data from the RO -secondary storage accounts to new RW storage accounts. It would be a big benefit to use same-stamp snapshot copies for these operations.

  • Isa Hunter commented  ·   ·  Flag as inappropriate

    @ Tim Sherburn: How do you validate stamp assignment? Powershell, CLI, Rest API? I have the same requirement and there's no documentation on how to do this.

  • Peter van Noort commented  ·   ·  Flag as inappropriate

    Agreed. We have scenarios where we prefer to create storage accounts on the SAME stamps, so that BLOB copy operations can be near instantaneous (shadow copy) instead of minutes to hours (cross Stamp copy)

    For this we would require something like a "-Samestamp <storageaccount>" parameter

  • Tim Sherburn commented  ·   ·  Flag as inappropriate

    Agreed! We have scenarios where we need to ensure each storage account in on a unique stamp. Currently, in order to do this, we have to basically take our chances during account creation, validate stamp assignment, and create a new one if it happens to fall on a previously used stamp. We should be able to designate if a created Storage account MUST be on a unique stamp for a given Subscription ID.

Feedback and Knowledge Base