none
Azure Backup Server Not Syncing to Azure Backup Vault RRS feed

  • Question

  • First, I apologize if this is already been asked. If so, please kindly point me in the direction of the documentation and thank you in advance.

    We are installing Azure Backup Server v3 and for the most part it's going relatively smooth. However, my question is in regards to the workloads backing up to Azure. Our pilot Protection group contains a few servers that have a status of "OK" in the protection. Online Protection is enabled. When viewing the Disk Storage, it's showing 4TB consumed. However, when viewing Online Storage, it's shows 20MB. 

    Viewing the Backup Infrastructure within the Backup Vault in Azure displays the Management server listed correctly. The "Protected Servers" tab shows the pilot servers correctly. When viewing "Storage Accounts" it says No Protected Servers found.

    Where does MABS store the backups in Azure? How can I verify the Online Backups are working properly? I find it terribly hard to believe 4TB of online storage compresses to 20MB of Azure storage.

    Thanks!

    Monday, September 9, 2019 9:21 PM

Answers

  • I resolved the challenge. It turns out that the upload / download "cache" (where MABS stores the cache for syncing up and restoring from Azure) needs to be on a drive formatted in NTFS. If you add the drive you have configured the cache to be on, as Disk Storage within MABS, it automatically formats the drive in ReFS. This breaks the entire process.

    I created a partition, formatted it in NTFS and re-ran the "configure" (Management > Online > Configure) to point the cache location to this new drive and everything started working

    • Marked as answer by AaronSWC Thursday, September 12, 2019 7:06 PM
    Thursday, September 12, 2019 7:06 PM

All replies

  • Are you backing up to a local storage?

    Per the screenshot it shows protected server count but fails to show protected items, possible could a reporting issue.

    Just to Isolate, can you try a restore to make sure the servers are actually backed up to Azure? If this successful, you may restart "Microsoft Azure Recover Services Management Agent" and that should help fixing this reporting issue.

    Tuesday, September 10, 2019 11:43 AM
    Moderator
  • Sadiqh - Thank you for the reply

    Yes, we are backing up to disk as well. I attempted to perform recoveries to verify what happens in both scenarios.

    When recovering from DISK - the recovery was successful.

    When recovering from ONLINE - The recovery fails


    • Edited by AaronSWC Tuesday, September 10, 2019 2:16 PM
    Tuesday, September 10, 2019 2:15 PM
  • It is worth noting, that the ONLINE restore DOES attempt a download... It does create the Local Staging directory, it just doesn't download anything

    Tuesday, September 10, 2019 2:54 PM
  • I restarted the services and re-launched the console just to see what happened and things do look a lot different now. I suppose now I just need to troubleshoot the restore failure, as it does appear things are moving to Azure


    Tuesday, September 10, 2019 3:09 PM
  • Wait for sometime and then see the online backup status. If you think the backup was successful, try a restore. Even otherwise its worth trying a restore to isolate the issue.
    Wednesday, September 11, 2019 9:01 AM
    Moderator
  • I resolved the challenge. It turns out that the upload / download "cache" (where MABS stores the cache for syncing up and restoring from Azure) needs to be on a drive formatted in NTFS. If you add the drive you have configured the cache to be on, as Disk Storage within MABS, it automatically formats the drive in ReFS. This breaks the entire process.

    I created a partition, formatted it in NTFS and re-ran the "configure" (Management > Online > Configure) to point the cache location to this new drive and everything started working

    • Marked as answer by AaronSWC Thursday, September 12, 2019 7:06 PM
    Thursday, September 12, 2019 7:06 PM
  • @AaronSWC Thanks for the update! Glad to hear it is resolved :)
    Friday, September 13, 2019 11:18 AM
    Moderator