none
How azure backup server (DPM Lite) works?, especifically Replica, Synchronization and Recovery point. RRS feed

  • Question

  • Hi Guys,

    I'm actually implementing Azure Backup Server on a costumer. I read all the documentation about DPM 2012 R2 and azure backup server.

    There is a few things that I can't understand yet. So I hope please you could help me with this.

    1. Replica is the complete information that is protected. Does it can be compressed? That is because customer storage restrictions.

    2. Synchronization is an incremental backup. Does it can be send for online protection?

    3. Does recovery points are express full backups?. It can be protected online and they are compressed 30%-40%. In case of a recovery, does they need the local replica stored on-premises?

    Thanks Guys for your help.

    1 point is like that, because costumer don't like that replicas are the same size of mdf files portected, because a backup with sql management studio has a ratio of compression of 60% to 70% ~. And finally they required compressions because they need 90 days retention.


    • Edited by JRLOPS Thursday, October 6, 2016 6:25 PM
    Thursday, October 6, 2016 6:24 PM

Answers

  • Hi,

    To answer your questions:

    1. At this stage, DPM (or Azure Backup Server) does not compress the data, so if you have 100GB in the original source, it will require 100GB of disk space on the replica partition.
    This being said, Microsoft now supports data deduplication, which mean if you virtualise the backup server, place the VHDX (virtual disks) associated with server on a Scale-out file server, you can enable dedupe. This will save you 40% to 70% of space depending on what is being backed up.
    For more information about deduplicating DPM storage, please see:
    https://technet.microsoft.com/en-us/library/dn891438(v=sc.12).aspx

    2. Yes, each recovery points can be send to a backup vault in Azure. Only the deltas (data differences) are being send across. Note that, the data send to Azure in compressed and stays compressed in the Vault.
    You will see a compression rate of about 30% in Azure (depends on the data though). This mean that, if a recovery point takes 10GB on your local recovery point partition, it will only take about 7GB in your online Azure Vault.
    To come back to your orginal question though, make sure you do not confuse a Synchronisation with a Recovery point as they are two different things.
    The Synchronisation copies the new data from your source to the Replica, ensuring the replica is up-to-date with the latest data.
    The Recovery point on the other hand, creates a snapshot of the replica with the data difference, allowing it to be restored at a later stage (think of it as a reverse incremental backup system).

    3. As I mentioned above, Recovery Points are effectively reverse incremental backups, not full backups. Your Replica always contains the latest data (the latest full backup), while your recovery points hold the difference at the time of a recovery creation, allowing you to restore from those points based on the replica partition.

    If you need to recover anything from your Azure Vault, you will require local disk space of at least the same size as what you are trying to recover. DPM will download the data into that space (cache), the move to the location your decided to restore to.
    To backup the data to a Vault, you will need about 10% of the orginal space on local disk. So if you are trying to backup 100GB to your Azure Vault, your local disk (cache) should have about 10GB of free space.

    Hope the above makes sense, but let me know if you require any additional details/clarifications.


    Stephane

    • Proposed as answer by _Stephane_MVP Sunday, October 9, 2016 10:34 PM
    • Marked as answer by JRLOPS Monday, October 10, 2016 7:13 PM
    Thursday, October 6, 2016 11:46 PM
  • No problem, happy to help :-)

    1. This how MABS creates a backup and how Replicas and Recovery Points interact:
    The Replica partition contains the exact copy of your data. THis copy is kept up-to-date by the use of the synchronisation job.
    When you kick off a backup in MABS and create a local Recovery Point, the MABS agent will send out the changed data from the original source to the Replica. The changed data on the replica, instead of being overwitten will be move to the recovery point partition and become part of that recovery point. This process run every time you run a new local backup (without compression).
    When you decide to use Azure for your long term retention, the first thing MABS will do is send out the entire Replica to Azure first (called the initial seeding). From there, every time you decide to run an Cloud Recovery point, MABS will send out the changes to Azure, which will be put on the replica, and the changed data on the replica, instead of being overwritten, will be placed in an online Recovery Point. All this data will be compressed.
    To answer to orginal question, the compress level depends on what data is uploaded and can be substantial indeed. Although I haven't seen 80% yet, it's not impossible, but I would verify that the data can be restored (there could be something wrong with the initial seeding).

    2. Yes, creating local recovery points and Azure recovery point are two separate things and run as two separate jobs. So you could create a local recovery point first at 10pm for example, and an online recovery point (with the same data) at 11pm. Note that the Azure Recovery Point will always use the data from the latest Local Recovery Points, so you cannot create a local recovery point, followed by 2 Azure Recovery point as the second one does not have any new data.

    3. No matter how small you reduce the local retention, the replica will never be deleted, only your Recovery Point partition will change and use less space.
    Online recovery Points are always available, even if you stop running your local backup and delete the local replica (this is why there is a copy of the replica in the cloud as well). When removing a object from a protection group, you have the choice to delete the local and/or the online replica/storage. As long as you only delete the local storage, your only replica and backups will always be available and restorable.

    4. Because the Replica is already in Azure, you can restore the VM without re-transferring the entire data set.

    5. A Replica does not have a retention range and always exist as long as you need to do backups. Recovery points are the one impacted by the retention range and will be deleted in a circular fashion based on how long the retention range is defined for (this apply for both local and Azure Recovery point). For example, if you define a local retention of 5 days, on day 6, the oldest local recovery point will be overwritten, ensuring that you always have the last 5 days available. The same principle applies for Azure Recovery Point as both retention range (local and Azure) are defined separately. So you can define a 5 day local retention and a 5 years online retention. In this example, you'll be able to restore any local recovery point from the last 5 days, and any online recovery points from the last 5 years.
    Again those are managed separately, so deleting local ones doesn't touch the online ones.

    Cheers,


    Stephane

    • Proposed as answer by _Stephane_MVP Sunday, October 9, 2016 10:35 PM
    • Marked as answer by JRLOPS Monday, October 10, 2016 7:13 PM
    Friday, October 7, 2016 1:23 AM
  • The option above will use the Internet to upload the intial replica when the online job starts.
    Earlier during the wizard, you would have selected at what time of the day the online job should start. When this starts for the first time, the replica will be upload first automatically.

    This process will appear in the same area of any other jobs (click on the "monitoring" tab, then select the "All jobs in progress") once the online job has started (at the time you selected during the setup wizard above).

    If your local replica is 100GB, the replica stored in Azure will be around 70GB as you can expect around 30% compression (this can vary though).

    Let me know if this all works out for you and, if you don't mind, please remember to mark my replies as "Answers" if you feel they've answered your questions accurately :-)

    Thank you,


    Stephane

    • Proposed as answer by _Stephane_MVP Sunday, October 9, 2016 10:35 PM
    • Marked as answer by JRLOPS Monday, October 10, 2016 7:13 PM
    Saturday, October 8, 2016 6:35 AM
  • Hi,

    The "Online Recovery Point" represent both the initial replica creation and recovery point jobs. In this case, Microsoft considers the first Recovery Point as the intial seeding of the replica from a job point of view.

    In terms of how much data is uploaded (point 1.) in an online recovery point compare to a local recovery point, this is also a mistery to me why there is a discrapency there, so I'm afraid I won't be of much help there.

    In regards to the time (point 2.) shown in your recovery point selection, although the online recovery point is scheduled to run at 9am, it will look at the latest local recovery point and upload a copy. This will then translate in your online recovery point showing the time your local recovery point was taken.

    Cheers,


    Stephane

    • Marked as answer by JRLOPS Monday, October 10, 2016 7:11 PM
    Sunday, October 9, 2016 10:34 PM

All replies

  • Hi,

    To answer your questions:

    1. At this stage, DPM (or Azure Backup Server) does not compress the data, so if you have 100GB in the original source, it will require 100GB of disk space on the replica partition.
    This being said, Microsoft now supports data deduplication, which mean if you virtualise the backup server, place the VHDX (virtual disks) associated with server on a Scale-out file server, you can enable dedupe. This will save you 40% to 70% of space depending on what is being backed up.
    For more information about deduplicating DPM storage, please see:
    https://technet.microsoft.com/en-us/library/dn891438(v=sc.12).aspx

    2. Yes, each recovery points can be send to a backup vault in Azure. Only the deltas (data differences) are being send across. Note that, the data send to Azure in compressed and stays compressed in the Vault.
    You will see a compression rate of about 30% in Azure (depends on the data though). This mean that, if a recovery point takes 10GB on your local recovery point partition, it will only take about 7GB in your online Azure Vault.
    To come back to your orginal question though, make sure you do not confuse a Synchronisation with a Recovery point as they are two different things.
    The Synchronisation copies the new data from your source to the Replica, ensuring the replica is up-to-date with the latest data.
    The Recovery point on the other hand, creates a snapshot of the replica with the data difference, allowing it to be restored at a later stage (think of it as a reverse incremental backup system).

    3. As I mentioned above, Recovery Points are effectively reverse incremental backups, not full backups. Your Replica always contains the latest data (the latest full backup), while your recovery points hold the difference at the time of a recovery creation, allowing you to restore from those points based on the replica partition.

    If you need to recover anything from your Azure Vault, you will require local disk space of at least the same size as what you are trying to recover. DPM will download the data into that space (cache), the move to the location your decided to restore to.
    To backup the data to a Vault, you will need about 10% of the orginal space on local disk. So if you are trying to backup 100GB to your Azure Vault, your local disk (cache) should have about 10GB of free space.

    Hope the above makes sense, but let me know if you require any additional details/clarifications.


    Stephane

    • Proposed as answer by _Stephane_MVP Sunday, October 9, 2016 10:34 PM
    • Marked as answer by JRLOPS Monday, October 10, 2016 7:13 PM
    Thursday, October 6, 2016 11:46 PM
  • Thank you so much for your response.

    Please could you help me with the following?

    Note: I have my MABS on-premises.

    1. One of my replicas is actually about 130GB but Online recovery point is 32GB, that is aproximately 80% of compression. I'm sorry I'm confused a lot, knowing that recovery point is a VSS snapshot of replica, why DPM or MABS can send that data to azure with that level of aproximately 80% of compression. Does the recovery point is an exact snapshot of the replica?

    2. Could I have one recovery point in disk and azure at the same time?

    3. Because of storage retrictions, if I reduce the local retention range of my replica to 5 days, but I maintain my recovery point in Azure for about 90 days:

    • Does Replica will be deleted in 5 days?
    • Does my online recovery point will be orphaned or obsolete?
    • Could I will use the recovery point that is stored in azure?

    4. If I want to do a restore to an azure VM, will apply only the online recovery point, or the replica needs to be uploaded or transferred to Azure VM from on-premises.

    5. When replica reached the retention range period Does all data will be deleted (Replica + Recovery points), Does online recovery points will be deleted too?

    Thank you so much for your help.



    • Edited by JRLOPS Friday, October 7, 2016 12:41 AM
    Friday, October 7, 2016 12:39 AM
  • No problem, happy to help :-)

    1. This how MABS creates a backup and how Replicas and Recovery Points interact:
    The Replica partition contains the exact copy of your data. THis copy is kept up-to-date by the use of the synchronisation job.
    When you kick off a backup in MABS and create a local Recovery Point, the MABS agent will send out the changed data from the original source to the Replica. The changed data on the replica, instead of being overwitten will be move to the recovery point partition and become part of that recovery point. This process run every time you run a new local backup (without compression).
    When you decide to use Azure for your long term retention, the first thing MABS will do is send out the entire Replica to Azure first (called the initial seeding). From there, every time you decide to run an Cloud Recovery point, MABS will send out the changes to Azure, which will be put on the replica, and the changed data on the replica, instead of being overwritten, will be placed in an online Recovery Point. All this data will be compressed.
    To answer to orginal question, the compress level depends on what data is uploaded and can be substantial indeed. Although I haven't seen 80% yet, it's not impossible, but I would verify that the data can be restored (there could be something wrong with the initial seeding).

    2. Yes, creating local recovery points and Azure recovery point are two separate things and run as two separate jobs. So you could create a local recovery point first at 10pm for example, and an online recovery point (with the same data) at 11pm. Note that the Azure Recovery Point will always use the data from the latest Local Recovery Points, so you cannot create a local recovery point, followed by 2 Azure Recovery point as the second one does not have any new data.

    3. No matter how small you reduce the local retention, the replica will never be deleted, only your Recovery Point partition will change and use less space.
    Online recovery Points are always available, even if you stop running your local backup and delete the local replica (this is why there is a copy of the replica in the cloud as well). When removing a object from a protection group, you have the choice to delete the local and/or the online replica/storage. As long as you only delete the local storage, your only replica and backups will always be available and restorable.

    4. Because the Replica is already in Azure, you can restore the VM without re-transferring the entire data set.

    5. A Replica does not have a retention range and always exist as long as you need to do backups. Recovery points are the one impacted by the retention range and will be deleted in a circular fashion based on how long the retention range is defined for (this apply for both local and Azure Recovery point). For example, if you define a local retention of 5 days, on day 6, the oldest local recovery point will be overwritten, ensuring that you always have the last 5 days available. The same principle applies for Azure Recovery Point as both retention range (local and Azure) are defined separately. So you can define a 5 day local retention and a 5 years online retention. In this example, you'll be able to restore any local recovery point from the last 5 days, and any online recovery points from the last 5 years.
    Again those are managed separately, so deleting local ones doesn't touch the online ones.

    Cheers,


    Stephane

    • Proposed as answer by _Stephane_MVP Sunday, October 9, 2016 10:35 PM
    • Marked as answer by JRLOPS Monday, October 10, 2016 7:13 PM
    Friday, October 7, 2016 1:23 AM
  • Thanks so much _Stephane_, a lot really, for your time and effort to help me.

    I'm sorry _Stephane_ how could I upload replica to Azure from internet?, because I can't do it offline. The following option is where I can do it?:

    Where I can check the progress of the initial replica to the Cloud (not local)?, that is because I only see in the monitoring tab jobs like "online recovery point", "Replica" and "Recovery point", but I can't see something like "Online Replica"

    If local replica is 100GB, does the replica stored in azure must be 100GB too? Right?

    Regards.

    • Edited by JRLOPS Friday, October 7, 2016 6:42 PM
    Friday, October 7, 2016 3:25 PM
  • The option above will use the Internet to upload the intial replica when the online job starts.
    Earlier during the wizard, you would have selected at what time of the day the online job should start. When this starts for the first time, the replica will be upload first automatically.

    This process will appear in the same area of any other jobs (click on the "monitoring" tab, then select the "All jobs in progress") once the online job has started (at the time you selected during the setup wizard above).

    If your local replica is 100GB, the replica stored in Azure will be around 70GB as you can expect around 30% compression (this can vary though).

    Let me know if this all works out for you and, if you don't mind, please remember to mark my replies as "Answers" if you feel they've answered your questions accurately :-)

    Thank you,


    Stephane

    • Proposed as answer by _Stephane_MVP Sunday, October 9, 2016 10:35 PM
    • Marked as answer by JRLOPS Monday, October 10, 2016 7:13 PM
    Saturday, October 8, 2016 6:35 AM
  • Thanks Stephane so much.

    So I've identified 4 types of Jobs in MABS Finally:

    Replica Creation = Local Replica

    Recovery Point Incremental Sync = Incremental Backup that updates replica to the latest version, here we can't select that for recovery point in applications data; i.e SQL Simple Recovery and Log Shipping.

    Recovery Point Express Full = Snapshot of the data source and then it only takes the changes and sync that changes to the replica. Used when Applications data like SQL, don't support Incremental backups (Types explained above).

    Online Recovery Point = Same as above but send to the cloud.

    So According to the above, what is the job tha send the total replica to the cloud? Is it Online Recovery Point? If so, why microsoft don't named that "Online Replica Creation" instead of "Online Recovery Point".

    I assumed that Online Recovery Point = Copy of the replica in the cloud. That is right?.

    Replica "does not have a retention range and always exist as long as you need to do backups"as you mencioned above, Given that only exists Online Recovery Point that appears to be an express full backup in the cloud. Where is the replica in the cloud that never change?

    Finally I don't understand why the following situation happened:

    1. I have a Database that is not transactional, I've created that for testing purposes. The Local Replica size was 5.06MB, and when the online recovery point was created the data transferred was 23.21MB. Why this happens?

    2. The Online recovery point runs at 9:00AM, why in the recovery tab I see the option to recover that from 8:30AM instead of 9:00AM:


    Thanks so much again.



    • Edited by JRLOPS Saturday, October 8, 2016 9:25 PM
    Saturday, October 8, 2016 3:07 PM
  • Hi,

    The "Online Recovery Point" represent both the initial replica creation and recovery point jobs. In this case, Microsoft considers the first Recovery Point as the intial seeding of the replica from a job point of view.

    In terms of how much data is uploaded (point 1.) in an online recovery point compare to a local recovery point, this is also a mistery to me why there is a discrapency there, so I'm afraid I won't be of much help there.

    In regards to the time (point 2.) shown in your recovery point selection, although the online recovery point is scheduled to run at 9am, it will look at the latest local recovery point and upload a copy. This will then translate in your online recovery point showing the time your local recovery point was taken.

    Cheers,


    Stephane

    • Marked as answer by JRLOPS Monday, October 10, 2016 7:11 PM
    Sunday, October 9, 2016 10:34 PM
  • Thank you so much Stephan, It's all clear finally.

    • Edited by JRLOPS Monday, October 10, 2016 7:12 PM
    Monday, October 10, 2016 7:12 PM
  • My pleasure :)

    Don't hesitate to ask if you require any additional information or are running into problem.

    Good luck,


    Stephane

    Monday, October 10, 2016 10:58 PM