Skip to main content

Object Replication for Premium Block Blob Storage (Public Preview)

Microsoft has recently announced the Object Replication for Premium Block Blob Storage. This feature is in public review. Let look at why we need this and what are the benefits of having them, Specially how to setup this one

Diagram showing how object replication works

Object replication asynchronously copies block blobs in a container according to rules that you configure. The contents of the blob, any versions associated with the blob, and the blob's metadata and properties are all copied from the source container to the destination container

few things to note

  • Object replication does not support blob snapshots
  • Object replication is supported when the source and destination accounts are in the hot or cool tier.

Before you proceed you need to know following

  1. Replication Policies - Replication policy is an object that holds replication rules in the target region. You need to create the replication policies on the destination side and associate them with the source.
    • Source can replicate to multiple destination (in the same target account) using a single policy
    • Source account can replicate to maximum of two accounts
  2. Replication Rules - Replication Policies - Replication policy is an object that holds replication rules in the target region. You need to create the replication policies on the destination side and associate them with the source.
    • Each replication rule defines a single source and destination container
    • You can specify up to 10 replication rules for each replication policy

How to Guide

Following is my source and destination

Image1: Source and Destination

Browse to the source storage account and create the policy

Once you select the above you will get into the below page which where you need to define the source and destination containers

Note : A container pair consists of a container in the source account and a container in the destination account. Objects in the source container are copied over to the destination container according to the replication rule. You can optionally filter which objects are copied by specifying a prefix match and by copying objects created only after a specified date and time

replication rules

During the process you can specify the copy over status which mean what will be getting copied to the target. if you select custom you can specify a date range

Once you done hit save and apply

Once done you can see the changes in both source and destination storage accounts

Because block blob data is replicated asynchronously, the source account and destination account are not immediately in sync. There's currently no SLA on how long it takes to replicate data to the destination account.

For more details head out to the MS documentation which will have up to date features


Popular posts from this blog

Deploying an Automation Account with a Runbook and Schedule Using Bicep

Introduction Automation is a key component in many organizations' cloud strategy. Azure Automation allows you to automate the creation, deployment, and management of resources in your Azure environment. In this post, we will walk through the process of deploying an Automation Account with a Runbook and Schedule using Bicep, a new domain-specific language for deploying Azure resources. Intention My intention at the  end is to run a PowerShell  script to start and shutdown Azure VMs based on tag values. PowerShell  script that I have used is from below l ink.  And two  of me   collogue s ( Michael Turnley   and Saudh Mohomad helped to modify the  PowerShell  script. Prerequisites Before we begin, you will need the following: An Azure subscription The Azure CLI installed on your machine. The Azure Bicep extension for the Azure CLI Creating the Automation Account The first step in deploying an Automation Account with a Runbook and Schedule is to create the Aut

Migrating Azure DevOps Variable Groups

Howdy Folks, I was working on an application modernization project. And there was a requirement to migrate application deployments from one project to another in Azure DevOps. deployment pipelines were heavily dependent on variable groups. So, we wanted to migrate these variables group to the new project. Couldn't find any solutions in internet for this, so came up with the below scripts. You can grab the scripts from the below GitHub URL. DaniduWeerasinghe911/Migrate-Azure-DevOps-Variable-Groups: This Repo Include PowerShell Scripts relating to Migrating Azure DevOps Variable Groups ( Azure DevOps Variable Groups Azure DevOps Variable Groups are a way to store and manage sets of variables that can be used across multiple pipelines in Azure DevOps. These variables can include secrets, connection strings, and other sensitive information that is needed for builds and releases. Variable Groups provide a centralized way to manage these variables and ensure that they are cons

Securing Azure Services with Fetian FIDO

Hey Folks  Here again with another security topic with Fetian Fido. And once again Fetian devices proved their excellent quality and stability. For this I choose Fetian K33 -  AllinPass FIDO Security Key – FEITIAN ( and  K39 -  Single-button FIDO Security Keys | FEITIAN ( Use case  In an organization following changes needs to be implemented.  1. Update the password policy 2. Update the user session time out to 30 minutes Once these changes being implemented, the following issues need to be addressed 1. Users' complaint new passwords need to be so long 2. Users complain sessions time out makes them work so much slower with the longer passwords 3. Etc... Solution  One of my friends reached out to me to help solve this problem. All I could think of was using passwordless auth with FIDO devices. We have decided to use Fido2 keys for better security and flexibility for the users. The FIDO (Fast IDentity Online) Alliance helps to promote open authentication stand