Slide 1 Welcome to this Web Based Training session providing you an introduction to the fundamentals of the ETERNUS DX Snapshot functionality. ETERNUS Advanced Copy Functions provide two types of Snapshots: SnapOPC and SnapOPC+. This module includes also an introduction to Snap Data Pool which provides additional flexibility to the use of the Snapshots. At the time of publication the SnapOPC functionality is available only in the Midrange and Enterprise models; SnapOPC+ and Snap Data Pool are available also in the Entry models. Advanced Copy functionality is embedded in the firmware of the DX system and is managed by the additional ETERNUS SF management applications: either with "AdvancedCopy Manager" - often abbreviated as ACM - or "SF Express". Please note that the content of this Web Based Training is valid for the time of publication. Additional functionality and functional improvements can be introduced in later ETERNUS DX models and firmware releases. Please always use the latest handbooks for reference. 2 This Web Based training module consists of four main sections: First section provides us a general introduction to ETERNUS DX Snapshots. Sections SnapOPC and SnapOPC+ introduce us to the two types of Snapshots in more detail. Last section shows us how Snap Data Pool provides additional flexibility for the use of ETERNUS DX Snapshots. 3 This section serves as a general introduction to the Snapshot functionality and is divided in the following parts: We will start with a general description of Snapshots, followed by a brief introduction to the difference between the two available types of Snapshots. A basic principle of the Snapshot mechanism is explained next. Functionality of the SnapOPC is based on Backup Data Control Information, this is the next subject. Chapter "Snapshot Feature Overview" provides a summary of what typical usage is best suited for Snapshots. As we continue, we will be referring to Snapshots also as Snaps; they mean the same and refer to both SnapOPC and SnapOPC+. 4 All Advanced Copy functions use one or more bitmaps to manage block replication and/or to keep a track of changed data blocks. Snapshots do not use a copy control bitmap like for example OPC, because they only need to keep a track of changed data blocks. Therefore, each Snap session uses a dedicated tracking bitmap. This records the modifications done at the source or destination volume. In the case we are running multiple Snapshot sessions - one source is used for several destination volumes - tracking bitmaps will be used for each replication pair. All Advanced Copy functions start with a logical phase after they have been invoked. During this phase ETERNUS DX creates the tracking bitmap, which takes only a very short time. After this an acknowledgement is sent back to the user interface.

The second step is the physical phase. Instead of creating a full copy of the source like with OPC, Snaps records the changes of the source volume. This procedure is called "copy-on-first-write". Before overwriting the source data, the original data block is copied over to the Destination Volume. In a Snapshot replication the destination is named Snap Data Volume, abbreviated SDV. After successful backup of the original data block, the source data will be overwritten and in the last step of "copy-on-first-write" the corresponding bit in the tracking bitmap is changed to "modified". 5 ETERNUS DX systems provide two different types of Snap replications: SnapOPC and SnapOPC+. We will now have a look at the differences between the two available Snap types. We start with the SnapOPC. In our example we have a Source Volume and three replication partners. The first generation of the replication is done on Monday. The second is started on Tuesday and the third SnapOPC replication is started on Wednesday. All three sessions are active and run in parallel. As you can see at the destination side there is a yellow block from the Monday modifications, a green from the Tuesday modifications and a red from the Wednesday modifications. This picture shows nicely the basic functionality of SnapOPC: with parallel running sessions, the data changes in the Source Volume are recorded in all active generations. In other words, if we would restore the Snap made on Monday it would restore also the changed data from Tuesday and Wednesday. On the next slide we will see how the write operation is carried out. 6 Now let us see how SnapOPC handles data block modification in general. Before we can transfer the purple data to the area of the blue block in the source volume, SnapOPC copies these original blue contents to the destination volume of the Monday generation, Tuesday generation and Wednesday generation. And now after the blue data block is backed up, the purple content overwrites the original data at the source volume. This operation is called "copy-on-first-write", implying that a write operation is preceded by a copy operation. Later on we will see why also the word "first" has its significant meaning. 7 This slide gives a brief heads-up about how SnapOPC+ differs from SnapOPC. On the left hand side we see how SnapOPC executes the "copy-on-first-write" process, we will now see with the animation on the right hand side of the screen how SnapOPC+ works differently. We have a similar initial situation as previously with the SnapOPC, three parallel active replication pairs. But at generation one there is only a yellow data block that was backed up with the Monday modification, in generation two there is only a green data block that was backed up on Tuesday and at generation three there is only a red data block that was backed as a Wednesday Snap. In other words, a SnapOPC+ generation always records the changes since the start of the Snap or since the last Snap was made.

Like on the left hand side, the application server wants to write the purple data block to the Source Volume. Opposite to SnapOPC ETERNUS DX saves the blue data block to the last generation only, also when in our example all three SnapOPC+ sessions are active. After the blue data block is copied, the purple data block is written on the Source Volume. That means, with SnapOPC+ each snap generation holds the data changes that were done before the next snap generation was started. This is a classical incremental backup. 8 This page summarizes some basic characteristics of Snapshots and introduces couple of new functional basics that we will have a closer look at in the coming slides. Snapshot is a "copy-on-first-write" process. That means Snapshots do not make a full initial backup of the source volume. The destination volume must be pre-created with the ETERNUS Manager GUI. The Destination Volume is a special type of ETERNUS volume and is used for both types of Snap replications; SnapOPC and SnapOPC+. Although the Destination Volume is a special type of Volume, you can make it accessible for the application server by mapping it like any normal Volume. When configuring the Snap Data Volume with ETERNUS Manager GUI you have to define a physical and a virtual capacity. The physical capacity of the SDV saves the original - that is to say the old - data block from the Source Volume before it is modified. The virtual capacity equals the capacity of the source volume. It is this virtual capacity that is made visible to the application server, through this the server has read and write access to the data which in reality reside on the physical Source Volume and in the physical Snap Data Volume. Like already mentioned, ETERNUS DX stores the original data to the SDV before it is overwritten by new data. But also the application server can have write access to the SDV; later on we will see what practical consequences that has. 9 As already mentioned, the SDV has to be created as a special volume type before you can use it for SnapOPC or SnapOPC+ replication. The physical SDV capacity can be much smaller than the capacity of the source volume. This is what makes SnapOPC and SnapOPC+ different from the other ETERNUS Advanced Copy functions like OPC, QOPC, EC and REC. Please note that the Backup Data Control information is stored in the physical SDV and is in size about 0.1 % of the virtual capacity. The virtual capacity parameter is used during the volume configuration for SDVs only. It has to be of the same capacity as the respective source volume. 10 Here are screenshots of the Snap Data Volume configuration parameters like they appear in the DX Entry or DX Midrange and Enterprise ETERNUS Manager GUI. 11 Backup Data Control information consists of three kinds of information, one of them is the SnapOPC Tracker. Please note that when we refer to the Tracker in the

