What Is Snapshot and How It Works?

Hello everybody,

What is snapshot in computer worlds and how it works? How you ever heard about snapshots in Cloud, SAN or Virtualization industry? No. Don’t worry. You can get your answer right now:

Snapshot is like a backup of your data, somehow, but it uses a different method. Traditional backup copies your data bit by bit to another disk or tape. It’s like an image of your data to somewhere else.  Snapshot uses Metadata copy of your data. Meta means change and data means your information. So, it copies your changed data to somewhere that reserved for data changes (PiT) and it doesn’t touch those data on original disk or source disk that it doesn’t change.  

In order to achieve this goal, software of snapshot creates a table called Bitmap of Track Pointers and manages it. Assume there is a pointer on Bitmap table for each track on disk. Of course, it depends on software design but for our purpose let’s assume this. Therefore, software uses pointer 1 for track 1 and pointer 2 for track 2 and so forth.

So, when you make a snapshot, it creates Bitmap of Track Pointers. Now, please look at picture 1, if any data changes on source or original disk, it copies the original value to PiT area and then overwrite new data to related track. Then it marks the corresponded pointer in Bitmap table as a changed track. For example, you want to write a file which goes to track 5 and 6 on disk. Before overwriting data with new values, software copies the values on track 5 and 6 to PiT area and then it overwrites to disk. Also, it marks or tags pointer 5 and 6 in Bitmap of Track Pointers table as a metadata or data changed.

Figure 1

Now, let’s assume that you want to revert your server for any reason. In other words, you want to restore your server to pervious state before getting snapshot. In this case, software goes through the Bitmap of Track Pointers table. Let’s back to our example above. Software goes to marked or tagged pointers in tables and finds track 5 and 6. It copies the values of track 5 and 6 on PiT area to track 5 and 6 on original disk and doesn’t change other tracks since there were no changes on those tracks. And that’s all. Your server restored to the same state that it was before getting snapshot.

 Figure 2

Advantages:   

1. It’s so fast. Getting snapshots is so fast and it takes few seconds. It’s not like image copy that takes hours and hours to copy your data.
2. Restoration is also fast since it copies only changed data.
3. You save disk space because you save only changes not all data. 

Disadvantage:

1. It’s not a complete or image backup. So, if you original disk die, you will lose your data.
2. You may experience performance issue during snapshot

That’s all.

Regards,

Khosro Taraghi

Synchronization of Clock With ntpd

Hello Everyone,

 

The ntpd is a daemon that synchronizes the system clock to remote ntp time server or local reference clock. The ntpd's configuration file is /etc/ntp.conf. In order to set up a ntp server in Fedora host, you  should configure this file first.

 vi /etc/ntp.conf    

It is better to comment all default server's list in this file and added open and free stratum-1 server that I found on the internet (clock.nyc.he.net)  

 

server clock.nyc.he.net

If you want to enable logging and statistics files, you should add following lines to this file as well:

statistics clockstats cryptostats loopstats peerstats

logconfig =all

logfile /var/log/ntp

statsdir /var/log/ntpstats/

Also, we should add a rule in iptables to accept all incoming udp protocols for destination port 123.

iptables -t filter -I INPUT -p udp –dport 123 -j ACCEPT

Now, we are ready to start our ntp daemon:

service ntpd start

Here is the log records in /var/log/messages when I started ntpd:

May 16 21:42:32 f13 ntpd[3690]: ntpd 4.2.6p1@1.2158-o

May 16 21:42:32 f13 ntpd[3691]: proto: precision = 0.106 usec

May 16 21:42:32 f13 ntpd[3691]: 0.0.0.0 c01d 0d kern kernel time sync enabled

May 16 21:42:32 f13 ntpd[3691]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123

May 16 21:42:32 f13 ntpd[3691]: Listen and drop on 1 v6wildcard :: UDP 123

May 16 21:42:32 f13 ntpd[3691]: Listen normally on 2 lo 127.0.0.1 UDP 123

May 16 21:42:32 f13 ntpd[3691]: Listen normally on 3 eth0 192.168.2.5 UDP 123

May 16 21:42:32 f13 ntpd[3691]: Listen normally on 4 lo ::1 UDP 123

May 16 21:42:32 f13 ntpd[3691]: Listen normally on 5 eth0 fe80::a00:27ff:fe02:f415 UDP 123

May 16 21:42:32 f13 ntpd[3691]: Listening on routing socket on fd #22 for interface updates

May 16 21:42:32 f13 ntpd[3691]: logging to file /var/log/ntp

All ntp server's statistics file are located in /var/log/ntpstats/ and the following is the records of peerstats file:

[root@f13 ~]# cat /var/log/ntpstats/peerstats

55486 10480.347 209.51.161.238 9024 -0.014972077 0.055863590 7.937508078 0.000000060

55486 10547.406 209.51.161.238 9024 -0.013583095 0.049342619 3.937763318 0.001388983

55486 10613.364 209.51.161.238 9024 -0.010081588 0.041968563 1.938010883 0.004253083

The peerstats file records peer statistics information. This includes statistics records of all peers of a NTP server. Each valid update appends a line to this file. The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next two fields show the peer address in dotted-quad notation and status. The status field is encoded in hex in the format described in Appendix A of the NTP specification RFC 1305. The final four fields show the offset, delay, dispersion and RMS jitter, all in seconds.

Another ntp server's statistics file is /var/log/ntpstats/loopstats and the following is its records in this file:

[root@f13 ~]# cat /var/log/ntpstats/loopstats

55486 10680.412 -0.003679314 452.701 0.001300834 0.249356 6

55486 10874.342 -0.009402045 450.961 0.002361007 0.657753 6

55486 11264.377 -0.008711860 447.721 0.002221960 1.300365 6

It records the loop filter statistics information. Each update of the local clock outputs a line to the file. Again, the first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next five fields show time offset (seconds), frequency offset (parts per million - PPM), RMS jitter (seconds), Allan deviation (PPM) and clock discipline time constant.

In order to demonstrate that my host and guest machine work correctly, I ran  ntpstat command in both machine and these were the outputs:

For host:

[root@f13 ~]# ntpstat

synchronised to NTP server (209.51.161.238) at stratum 2

   time correct to within 42 ms

   polling server every 512 s

For guest:

[root@vm01 ~]# ntpstat

synchronised to NTP server (192.168.2.5) at stratum 3

   time correct to within 131 ms

   polling server every 256 s

 =======================================

Accuracy:  As you noticed in ntpstat command, the time correction is within milliseconds and don't forget that the accuracy is also depend on network delay and distance as well.

Advantages:   The advantage of using ntpd among other time synchronization mechanisms is its continuous adaption to a time server time provided in the internet.  

Disadvantages:   It may take up to 30 minutes for the client's clock to synchronize for the first time on a time server. If, in addition, the difference between the two clocks is more than a few minutes, it can take much more time for synchronization to occur for the first time.

Thanks All,

Khosro Taraghi