Written by J. Moellenkamp on
Reading time: 2 minutes
SolarisEnglish
Less known Solaris Features: Point-in-time copy with AVS - Part 8: Working with point-in-time copies
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, let´s play around with our point-in time copy. At first we check the filesystem on our master volume mounted at /mnt. Nothing has changed. The AVS doesn´t touch the master volume. But now let´s create some files.
We check our dependent copy again:
Please look at the highlighted part. The system detected the changes to the master volume and marked the changed block on the bitmap volumes. The bitmap is “dirty” now.
Okay, now let´s use our copy. We create a mountpoint and mount our shadow volume at this mountpoint.
Just for comparision, we have a short look at our master volume again:
Now we check our copy:
We see the state of the filesystem at the moment we´ve created the point-in-time copy. Please notice the difference. The files created after initiating the copy are not present in the shadow.
You can make everything you want with the filesystem on the shadow volume. You can even write to it. But for this tutorial, we will make a backup from it. Whatever happens with the master volume during this backup, the data on the shadow won´t change. Okay, that´s isn´t so interesting for a few bytes, but important for multiterabyte databases or filesystems.
As you see, no test5, test6 or testindex2. Okay, we have made our backup, now let´s sync our copy.
That´s all. What have we done. We told the AVS to update the shadow copy on /dev/c1d1s3. Whenever you specify a disk or volume directly, you use the name of the shadow volume. A master volume can have several shadow volumes, but there can be only one shadow on a volume. So the copy configuration can be specified wth the shadow volume. The -u s tells AVS to do an update (not a full copy) to the slave (from the master). Okay, now let´s check the copy again.
Please look at the highlighted part again. The bitmap is clean again. The master and the shadow are in sync.
Okay, let´s check it by mounting the filesystem.
Okay, the directory are different. Now let´s start the backup again.
Okay, test7 and test8 didn´t made it into the tarball, as they were created after updating the point-in-time copy. Futhermore we´ve tared the 2k version of testindex2 not the 3k version. So you can backup a stable version of your filesystem, even when you modify your master volume during the backup.
Okay, now we can unount the filesystem again.
After this we sync the slave volume with the master volume.
And when we compare the filesystems, they are identical again.
You can play this game forever, but i will stop now, before it gets boring.