respective chapters for SnapOPC and SnapOPC+, it means the same, the Tracker functionality is the same for both types of Snaps. ETERNUS DX uses tracking bitmaps to control the data modifications in the Destination Volume. This tracking bitmap is created in the Controller Module cache of the ETERNUS DX. Each bit of the bitmap represents a physical data block of the Source Volume that is being tracked. Each SnapOPC session uses its own tracking bitmap, even when parallel sessions are using the same Source Volume. 12 Second piece of information held in the BDC is a conversion table which is used for the conversion between the logical addresses of the virtual Destination Volume and the physical addresses of where the data resides, which may be on the source volume or the SDV. 13 Snap Data Volume is the third element used for managing the Snap data. SDV is a physical volume with a capacity less than the Source Volume. Estimating an exact value for the SDV capacity is rather difficult; in every case it can be considerably smaller than the Source Volume because only changed data need to be stored. Please note that if the set capacity of the SDV is exceeded, the changes can no longer be recorded and consequently the SDV will be void. To help with estimating the needed capacity, ETERNUS management software AdvancedCopy Manager provides a command "swstestupdate". This command can be executed in the application server that is accessing the source LUN. The command uses a pseudo session setting function to measure the change rate of the Source Volume. The administrator gets an overview of the amount of updated data and can use this information for setting an optimal physical size for the SDV. For more details on this subject, you can refer to the "ACM Operator's Guide", chapter "Commands". 14 Let us summarize the Snapshot features. The Snap Data Volume is a special volume type of the ETERNUS DX systems. Its physical capacity can be considerably smaller than the source volume capacity. The read and write performance of the Snap destination volume is somewhat lower than that of a normal data volume. The reason is the overhead from having to generate a virtual view of the Destination Volume. The actual data that the application server sees comes from two different sources; Source Volume or Snap Destination Volume. The major difference between SnapOPC and SnapOPC+ is that with SnapOPC the original source data is stored in all generations, whereas with SnapOPC+ only in the last - or youngest - generation. That way SnapOPC+ uses in total far less space for the Snap generations. There is a limit - at the time of publication eight - to the number of Snap generations that can be started in parallel. In other words you may have to stop an older Snap generation before you can start the next. OPC and QuickOPC functions allow cascading of replications, meaning a destination of one replication pair could be the source of the next replication pair. However this is

not supported for an SDV, because it doesn't represent the complete data and is thus only meaningful in combination with the original source data. 15 Here are the advantages of Snapshots. The backed up data is available instantly after having launched the Snap, the application can also have write access to this data - albeit we know that after having changed the SDV contents, it can no longer be used to restore the data image to its initial state. Unlike other Advanced Copy functions Snaps use a smaller destination volume, which results in significant storage capacity savings. What applications benefit the most from Snapshots? Only a very short time is needed to make a Snap, after the Snap generation is started both members of the replication pair are immediately accessible. That means you can work with your application and its source volume without having to stop it to run a tape backup of the destination volume. The backup software has access to the source data as it existed at the time when the Snap command was invoked, even if the production application has made changes to it. Any accidentally deleted source data can be restored from a mounted destination volume of a Snap generation. The restore can be done manually using server Operating System provided tools and/or with the reverse OPC functionality, depending on the ETERNUS DX model used. Are there any disadvantages with Snapshots? As already explained, the disk access performance of the Destination Volume - comprising of the Snap Data Volume and virtual mapping of the Source Volume - is somewhat degraded compared to a normal Volume. Please note that typically the server application continues accessing the Source Volume directly; Snaps have only a minimal performance impact for direct access to Source Volume. Snaps do not create a full backup of the source data before the first "copy-on-first-write" process is executed. Here it is worth mentioning that Snapshots as such does not provide any redundancy for the Source Volume. To circumvent this, it is naturally possible to do a full backup with OPC before launching the Snap. If the Source Volume gets corrupted or lost, you cannot use any Advanced Copy functions to restore the source volume from the SDV. In fact you cannot even access the SDV. Snapshots are generally not recommended if your application modifies large amounts of data as this increases the size of the SDV. This is especially the case for SnapOPC as all changes are stored in all generations and the changes on the source are recorded as long as the sessions run; therefore SnapOPC is not ideal for long term copies. Snapshots are not an optimal choice if the access performance is critical, as well as if there is no initial full backup of your source data available. To summarize that, Snapshots are best suited for making daily disk-to-disk backups that can be consequently copied to tape. Data can be restored back as it was on a chosen day; having a full OPC copy of the source drive provides additional redundancy.

