DPM: Why does it look like a bow?

    In the last article, we talked about the history of Microsoft Data Protection Manager. Today we suggest going further. You will learn how it works technically, looking at the scary beast VSS.

    I give the floor to the author of the article, khabarovdaniil (Daniil Khabarov).
    The outline of the whole story is this:
    In the first part we will talk about the historical context of Microsoft Data Protection Manager , and why it is like that.
    In the second - about how he works technically, with a look at the terrible beast VSS.
    Well, and in the third - the current state of affairs, what he knows how and how we can use it, including with Microsoft Azure Backup.
    Hi, community, it's me again, and today, as promised, we will talk about how DPM works internally.

    I was always pleased with how DPM can work with disks, and I was even more pleased to answer questions of the format: “Why does it create so many disks”, “And how can I deal with their number”.

    Microsoft Data Protection Manager and Bow

    So, in order to understand why and how DPM works, you need to understand the basic things associated with the wonderful VSS technology. As the Technet website tells us . We will be interested in the following things:

    VSS is a framework that allows you to perform backup operations while the application continues to work and writes to that. At its core, it consists of three large elements:

    • Vss writer
    • Vss provider
    • Vss requestor

    And in the picture it looks like this: It

    makes sense to talk more about them when describing the operation of the application backup mechanism, and now we need to understand how this relates to the organization of storing backup copies on disks.

    So, if you try and give an analogy, then VSS is very similar to a bow. Yes, the same bow from the cartoon Shrek, and precisely because it is multi-layered. Each layer of VSS onion is the so-called DiffArea, which, when combined, are transformed from disparate elements into a whole onion.

    To create a backup copy and write it to disk, DPM, as you know, creates 2 volumes. The so-called initial backup is stored on one volume, the one that is created during the initial synchronization. According to generally accepted terminology, it will be Full Backup. In order to make the backup up-to-date, DPM performs regular synchronizations that you specify when creating the Protection Group.

    Move on to magic

    And then the magic of that “Shrekovsky” bow begins. On the second volume, which is empty at the time the original copy was created, the so-called DiffArea begin to be created. Contrary to your expectation, not changes, but historical data are saved on DiffArea. That is, it looks like this:

    1. The initial synchronization has occurred, we have the data:

    2. At time 1, the first DiffArea1 was created, which stores the initial state of the disk:

    3. Similar to the previous figure:

    4. Similar to the previous figure:

    5. Final drive status:

    Each new DiffArea stores historical data about the previous state. Thus, we get approximately the same comic strip as shown above. To get the initial state of the AAAAAAA data , we need to add all the layers sequentially (visually following the illustrations).

    Each of you who reads these lines, of course, is interested in where this data is stored. And here we go back to the data placement options provided by VSS. In general, it allows very flexible and convenient data placement. In case we consider the operation of VSS inside DPM, then the scheme looks like this:

    This illustration shows that we have data stored on one server, as well as shadow copies. Using a set of VSS context, they can be distributed across different volumes, or stored on the same one. Everyone who somehow used the backup service even at the level of the home operating system, watched how it works. Shadow copies are saved to disk, but are not visible when viewed by conventional means, and do not even take up space, according to Disk Manager.

    Using the VSS context, you can also set other parameters, such as: whether it is possible to mount a shadow copy, whether this backup copy of the application, and much more. The bottom line is that with the help of context you set the basic rules by which you can further work with these backups. This is set at the application level, and DPM in our case.

    For reverent readers who want to learn more about how VSS works, we can continue the story cycle in the future.

    But for those who want to see the whole picture at once, I am happy to bring reference material, which quite fully describes the principle of VSS.

    And completing the VSS topic, I’d like to add that it provides a huge number of features that are often unknown or not interesting to the average person, but nevertheless, work with external Hardware Providers, with different LUNs, various snapshot contexts, as well as a mechanism Bitmap always made me happy for technological progress and backup capabilities.


    If we apply all of the above to the practical meaning of DPM, then we get the following:
    1. The number of DPM disks is determined solely by the system and cannot be directly corrected by the user. In this regard, many administrators had, in addition to many questions, many problems:
      a. Logical Disk Manager, under certain circumstances, may prevent the creation of backups. The bottom line is that LDM has limitations because it cannot support more than 2950 drives. This applies to all drives, including physical drives. To avoid this, good protection group planning is needed.
      b. The number of shadow copies is limited. As many people know, the maximum number of shadow copies is 64. This means that if you want to make a large number of copies on the disk, you need to look for alternatives.
    2. DPM uses exclusively regular backup mechanisms that are provided by the OS, and therefore there are all of the above limitations. The advantage of this solution is the unconditional support of backup from the point of view of all MS technologies. Due to this, we have the full possibility of using DPM for AD backup, which is one of the biggest advantages of using it in a corporate environment.

    At the end of my story, I want to note that next time we will talk about DPM 2016, its new features, and, if the esteemed audience shows interest in our series, we can talk about possible ways to solve the above problems, as well as some poorly documented capabilities.

    I really hope that I was able to explain how it works on comics and why this is so.

    Thank you all for your attention, and see you soon!

    Also popular now: