After creating a filesystem share and mounting it on your client system, you now can actually start taking snapshots.

2.2. Taking snapshots and rollback

2.2.1. Take a first snapshot

With the ZFS appliance running, open your webbrowser and browse to “https://192.168.56.100:215
Go to “shares“. Hover your mouse over the share, you created in 2.1.1 and click on the pen – icon.
In the next window, click on “snapshots” in the upper right.
ZFSAttack_02_11_snapshot1

Notice the setting of snapshot visibility, which is inherited from the project.
Now, take a manual snapshot of your filesystem by clicking the “+” – icon next to “snapshots“.
ZFSAttack_02_12_snapshot2
Type in a name of your choice and click “apply
ZFSAttack_02_13_snapshot3

Since we did not create any data inside the filesystem, the snapshot is of course empty.
You might not want to do this in real life, so let’s do something, that’s actually useful.

2.2.2. Create data and take second snapshot

In your virtual database machine, enter the shell window and go to your mounted directory.

[root@localhost ~]# cd /mnt/zfsapp/

create a very important file by typing the following command:

[root@localhost zfsapp]# echo "do not loose this" > important.txt

If you now look at the contents of your directory, you will notice two things:

[root@localhost zfsapp]#  ls -la 
total 11
drwx------+ 3 nobody     bin           3 Aug 19  2013 .
drwxr-xr-x  5 root       root       4096 Aug 19 04:04 ..
-rw-r--r--+ 1 nobody     nobody       18 Aug 19  2013 important.txt
dr-xr-xr-x+ 4 root       root          4 Aug 19  2013 .zfs

First, the owner of your file is not root. Thats because of the NFS settings you provided during the export on the appliance. For this lab, that’s okay. In real life, you might want to restrict the access for your data.
Second, there is a hidden folder called .zfs.
The .zfs folder can be seen, because of the visibility option in the webinterface of the ZFS Appliance.

Go back to your webbrowser and take a second snapshot, using the same method as before.
ZFSAttack_02_14_snapshot4
This second snapshot was taken after the creation of our textfile, so it will (hopefully) include the file.

Now, in your database machine, edit your very important text file by typing:

[root@localhost zfsapp]# echo "lost it" > important.txt

show the contents of the file by typing

[root@localhost zfsapp]# cat important.txt
lost it

So your original message is gone now. But, don’t worry, we can retrieve it.

2.2.3. Retrieve lost data using ZFS rollback

To do this, there are actually two ways.

Remember the .zfs subfolder?
cd into it and you will see a subfolder called “snapshots“. And inside this subfolder, there are our two snapshots.

[root@localhost zfsapp]# cd .zfs/snapshot/
[root@localhost snapshot]# ls -la
total 3
dr-xr-xr-x+ 4 root       root 4 Aug 19  2013 .
dr-xr-xr-x+ 4 root       root 4 Aug 19  2013 ..
drwx------+ 2 nobody     bin  2 Aug 19  2013 mysnap1
drwx------+ 2 nobody     bin  3 Aug 19  2013 mysnap2

mysnap1 is an empty folder, but mysnap2 should contain your very important file. Let’s take a look at this directory:

[root@localhost snapshot]# cd mysnap2
[root@localhost mysnap2]# ls -la
total 3
drwx------+ 2 nobody     bin         3 Aug 19  2013 .
dr-xr-xr-x+ 4 root       root        4 Aug 19  2013 ..
-rw-r--r--+ 1 nobody     nobody     18 Aug 19  2013 important.txt

There is your lost file. Take a look at its contents:

[root@localhost mysnap2]# cat important.txt 
do not loose this

As you can see, the message is still intact. Now, you can recover the file by simply deleting the broken version and copying the backup to its original location:

[root@oraclelinux6 mysnap2]# rm /mnt/zfsapp/important.txt 
rm: remove regular file `/mnt/zfsapp/important.txt'? y
[root@localhost mysnap2]# cp important.txt /mnt/zfsapp/
cp: overwrite `/mnt/zfsapp/important.txt'? y

And there it is:

[root@localhost mysnap2]# cat /mnt/zfsapp/important.txt 
do not loose this

This is an extremely basic example. But the same method can be used to very easily recover single files or complete folder structures.

The second way to recover lost data using zfs rollback is to rollback the whole filesystem.

First, let’s create some chaos by deleting the file, you just worked so hard to recover.

[root@localhost mysnap2]# cd /mnt/zfsapp/
[root@localhost zfsapp]# rm important.txt 
rm: remove regular file `important.txt'? y

Now, go back to your zfs appliance to the snapshot properties of your share.
ZFSAttack_02_14_snapshot4

Hover your mouse over “mysnap2” and notice the three icons on the right. Click the leftmost icon (a rotating arrow). This will restore your filesystem to the moment, the snapshot was taken. You will see a warning message, because this action is irreversible.
ZFSAttack_02_15_snapshot5
Click okay.

On the linux machine, you will see, that the file is back and the recovery process worked.

2.2.4. schedule snapshots

You do not have to manually take snapshots of your file system. If you want to take regular snapshots, you can create a schedule.

In the web interface of the zfs app, navigate to the page, where you created and rolled back the snapshots in the last section.
You certainly have already noticed the schedules button next to snapshots. Click on the “+” – icon next to schedules.
http://portrix-systems.de/wp-content/uploads/ZFSAttack_02_30_schedule
Here you can create one or more snapshot schedules. The interface is quite self explanatory. Just select the frequency, how often a snapshot will be taken. On the right, you can configure, how many snapshot you want to keep, before they are removed.
Feel free to play around with this feature, if you like. Create snapshots, modify files, delete stuff, rollback…

In the next part of this lab, you will create a ZFS clone of your filesystem.

Leave a Reply

Your email address will not be published. Required fields are marked *