16 After having had an overview of Snapshot functionality, we will now have a closer look at the functionality of SnapOPC. The first two chapters demonstrate the internal functionality of the ETERNUS DX SnapOPC with a number of animated examples Principles of SnapOPC Restore functionality is explained in the chapter "SnapOPC Restore". Chapter "SnapOPC Read and Write Operations" shows with the help of several examples how data is written and read and how changes are tracked during a SnapOPC session. Last chapter explain how in practice data can be restored from a SnapOPC session. 17 In the following slides we will learn with help of simple animated examples how data blocks are handled by SnapOPC in different read and write scenarios. This first animation demonstrates what happens when a source data block is changed several times and how consequently the original data block is copied to the destination volume "SDV" only once. Here is where the significance of the word "first" in the "copy-on-first write" becomes obvious: a SnapOPC session copies a single data block only with the first overwrite instance, further overwrites of the same data block are discarded from a backup point of view. A SnapOPC session is meant for being able to restore the data at the time the SnapOPC was launched, for that purpose it is important to record only the first update of the data. We observe the functionality using a single data block as an example. The data block is stored in the Source Volume and is colored yellow. The replication destination is Snap Data Volume one. At this point in time we start the first SnapOPC session. Like we know, a tracking bitmap is created and consequently changes on the Source Volume are tracked and recorded. Technically, also the changes on the SDV are tracked, but that is irrelevant for this example, more about that later on. Data block one can be seen in the source volume and in the next step the application server wants to overwrite this block with the red colored contents. Before ETERNUS DX overwrites the block number one it checks if this data block is already copied to the SDV1 volume. As this is the first write instance on this particular block, the yellow data is copied to the SDV and after that the new red colored content is written to the source. We have now a red data block in the source and a yellow, snapped data block in the SDV1. Next change takes place in the form of amber colored content to be written to the source. And again ETERNUS DX checks first if this particular data block has been previously changed. In our case the answer is "yes" and therefore the system discards the red data block in order not to lose the original yellow data content. That means the amber content will overwrite the red data block in the source. We will now create a second replication pair with the same Source Volume and a second Snap Data Volume, SDV2. After that we start a second SnapOPC session in parallel to the first one. Please note that we haven't stopped the first SnapOPC session, meaning it is still active.

In step five we have amber content in data block one of the Source Volume and yellow content in the Destination Volume "SDV1". Now the application server wants to write purple content to the source block number one. Like we would expect, first ETERNUS checks if the data block number one has already been modified, in other words, already stored in SDV1. That being the case, the overwrite process is prevented. But as there is now a second, more recent snap generation with the Destination Volume "SDV2", Next ETERNUS checks if this data block one has been copied to that SDV. In our case the answer is "no" so next the amber content gets copied to SDV2. Remember, the amber content is needed so that we can later restore the data content as it was when the second SnapOPC was launched. Now we can overwrite the source data block with the purple content. Let us continue with the last example of this animation sequence. Although we pretty much already know what will happen, we look once more at what happens when the application server wants to change once more the contents of data block one, this time with green content. ETERNUS checks first if a copy of this particular data block already exists in SDV1 and consequently a copy process to SDV1 is prohibited. And the check of a backup status in SDV2 comes to the same conclusion, so a copy process to SDV2 is also prohibited. As a result ETERNUS replaces the purple source data contents with the green data block. 18 The animation on the previous slide demonstrated the "copy-on-first-write" mechanism with one data block only. The animation on this slide shows us how SnapOPC works when several data blocks - in our case three - are being updated. The source volume contains three data blocks with yellow colored contents. We create one replication pair with Snap Data Volume one. We invoke the first SnapOPC session after which application server wants to write red content to replace the data block one of the source volume. ETERNUS DX checks if a backup exists for data block one at SDV1 and in our case the backup process starts and consequently the block one is overwritten with red colored content at the source. In step three of our animation the application server wants to write red contents to data block number two. But before the write can take place the original yellow content of data block two has to be backed up to SDV1. As the contents for data block two has not yet been copied to the SDV1, ETERNUS proceeds with the copy. The yellow data block two is copied to SDV1 and the red data content will overwrite the data block two at the source volume. Another SnapOPC replication pair is set up next with SDV2 as a destination partner. After creating the second replication pair we start a second, parallel SnapOPC session. Again the application server wants to write red colored contents but this time to data block number three of the Source Volume. ETERNUS checks first the backup status for this data block at SDV1 and consequently copies the original data block from source to SDV1. The same check is carried out for SDV2.

Next the original data block is copied from source to SDV2. After these two "copy-on-first-write" instances, the red content is written to the third data block of the Source Volume. In the final step of this animation sequence the application server wants to update the block number two in the Source Volume with green contents. Again, backup status of this data block is checked first at SDV1 because SnapOPC one is still active. Copy to SDV1 will not take place because data block two is already exists in SDV1. Next the backup status for data block two is checked at SDV2. In our example there was no previous backup done, so the red colored data block is copied to SDV2. After this "copy-on-first-write" - from the second snap generation point of view - the green content is written to source data block two. 19 After the two previous examples of SnapOPC data block handling, we can now have a closer look at the restore functionality. Our source volume has got three originally yellow colored data blocks. After starting the first SnapOPC replication in step one we will do two red colored modifications for data block one and data block two in the source volume. This causes the data blocks one and two to be backed up in SDV1. In step 4 of our example we start a second SnapOPC session running in parallel with the first SnapOPC that is still active. The application server updates data block three with red content and immediately after that the data block two again with green content. As a result of all this, a backup of the yellow data block resides in both SDV1 and in SDV2 and the red data block number two is backed up to SDV2 only. Now let us see what happens when we recover the source volume from the first SDV1. The content of the source volume is the same as it was when we started the first Snap session. Now let's do a restore using SDV2. As we can see, the restored Source Volume represents the data contents from the time when the second Snap session was started. If we consider the SDV1 to be our backup from Monday and SDV2 backup from Tuesday, the example on this slide shows how it is possible on Wednesday quick and easy roll back the source data to the state it had either on Monday or Tuesday. Next on this Web Based Training follows six further read and write scenarios 20 Like we have learnt in the beginning of this Web Based Training, the two volumes - Source and Snap Data Volume - can be mapped like any other volume to the server and consequently be fully accessible for applications and the operating system. On the following slides the source volume is always shown at the left hand side of the page. The Snap Data Volume stores only the changed data and can therefore have a relative small capacity compared to the Source Volume. Instead of the physical capacity of the SDV, the application server sees only its virtual capacity, which equals the capacity of the Source Volume. Destination Volume is the second party of a replication pair, Source Volume of course being the other. Destination Volume is actually the virtual LUN of the Snap Data Volume, providing the application server access to all data, as it was at the time when the Snap was taken. A technical note again: that is, if the snapped data has not been changed thereafter on purpose by the application server.

