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.
<br />
# ls<br />
lost+found test1 test2 test3 test4 testindex1<br />
# touch test5<br />
# touch test6<br />
# mkfile 2k testindex2We check our dependent copy again:
# iiadm -i<br />
/dev/rdsk/c1d0s3: (master volume)<br />
/dev/rdsk/c1d1s3: (shadow volume)<br />
/dev/rdsk/c1d1s4: (bitmap volume)<br />
Independent copy<br />
Latest modified time: Fri Apr 25 18:16:59 2008<br />
Volume size: 273105<br />
Shadow chunks total: 4267 Shadow chunks used: 0<br />
Percent of bitmap set: 0<br />
<b>(bitmap dirty)</b>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.
# mkdir /backup<br />
# mount /dev/rdsk/c1d1s3 /backupJust for comparision, we have a short look at our master volume again:
# cd /mnt<br />
# ls<br />
lost+found test2 test4 test6 testindex2<br />
test1 test3 test5 testindex1Now we check our copy:
# cd /backup<br />
# ls<br />
lost+found test1 test2 test3 test4 testindex1We 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.
# tar cfv /backup20080424.tar /backup<br />
a /backup/ 0K<br />
a /backup/lost+found/ 0K<br />
a /backup/test1 1K<br />
a /backup/test2 1K<br />
a /backup/test3 1K<br />
a /backup/test4 1K<br />
a /backup/testindex1 1KAs you see, no test5, test6 or testindex2. Okay, we have made our backup, now let´s sync our copy.
# iiadm -u s /dev/rdsk/c1d1s3That´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.
# iiadm -i<br />
/dev/rdsk/c1d0s3: (master volume)<br />
/dev/rdsk/c1d1s3: (shadow volume)<br />
/dev/rdsk/c1d1s4: (bitmap volume)<br />
Independent copy<br />
Latest modified time: Fri Apr 25 19:30:19 2008<br />
Volume size: 273105<br />
Shadow chunks total: 4267 Shadow chunks used: 0<br />
Percent of bitmap set: 0<br />
<b>(bitmap clean)</b>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.
# mount /dev/dsk/c1d1s3 /backup<br />
# cd /backup<br />
# ls -l<br />
total 30<br />
drwx------ 2 root root 8192 Apr 25 18:10 lost+found<br />
-rw------T 1 root root 1024 Apr 25 18:10 test1<br />
-rw------T 1 root root 1024 Apr 25 18:11 test2<br />
-rw------T 1 root root 1024 Apr 25 18:11 test3<br />
-rw------T 1 root root 1024 Apr 25 18:11 test4<br />
-rw-r--r-- 1 root root 0 Apr 25 18:20 test5<br />
-rw-r--r-- 1 root root 0 Apr 25 18:20 test6<br />
-rw------T 1 root root 1024 Apr 25 18:11 testindex1<br />
-rw------T 1 root root 2048 Apr 25 18:20 testindex2</blockquote>
</code>It´s the exact copy of the filesystem in the moment when you´ve initiated the copy.
Okay, now let´s play again with our point-in-time copy. Let´s create some files in our master volume:
<blockquote><code># cd /mnt<br />
# touch test7<br />
# touch test8<br />
# mkfile 3k testindex2</blockquote>
</code>Please note, that i´ve overwritten the 2k sized version of <code>testindex2</code> with 3k sized version.<br />
A quick check of the directories:
<blockquote><code># ls /mnt<br />
lost+found test2 test4 test6 test8 testindex2<br />
test1 test3 test5 test7 testindex1<br />
# ls /backup<br />
lost+found test2 test4 test6 testindex2<br />
test1 test3 test5 testindex1Okay, the directory are different. Now let´s start the backup again.
# tar cfv backup20080425.tar /backup<br />
a /backup/ 0K<br />
a /backup/lost+found/ 0K<br />
a /backup/test1 1K<br />
a /backup/test2 1K<br />
a /backup/test3 1K<br />
a /backup/test4 1K<br />
a /backup/testindex1 1K<br />
a /backup/test5 0K<br />
a /backup/test6 0K<br />
a /backup/testindex2 2KOkay, 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.
# cd /<br />
# umount /backupAfter this we sync the slave volume with the master volume.
# iiadm -u s /dev/rdsk/c1d1s3And when we compare the filesystems, they are identical again.
# mount /dev/dsk/c1d1s3 /backup<br />
# ls /mnt<br />
lost+found test2 test4 test6 test8 testindex2<br />
test1 test3 test5 test7 testindex1<br />
# ls /backup<br />
lost+found test2 test4 test6 test8 testindex2<br />
test1 test3 test5 test7 testindex1You can play this game forever, but i will stop now, before it gets boring.