c0t0d0s0.org

Okay, the next installment of the "Less known Solaris Features" series is online. This time i will discuss the feature Point in time copies with AVS. As i have to go through some theory at first, it´s a quite long tutorial. It´s the longest so far. Point-in-time copies are a rather unusual feature for small installations, but they are absolutly essential for many enterprise customers. And when you really think about it, there are many usecases even for small installations.

• Part 1: Introduction
• Part 2: Basics
• Part 3: Independent copy
• Part 4: Dependent copy
• Part 5: Compact dependent copy
• Part 6: Preparation of the test environment
• Part 7: Starting a point-in-time copy
• Part 8: Working with point-in-time copies
• Part 9: Disaster Recovery
• Part 10: Administration
• Part 11: Conclusion

Have fun while trying out the feature!

I hope i gave you some insight into this really interesting feature of Solaris and Opensolaris. There are vast posibilities to use it in your daily use. It´s not limited to desaster recovery or backups. One of my customers uses this tool to create independent copies of their database. They take a snapshot at midnight and export it on a different database server. The rationale for this process: They run some long running analytics with a huge load on the I/O system on this independent copy. By using the copy the analysis doesn´t interfere with the production use of the database. Another customer uses this feature for generating test copies of their production data for testing new software versions. You see, the possibilties are vast and virtually endless.

Okay, there are several administrative procedures with the point-in-time copy functionality. I will describe only the most important ones, as i don´t want to substitute the manal with this tutorial.

The process of syncing master and shadow is bidirectional. You can´t not only update the shadow from the master, you can update the master from the shadow as well. This is a really neat feature for diaster recovery.

We´ve created the point-in-time-copy in the last part of the tutorial, but this is only one half of the story. In this part, we will use the this feature for backup purposes. The procedures are independent from the choosen point-in-time copy mechanism.

Okay, before using the merits of point-in-time copies, we have to configure such copies. The configuration of this copies is done with the with the iiadm command. In this part of the tutorial i will show you how to configure the different kinds of point-in-time copies.

After all this theory, i will go into more practical stuff. In the follwing parts of this tutorial i will give you an introcution to point-in-time copies with AVS. But at first we have to prepare some things.

The compact dependent copy is similar to the normal dependent copy. But this dog knows an addtional trick: The shadow and the master doesn´t have to be at the same size.

The mechanism of dependent copies was introduce to get rid of this initial sync, as there are circumstances where this initial copy would pose to much load to the system.

The most important point about independent copies are in their name. The point in time copy is an independent copy of your original data. You can use it on it´s own and the copy doesn´t need the original data to work.

One of this methods is the usage of the point in time copy functionality of the Availibility Suite. I´ve wrote about another function of AVS not long ago when i wrote the tutorial about remote replication. Point-in-time-copy and remote replication are somewhat similar (you detect and record changes and transmit those to a different disk, albeit the procedures are different). Thus it was quite logical to implement both in the AVS.

The basic idea of Point-in-Time copies is the idea to freeze the contents of a disk or a volume at a certain time, thus other processes can work on data of a certain point in time, while your application works on the original dataset and changes it.

Why is this important? Let´s assume you want to make a backup. The problem is quite simple. When a backup takes longer than a few moments, the files backup first my represent an different state of the system than the files backup last. You backup is inconsistent, as you´ve done a backup of a moving target. Okay, you could simply freeze your application, copy it´s data to another disk (via cp or dd) and backup it from there or backup it directly and restart your application, but most of the time, this isn´t feasible. Let´s assume you have a multiterabyte database on your system. A simple copy can take quite a time, in this time your application doesn´t work (at least when you database has no backup mode).

Okay, simple copy is to ineffective. We have to do it with other methods. This tutorial will show you the usage of a method integrated into Opensolaris and Solaris.