Next important element is the tracking bitmap which is held in the cache of the Controller Module. The purpose of the tracking bitmap is to keep a record of all data blocks that have been changed since the particular SnapOPC was launched. We start with a simple example: application server reads an unmodified data block directly from the Source Volume. This would be the typical situation when the application server continues working with its Volume normally, like it would without having SnapOPC running in the background. 21 On the previous page the Source Volume was mapped directly to the application server, in this example the application server reads the same data block but this time from the Destination Volume. In effect, for the application server this means access to the data as it was at the time when the SnapOPC was launched. The application server addresses a data block in the Destination Volume SnapOPC Tracker checks the data status to know if the data has been changed since the Snap was taken, in other words, if it is to be fetched from Source Volume or from Snap Data Volume. In this example the data has not been changed, meaning ETERNUS DX fetches the data from the Source Volume. When reading unchanged data from the Destination Volume, the data is fetched in reality from the Source Volume. That requires additional mapping of the block addresses which is the cause for the slight performance hit. 22 This next example is similar to what we have already seen at single data block level earlier in this Web Based Training, now a bit more generic view to ETERNUS functionality for writing new data directly to the Source Volume. A white data block in the Source Volume represents the original data. The application server wants to write the diagonally striped data in the Source Volume, that is, to replace existing data. Before we can now overwrite the white colored block in the Source Volume, we have to do a "copy-on-first-write" to backup the original data block to the physical SDV. Physically the backed up white data block resides in the SDV. But from the application’s point of view this saved block resides in a virtual resource. Remember, few slides earlier we have learnt that the ETERNUS uses "backup data control information" to convert virtual block addresses to real ones. This BDC information is held on the physical SDV and it occupies only a fraction of its capacity. After the original data block is backed up, the "copy-on-first-write" process finishes with the update of the tracking bitmap. The bit responsible for this virtual data block will be changed to "modified". Now the ETERNUS can overwrite the original content of the white block in the source with the new content. 23 We continue with the animation from the last page, now the application server wants to read a data block from the Destination Volume and in this case, the data is located on the SDV because the source volume was updated. Application server wants to read the data block that was backed up in the last page.

First the SnapOPC Tracker checks the status of this data block. The bitmap table tells that the data block has been once overwritten; therefore the data will be fetched from the Snap Data Volume. In practice this means that the application server can access the original data in the Destination Volume whereas the new data is available only in the Source Volume. 24 Earlier on in this Web Based Training we saw a block level example of what happens when a data blocks gets overwritten for the first time in the Source Volume, in this example the application server wants to write in the Destination Volume instead. The application server wants to write new data with striped content to the Destination Volume, which in fact is the physical Snap Data Volume. ETERNUS DX changes the tracking bitmap to "modified". This protects it from being overwritten later by a "copy-on-first-write" that would otherwise overwrite the data block in the SDV. The striped content is now visible in the virtual destination LUN. This demonstrates that all writes on Destination Volume are done in the Snap Data Volume and thus part of the data that can be restored. In other words, if you want to keep your original data image intact, do not allow writes on the Destination Volume. 25 The example on the previous slide demonstrated the write process on the Destination Volume when overwriting previously unmodified data. This next example shows what happens with a write request to a block of data in the Destination Volume that has been backed up. The application server wants to write "dotted" data to the Destination Volume. You can see that this particular "white" data block has already been backed up as a result of an earlier "copy-on-first-write" process. ETERNUS checks the respective bit in the tracking bitmap and recognizes the "modified" status. That means that the data block has already been once backed up and consequently the SDV holds the original data content. If the application server would be now writing in the Source Volume, we know what happens: the existing data would be replaced but the original data would remain intact. Now that the application server writes in the Destination Volume - providing of course that writing is allowed for the mapped LUN - the original data in the SDV is replaced with the new data. For the purpose of being able to restore the original data this of course makes no sense - that is obviously no longer possible - but useful when for example an application developer wants for trouble shooting purposes to quickly switch between different development versions and continue working normally. 26 How about restoring data from a SnapOPC backup? We mentioned earlier that SnapOPC is not a full backup like OPC. Therefore the SDV only contains the changed data. There are two methods that can be used to restore data from the SDV. The easiest and most common method would be to mount a chosen SDV to some OS and copy the files individually using OS commands, without having to stop any of the SnapOPC sessions for the same source volume. The second method would be to completely restore the source volume from one of the generations of

SnapOPC; this would require stopping all other generations of SnapOPC for that particular source volume. The following two slides explain the procedure for restoring data from a particular SnapOPC generation. We have here four active SnapOPC replication pairs, all running in parallel and having the same Source Volume. Like we said, SnapOPC is not a full backup. What we have instead is differential backups, meaning we cannot restore full backup data without the source volume. To play safe, you could of course configure and start an OPC replication for the source before starting the first SnapOPC generation. 27 We choose to restore the data as it was at the time when the second SnapOPC generation was launched. Next step in the restore process is to stop all the other SnapOPC generations using the same source. Please note that at this moment the canceled SnapOPC copy Destination Volumes will disappear. The generation to be used for restoring must remain active, for the restore we start a reverse copy with either ACM or SF Express. Typically for all ETERNUS DX Advanced Copy functions, the Source Volume will be immediately available for normal use, without having to stop the application to wait for the restore to be done. This slide concludes the introduction to SnapOPC. You may now want to take a short break before continuing with the next section that provides us an introduction to SnapOPC+. 28 This section introduces us to SnapOPC+. The first two chapters demonstrate the internal functionality of SnapOPC+ with a number of animated examples Principles of SnapOPC+ Restore functionality is explained in the chapter "SnapOPC+ Block Restore". Chapter "SnapOPC+ Read and Write Operations" shows with the help of several examples how data is written and read and how changes are tracked during a SnapOPC+ session. Last chapter explain how in practice data can be restored from a SnapOPC+ session. 29 In the following slides we will learn with help of simple animated examples how data blocks are handled by SnapOPC+ in different read and write scenarios. This first animation demonstrates what happens when a source data block is changed several times and how consequently the original data block is copied to the destination volume SDV only once. Here is where the significance of the word "first" in the "copy-on-first write" becomes obvious: a SnapOPC+ session copies a single data block only with the first overwrite instance, further overwrites of the same data block are discarded from a backup point of view. A SnapOPC+ session is meant for being able to restore the data from the time the SnapOPC+ was launched. For that purpose it is important to record only the first update of the data.

