Moving backup replication core repo to Azure

We have one main office with the main core.  We have decommissioned our secondary site where our backup core was which is now up and running in the main office, for now.  I'm trying to figure out how to push the backups to Azure to retain the offsite tertiary backups.  We don't currently have an Azure VM environment built to create a new server core up there so in the meantime, I'm looking to push our backups to the Azure blob we do have today.  This seems like the fastest path to gain peace of mind until we can build out Azure to accommodate a core, or just move the existing backup core there. 

I have created the Azure repository in RR.  Is it possible to change the repository being used of each machine without having to delete and recreate the replication?  I'm afraid it will delete the existing backups although I believe it will just archive them into 'recovery points only' status.

  • Azure repository feature is meant for replication, not for backups as the compression and deduplication process is an intensive task the performance in an Azure repository is really bad for backups. 

    In your scenario, the best option might be to use the archive functionality instead.

    To archive the data to Azure you need to create a cloud account first by following these steps:

    1. Click the 3 dots and then select Cloud accounts.  https://app.screencast.com/IDIBsn9ibrysP
    2. Click "Add new account"
    3. Input the storage account name and access key
    4. Click save

    Once you have the Cloud account created do the following:

    1. Click the archive button
    2. Select "One-time archive" or "schedule archive" as you prefer and click next
    3. Click the Location type drop-down menu and select "Cloud"
    4. Select the newly created account from the drop-down menu and click next.
    5. Select the machines you want to archive, click next
    6. Click Finish

    Hope this helps.

  • That makes sense.  I think I saw another post (maybe yours) that spoke to the intensive nature of dedup likely making this idea an ineffective solution. The archiving will serve our purposes for now.  Thanks!