A cheap snapshot system (Part 2)

People delete files by accident and the work is lost if you do not have a system that takes periodic snapshots of the system to be able to recover files, however a lot of “snapshot” systems cost a lot of money, something a SME never has enough of, so I wrote my own little utility with the help of some “rotate” utility I found on the Internet using one of the best features Linux has called “hard-links”.

Please checkout the previous blog entries for this:

  1. http://www.systemadministratorblog.com/2014/07/a-cheap-snapshot-system-part-1/

The Main Loop
The main loop is used for any directory, since I showed /var above, I keep on using /var.
In the script file shown in Part 3 there are options you can specifiy:

  1. how many backup per hour
  2. how many backups daily (5,6,7)
  3. how many backups weekly (4,5)
  4. how many backups monthly (1 .. whatever)

For each of the hourly,daily,weekly and monthly the main loop does the same, note I show mockup code here and assume I would have set the backup number to 3:

# rm the last backup in the chain
rm -rf backup.3
# move the next backups one up each
mv backup.2 backup.3
mv backup.1 backup.2
# make HARDLINKS from the BASEDIRECTORY (0) to the first backup
cp -al backup.0 backup.1
# now replace the NEW FILES ONLY in the base directory
rsync -a --delete source_directory/  backup.0/

Giving Users Access to the Snapshot System

One of the MOST important things to keep in mind is that the user must NOT have access to the snapshot drive, it must be completely READ ONLY. Further when backup up a file it must NOT be read at the same time or the backup will fail, so the best way to do this:

  • have a snapshot directory with access by root only
  • have another separate directory that is READ ONLY by the user so they cannot delete an already deleted file
  • Whatever system you use it must keep the permission system intact such that user A cannot read user’s B files.

Thankfully Linux makes all of this possible.

I use SAMBA to give people access to a full Active Directory Server, imitating a Windows Server to give Windows clients access to files/directories base don users permissions. My directory structure for all of the SAMBA stuff looks like this below (note the .snapshot directory)
<pre>
..
/samba
– documents
– .snapshot
– spreadsheets
– .snapshot
– photoshop
– .snapshot
– powerpoint
– .snapshot  – and_so_on
</pre>
Now that does not give users access to the directories directly, I have that configured in the /etc/smb.conf file, so for example users see /samba/documents as w:/ on their workstations.

I backup all directories (e.g. documents) into /snapshot that is accessible by root only:
<pre>
drwx——  21 root     root     4096 Jan  7 22:12 snapshot
</pre>
In parallel I have another directory called /snapshotUser that user can (indirectly) access:
<pre>
drwxr-xr-x  21 root     root     4096 Jan  7 22:12 snapshotUser
</pre>
I use a local NFS based mount to make /snapshot visible for users mounted at /snapshotUser:
<pre>
mount -o ro 127.0.0.1:/snapshot /snapshotUser
</pre>

That still will give the user no access to the system (users have /bin/nologin set in /etc/password) so I need to give them access through SAMBA to the snapshot system.

For each directory I backup using my utility I have a softlink the backup directory in the samba tree, for example:
<pre>
ls -al /samba/documents

lrwxrwxrwx  1 root  domusers       32 Aug 25  2012 .snapshot -> /snapshotUser/documents

</pre>

Please continue reading at: http://www.systemadministratorblog.com/2014/07/a-cheap-snapshot-system-part-3/

2 thoughts on “A cheap snapshot system (Part 2)”

  1. Pingback: A cheap snapshot system (Part 1) | System Administrator Blog

  2. Pingback: A cheap snapshot system (Part 3) | System Administrator Blog

Leave a Comment

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

You must tick the checkbox for 'I am not a robot' before you can submit your comment!