We observe the functionality using a single data block as an example. The data block is stored in the Source Volume and is colored yellow. The replication destination is Snap Data Volume one. Now we start the first SnapOPC+ session. Like we know, a tracking bitmap is created and consequently changes of the Source Volume are tracked and recorded. Technically, also the changes of the SDV itself are tracked, but that is irrelevant for this example, more about that later on. Data block one can be seen in the source volume and in the next step the application server wants to overwrite this block with the red colored content. Before ETERNUS DX overwrites the block number one it checks if this data block is already copied to SDV1. As this is the first write instance on this particular block, the yellow data is copied to the SDV and after that the new red colored content is written to the source. We have now a red data block in the source and a yellow, snapped data block in the SDV1. Next change takes place in the form of amber colored content to be written to the source. And again ETERNUS DX checks first if this particular data block has been previously changed. In our case the answer is "yes" and therefore the system discards the red data block in order not to lose the original yellow data content. That means the amber content will overwrite the red data block in the source. We will now create a second replication pair with the same Source Volume and a second Snap Data Volume, SDV2. After that we start a second SnapOPC+ session in parallel to the first one. Please note that we haven't stopped the first SnapOPC session, meaning it is still active. In step five we have amber content in data block one of the Source Volume and yellow content in the SDV1. Now the application server wants to write purple content to the source block number one. As this is a SnapOPC+ session, ETERNUS does not check if the data block exists in SDV1 - like it would do with a SnapOPC session - but instead checks if this data block one has been copied to SDV2. In this case the answer is "no" so next the amber content gets copied to SDV2. This shows us the difference between SnapOPC and SnapOPC+: the changes in the Source Volume are recorded only in the youngest Snap generation. Now we can overwrite the source data block with the purple content. Let us continue with the last example of this animation sequence. Although we pretty much already know what will happen, we look once more what happens when the application server wants to change once more the contents of data block one, this time with green content. ETERNUS checks if a copy of this particular block already exists in SDV2, consequently a copy process to SDV2 is prohibited. As a result ETERNUS replaces the purple source data content with the green data block. 30 The animation on the previous slide demonstrated the "copy-on-first-write" mechanism with one data block only. The animation on this slide shows us how SnapOPC+ works when several data blocks - in our case three - are being updated. The source volume contains three data blocks with yellow colored contents.

We create one replication pair with Snap Data Volume one and invoke the first SnapOPC session after which application server wants to write red content to replace the data block one of the source volume. ETERNUS DX checks if a backup exists for data block one at SDV1 and in our case the backup process starts and consequently the block one is overwritten with red colored content in the source. In step three of our animation the application server wants to write red contents to data block number two. But before the write can take place the original yellow content of data block two has to be backed up to SDV1. As the contents for data block two has not yet been copied to the SDV1, ETERNUS proceeds with the copy and consequently the red data content will overwrite the data block two in the Source Volume. Another SnapOPC replication pair is set up with SDV2 as a destination partner. After creating the second replication pair we start a second, parallel SnapOPC+ session. Again the application server wants to write red colored content but this time to data block number three of the Source Volume. Like seen in the previous slide, with SnapOPC+ the "copy-on-first-write" is done only with the latest Snap generation, meaning ETERNUS checks the backup status of this data block in SDV2 and consequently copies the data block three to SDV2. Next the red content is written to the Source Volume. In the final step of this animation sequence the application server wants to update the block number two in the Source Volume with green contents. Next the backup status for data block two is checked in SDV2. In our example there was no previous backup done, so the red colored data block is copied to SDV2. After this "copy-on-first-write" - from the second snap generation point of view - the green content is written to source data block two. 31 After the two previous examples of SnapOPC+ data block handling, we will now have a closer look at the restore functionality. Our Source Volume has got three originally yellow colored data blocks. After starting the first SnapOPC+ replication in step one we will do two red colored modifications at data block one and data block two in the Source Volume. This causes the data blocks one and two to be backed up in SDV1. In step 4 of our example we start a second SnapOPC session running in parallel with the still active first SnapOPC session. The application server updates data block three with red content and immediately after that the data block two is again updated with green content. The result of all this, a backup of the yellow data block number one and two reside in SDV1 and the yellow data block number three and the red data block number two are backed up to the SDV2 only. Now let us see what happens when we recover the Source Volume from SDV2 after step six. After restore the Source Volume has same contents as it had at the time when the second Snap was taken. With SnapOPC+ ETERNUS DX keeps internally track of where the data block to be restored resides; it can be either in the Source, in the latest SDV or in a younger SDV. Let's see what happened in our example. The red block number 1 doesn't reside in the SDV2 and as there is no younger SDV, we will use the Source Volume, in other words leave the block as it was.

After the second Snap was taken, both data block two and three have been overwritten and therefore we use the SDV2 to restore the data. Similarly, when restoring from SDV1, the original data for blocks one and two are stored in SDV1, but as block three doesn't exist in SDV1, we need to look to younger generations. Consequently the data is copied from SDV2 to the source. In reality the internal linking and tracking that the ETERNUS DX does with the snapped data is much more complicated than what was shown here. As what comes to restoring data from SnapOPC+, the most important lesson to learn is that by using internal algorithms and linking, ETERNUS DX ensures that it is always possible to restore the Source Volume to the state it had at the time when a particular Snap was taken. We are not quite yet finished with explaining the restore functionality; please move on to the next slide. 32 This slide continues from where the last slide left off. Even after a restore, ETERNUS must continue ensuring that the previously taken Snapshots can be used to restore the Source as it was at the time when the respective Snap was taken. Let's now see what that means on our example. From now on we are only interested about the both SDVs and the Source. If we had restored from the latest SDV - SDV2 - there was nothing more to do because we have all the necessary content either in the Source or in the SDVs to do a successful restore again at a later time. However, if we did the restore with SDV1, we can see that the red data block one would no longer be available in the Source and as that is the only occurrence of this data, it is necessary to copy this data block to SDV2. From this point onwards ETERNUS DX starts tracking the changes as before, following the principle of "copy-on-first-write". Following seven slides of this Web Based Training take a look at some typical read and write scenarios in more detail. 33 Like we have learnt in the beginning of this Web Based Training, the two volumes - Source and Snap Data Volume - can be mapped like any other volume by the server and consequently be fully accessible for applications and the operating system. The basic layout for the following slides consists of Source Volume and a total of three Snap generations. Each Snap generation has its own Destination Volume, which is a virtual LUN with a capacity equal to the Source Volume. Snap Data Volume holds the changed data of the Source Volume. The youngest Snap generation is labeled G3 and the two older generations G2 and G1. Next important element for our examples is the tracking bitmap, which holds a record of the changed data blocks since the SnapOPC+ session was launched. We start with a simple example: application server reads an unmodified data block directly from the Source Volume. This would be the typical situation when the application server continues working with its Source Volume normally, like it would without having SnapOPC+ running in the background. 34

On the previous page the Source Volume was mapped directly to the application server, in this example the application server reads the same data block but this time from the Destination Volume G3. In effect, for the application server this means access to the data as it was at the time when this SnapOPC+ generation number three was launched. The application server addresses a data block in the Destination Volume. This data block will be addressed at a virtual block address of the Destination LUN. SnapOPC Tracker checks the data status to know if the data has been changed since the Snap was taken, in other words, if it is to be fetched from Source Volume or from Snap Data Volume. In this example the data has not been changed, meaning ETERNUS DX fetches the data from the Source Volume. When reading unchanged data from the Destination Volume, the data is fetched in reality from the Source Volume. That requires additional mapping of the block addresses which is the cause for the slight performance hit. The older Snap generations, number two and one do not play a role in this read process. 35 This next example is similar to what we have already seen at single data block level earlier in this Web Based Training, now a bit more generic view to ETERNUS DX functionality for writing new data directly to the Source Volume. With this we will overwrite the original data. A white data block in the Source Volume represents the original data. The application server wants to write the striped data in the Source Volume, that is, to replace existing data. Before we can now overwrite the white colored block in the Source Volume, we have to do a "copy-on-first-write" to backup the original data block to the physical SDV. Physically the backed up white data block resides in the SDV of generation G3. Remember, few slides earlier we have learnt that the ETERNUS uses "backup data control information" to convert virtual block addresses to real ones. This BDC information is held on the physical SDV and it occupies only a fraction of its capacity. After the original data block is backed up, the "copy-on-first-write" process finishes with the update of the tracking bitmap. The bit responsible for this data block will be changed to "modified". Now the ETERNUS can overwrite the original content of the white block in the source with the new content. Like in the previous slide, the older Snap generations two and one do not play a role in this example. 36 We continue with the animation from where the last page left off, now the application server wants to read a data block from the Destination Volume "G3". First the SnapOPC Tracker checks the status of this data block. The bitmap table tells that the data block has been once overwritten, that means the data that the server wants resides in the physical Snap Data Volume. In practice this means that the application server can access the original data in the Snap Data Volume whereas the new data is available only in the Source Volume. This is a good example for a read process of a backup application during the backup procedure.

And again for this read process from Snap generation number three the older Snap generations two and one do not play a role. 37 In this example the application server wants to write in the Destination Volume and the newest data resides in the Source Volume. Two Snap generations exist already and we create and launch a third one for the same Source Volume. Application server addresses the data block in the Destination Volume to overwrite it, next ETERNUS DX checks the bitmap status to find out that this is the first write to this block, meaning the original data resides in the Source Volume. At this moment this particular data block resides only in the Source Volume. Should it be later overwritten in the Source Volume no copy-on-first-write would take place because the block would be flagged in the Tracker. Consequently, restore from G2 would not be complete, this block would be missing. Therefore, next ETERNUS checks the bitmap status of the next old Snap generation. As this is the first time this block is modified, the status of the Tracker is not flagged. Next the data block is copied from Source to SDV2 and the bitmap is flagged. Now ETERNUS writes the data block in the SDV3 and the data block is flagged in the Tracker. The end result from this is that G3 has been permanently changed and if it will be used for a restore, the restore will include the data just written to it. Anyway, because ETERNUS copied the original data from Source to G2, that can still be used for restoring the original data. Obviously, writing in the Destination Volume is not a good practice if the Snapshots are meant to be used for backup and restore purposes, but can be suitable for testing purposes. 38 In our next scenario the application server writes again in the Destination Volume, in this example the target SDV holds the newest data. As the data arrives to ETERNUS DX, the first task is to check the bitmap status, which obviously in this case is flagged. Before proceeding with the write - similarly as in the previous example - we need to see if the earlier Snap generation is relying on the availability of this data block in G3. The SnapOPC+ Tracker shows that this data block has not yet been addressed in Snap generation G2 and therefore needs to be copied over and consequently the Tracker is flagged. Now the new data can be written to G3. Like in the previous example, the earlier generation is relying on the availability of this data block in order to maintain its ability for a restore and therefore it is necessary to copy the data block over. Also in this example the Snapshot G3 gets permanently changed and can no longer be used for restoring the original data, but generations G2 and G1 retain their ability to restore the original data. As a side note; it is not necessary to copy this white data block to G1 because ETERNUS maps the block internally between G2 and G1 so that when G1 is restored this data block is included. 39 In the last example the application server writes again in the Destination Volume but this time the latest data is in a younger Snap Data Volume.

Striped data has been written in the Source Volume and the original data resides now in SDV G3. The application server wants to write the blue data block to the second Snap generation G2. Next ETERNUS DX checks the status of this data block in the previous generation G2. The data block has status "not modified" which means we need to copy the data block from G3 to G2 and consequently the Tracker is flagged as "modified". The same procedure follows with G1, the data block is copied and Tracker is flagged. Now the data block can be written to SDV G2. As you have noticed, ETERNUS first copied the original white content from G3 to both G2 and G1 and then overwrote the data block in G2 with blue content. The reason behind is not really important for our example but for the sake of completeness we will explain that. You noticed that in our animation the blue data block was smaller in size than the white block. This is to reflect the fact that the update from the server may be smaller than the tracking bitmap block size; for example 512 bytes versus 8192 bytes. To ensure data consistency in such cases ETERNUS copies the data block also to G2 because in the next step the data within the block may be overwritten only partially. This by the way is true for all ETERNUS DX copy operations, but for the sake simplicity we mention it only once here. The second important point is that both G2 and G1 need the white data block in G3 to be able to restore; as this data block is partially overwritten in G2, it needs to be copied also to G1. This concludes our animated examples demonstrating how ETERNUS SnapOPC+ works internally in various read and write scenarios. It is not in the scope of this Web Based Training to cover further details; for that and to gain practical experience with the ETERNUS DX Advanced Copy functions it is strongly recommend to join one of the available ETERNUS SF classroom trainings for more detailed examples using the AdvancedCopy Manager. 40 Equally like SnapOPC, SnapOPC+ is not a full backup like OPC. In order to restore the Source Volume contents to an earlier point in time, at least one SnapOPC+ generation and the existing Source Volume are needed. We have here four active SnapOPC+ replication pairs, all running in parallel and having the same Source Volume. We choose to restore the data as it was at the time when the third SnapOPC+ generation was launched. Restoring can be done by using the reverse OPC feature of the ETERNUS SF Advanced Copy Manager. Please note that the availability of reverse OPC functionality is ETERNUS DX model dependent. Due to the incremental backup mechanism - and contrary to the SnapOPC - all the older SnapOPC+ generations can - but do not have to - remain active for restoration. Please note, like with SnapOPC, after stopping a Snap session the respective SDV no longer exists. We could also choose to restore the G2. If the Sessions 1 through 4 were our incremental backups from Monday through Thursday, respectively, restoring Session 3 would mean that the Source Volume has been restored to the state it had on Wednesday; restoring Session 2 respectively would return the Source to the state it had on Tuesday at the time when the Snap was taken.

Before executing a restore from a particular SDV to the Source, ETERNUS copies internally all necessary content from the Source to the latest SDV to maintain its ability for a restore - otherwise the existing data in the Source would be overwritten with the data from the SDV. 41 An alternative for using ETERNUS SF ACM is to use the copy tools provided by the operating system and copy the contents of a Snap Data Volume manually. Depending on the ETERNUS DX model, the restore can be done using the available Operating System tools and/or with the reverse OPC functionality as explained in the previous slide. Please refer to the latest documentation for up-to-date status. In this example the Source Volume is mounted with read and write access, whereas the Backup Volume is read only. The advantage with this is that it is not possible to accidentally delete any data from the Backup Volume: naturally, the read only is valid just for the server; ETERNUS DX has always write access to the Backup Volume. If data gets accidentally deleted from the Source Volume, one can use the usual copy functionality of the operating system to restore the data. 42 After this presentation you will be familiar with the Advanced Copy function "Snap Data Pool". We will start with a functional description of the Snap Data Pool. For setting up the Snap Data Pool it is necessary to understand the related terminology. Chapter "Features" explains the advantages and the restrictions. The chapter "Configuration Guidelines" provides general guidelines for system configuration. Last topic shows how the Snap Data Pool is set up in ETERNUS Manager GUI. 43 Snap Data Pool is an Advanced Copy function that provides additional flexibility to the use of SnapOPC and SnapOPC+. Each Snap Data Volume must have a pre-set capacity that can only be estimated but not precisely calculated because we can't really know in advance how much space will be needed for the Snap data. Should Snap data exceed the available capacity, the copy process to this particular SDV is stopped. Consequently, with SnapOPC this particular generation will no longer be available and with SnapOPC+ this and all older generations will be no longer available. SDP provides on-demand capacity that can be taken in use if a particular SDV uses up its capacity. This additional storage capacity is made automatically available to the SDV so that the Snap session continues running without interruption. The Snap Data Pool consists of a user definable number of Snap Data Pool Volumes that serve all Snap sessions in the ETERNUS DX. Following two slides explain these terms and their functionalities in more detail. 44 There are three important terms associated with the Snap Data Pool functionality. There is one Snap Data Pool per ETERNUS DX system that holds all the SDP Volumes and it is generated automatically as the first SDPV is created

The second important term to understand is Snap Data Pool Volume. This is one of the available Volume types and used only for Snap Data Pools. An SDPV is created like any other Volume and will automatically become part of the Snap Data Pool. Maximum capacity for each SDPV is two Terabytes and it must be a multiple of the Snap Data Pool Element size - we'll explain SDPE on the following slide. There are two ways to create a SDPV: either with ETERNUS Manager Graphical User Interface or with the Command Line Interface. 45 SDPE is the smallest storage element that the SDVs can use on-demand basis to expand their capacity. For the DX Entry systems the unit size is fixed to one Gigabyte, with the Midrange and Enterprise models the administrator can choose the unit size to be either one, two or four Gigabytes. These Elements are automatically available as additional storage capacity for all SnapOPC and SnapOPC+ sessions without having to allocate them in beforehand. Without any user intervention, shortly before any active SDV would run out of capacity, it can take on the Elements one after another as long as they are available in the Snap Data Pool. After a Snap session is stopped the used SPDEs are released back to the SDP. To summarize: per ETERNUS system there can be one Snap Data Pool that can consist of several Snap Data Pool Volumes that in turn are made of Snap Data Pool Elements. The Snap Data Pool Elements are the storage units that are available for all the SnapOPC and SnapOPC+ sessions to expand their capacity when needed. 46 Let's have a look at the main features of Snap Data Pool functionality. When a SnapOPC or a SnapOPC+ session runs out of storage capacity all its data contents will be lost - in the case of SnapOPC+ also all earlier generations are lost. Please note that the risk of the Snap Data Pool running out of available Snap Data Pool Elements still exists and therefore it is still necessary for the System Administrator to keep an eye on the available SDP capacity but it is not necessary to do that for the individual SDVs and if necessary, SDPVs can be added to the Snap Data Pool. Further advantage of the SDP is that it is not necessary to separately set the Snaps to use it; one single SDP is a dynamic global resource for all Snap instances. The principle of SDP is similar to that of Thin Provisioning but these functionalities should not be mixed with each other: SDP is a license free functionality providing dynamic storage capacity for the Snapshots - the Snap Data Pool Volumes cannot be used for other purposes. 47 Like any normal Volume, SDPVs can be created in any RAID Group using any RAID level. Same restrictions as for normal Volumes apply for the maximal number of Snap Data Pool Volumes per single RAID Group; however it is recommended to have all the SDPVs created in the same RAID Group - except if encrypted and non-encrypted SDPVs are needed they must reside in separate RAID Groups.

For data security reasons encrypted Snap Data Volumes only expand to encrypted Snap Data Pool Volumes, equally non-encrypted SDVs only work with non-encrypted SDPVs. The following four functions are not available for SDPVs because they are either not needed or the same functionality is provided in a different way: Host Affinity and LUN Mapping are not needed as these Volumes are used system internally only, instead of LUN Concatenation and RAID Migration the total capacity of an SDP can be increased by adding more SDPVs to it. 48 Following three slides provide general configuration guidelines for setting up and using Snap Data Pool. One should not think that now that Snap Data Pool provides fully automatic storage capacity for the Snap Data Volumes, it is irrelevant what capacity the SDVs should have. The more concurrently active Snaps there are the higher impact this functionality has on the system internal performance and therefore it should really be considered only as a safety net when not having a good idea of the needed capacity for a new SDV. As a rule of thumb the SDV should have a capacity of about 30 to 50 per cent of the Source Volume. Snap Data Pool is a good option when implementing a Snapshot scheme for a new usage. After having observed long enough the actual capacity usage of the related Snaps one could choose the optimal size for them and thus keep up maximal performance. With the ETERNUS DX Midrange and Enterprise systems it is possible to define the size of the SDPEs - with DX Entry it is fixed to one Gigabyte - we will now have a look at the practical consequences this decision has. Let's assume we have an SDP with a total capacity of 40 Gigabytes and we set the SDPE size to four Gigabyte. We have 50 parallel Snaps running and 10 of them require more capacity - not necessarily 4 Gigabytes each but this is now the smallest unit available - that results in a total of 40 Gigabytes used space, which in turn means that all available SDP capacity is used up. Should any of the other 40 sessions require expanded capacity we would lose the whole Snap Data Pool. Like the case usually is, we can't estimate how many of our SDVs will need additional capacity and we don't know how much each needs, it is better to use smaller SDPE size to maximize the number of available SDPEs. 49 Next we will have a look at some recommendations regarding the performance aspects associated with Snap Data Pool, For performance critical environments one should avoid using Snap Data Pool as it does have an impact on the system internal performance. It is recommended to dedicate one RAID Group for all the SDPVs, in other words not to have both Open Volumes and Snap Data Pool Volumes in the same RAID Group. As each SDVP adds load on the processing power of the CM, it is recommended to divide the SDPVs equally between the available Controller Modules. If both encrypted and non-encrypted SDPVs are needed then they must reside in separate RAID Groups that are allocated to different CMs. 50

Like already mentioned, although Snap Data Pool relieves the system administrator from monitoring the capacity usage of individual Snap Data Volumes, it is still very important to monitor the available capacity in the Snap Data Pool. As a guideline, when SDP usage exceeds 50 per cent, the Administrator should keep a close eye on it and start considering adding capacity to the Pool. Please note that the availability must be considered separately for encrypted and non-encrypted Volumes as they cannot be cross-used. As the usage reaches 70 per cent the Administrator should take immediate action to add capacity to the pool. Remember, the consequences from Snap Data Pool running out of capacity are the same as from a Snap Data Volume getting full: the Snap is lost. 51 In the last slide of this Web Based Training module we have a look at the ETERNUS Manager GUI to have a feeling of how an SDP is set up. As the first step, we choose to set up the Snap Data Pool and like we remember, the pool is automatically set up after we have created the first Snap Data Pool Volume. Bear in mind the configuration guidelines regarding load balancing between the Controller Modules when selecting the RAID Group where the Snap Data Pool Volume is to be created. Last screen shot shows the configuration step for creating the Volume. This same way you can later create additional Volumes to add capacity to the Pool. 52 This brings us to the end of this Web Based Training session module. This module served as an introduction to the ETERNUS Advanced Copy functions called SnapOPC, SnapOPC+ and Snap Data Pool. These functions are built-in features in ETERNUS DX storage systems. Please note that Advanced Copy functional improvements can be introduced in later ETERNUS DX models and firmware releases, therefore it is advised always to use the latest handbooks for reference. For more information about the other ETERNUS Advanced Copy functions please check the other available Web Based Training modules. For practical experience with ETERNUS check also the availability of classroom trainings for the ETERNUS DX and SF products.