Scott O'Brien

Note: This post is one in a series aimed to be a tutorial eventually, it’s not currently finalised and at the moment exists as a place for collating thought and collecting feedback

In part 1 of this blog post, I showed you how I created a script that would, when run, rotate your snapshots on a ZFS filesystem. For this to be usable, we need to create a mechanism for having it be automatically ran. We’ll do this with a cronjob.

On Unix systems, the cron daemon is used to execute scheduled commands. Picture it much like windows task scheduler for all you windows kiddies.

I saved the backup script we wrote yesterday to /FileStore/backups.sh. The first thing I want to get running is my hourly backups. To do this, we’ll start editing our cron file

sudo crontab -e

The crontab utility is a program used to edit the tables that drive the cron daemon.

On my OSX box, information about how to set up the cron file can be found in ‘man 5 crontab’

Basically, cron examines cron entries once every minute. the fields that we’ve got to play with are (in this order)

field allowed values
—– ————–
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

Having said that, it’s time to think about when we want to create our snapshots. Because I intend machines to do their backups to the server on the hour, I’ll be creating my snapshots at half past the hour. My cron file now looks like this (for hourly snapshots with 24 rotations, daily snapshots with 7 rotations, Weekly snapshots with 4 rotations.

#**Snapshots for the Filesystem**
30 * * * * /bin/bash /FileSystem/backups.sh hourly 24
30 6 * * * /bin/bash /FileSystem/backups.sh daily 7
30 6 * * sun /bin/bash /FileSystem/backups.sh weekly 4

Now that that concludes our section on setting up my rotating snapshots.

Other posts to come in the series:
1. Selecting the hardware
2. Installing the Operating System
3. Setting up File systems & Snapshots
4. Allowing access through NFS & SAMBA
5. Setting up encrypted off-site backups
6. Configuring Windows & Linux clients to dump backup info to the FileServer
7. My router setup, configuring IP tables & torrents on a low-powered server.

Note: This post is one in a series aimed to be a tutorial eventually, it’s not currently finalised and at the moment exists as a place for collating thought and collecting feedback

Setting up the FileSystems is a trivial task.  First, you can see that when we’ve created a storage pool ‘datastore’ it created a filesystem for us (also called datastore) that can act as a container for child file systems.  I’m going to go ahead and create a place to store my media and downloads now

zfs create datastore/media

for now I’ll also want a place to store my backups.  It’s worth noting that while my media filesystem will contain compressed MP3’s and the like, it’s kind of a waste of CPU power to compress it, but my backups will be a lot of PHP pages and what not, so lets go ahead and enable compression on this one

# zfs create datastore/backups
# zfs set compression=on datastore/backups

As appalled as I am of my mums backup habits, one of the requirements of this server was to provide a medium for backing up her data without her having to do anything, so lets set up backup locations for my laptop (MacShell) and a place for mum (mum) assigning both of these 20GB quota’s (ok, MacShell gets 120GB)

# zfs create datastore/backups/MacShell
# zfs create datastore/backups/mum
# zfs set quota=120G datastore/backups/MacShell
# zfs set quota=20GB datastore/backups/mum
# zfs get datastore/backups/mum

Now, the idea is that a cron job will run rsyncing over the files every hour, on the hour.  For many reasons (in case I get a virus and need to revert back, in case somebody hacks in and does bad stuff, etc, etc) I’m going to choose to create Snapshots so I can roll back to a previous version.

The convention I want is hourly.HOUR, daily.DAY, weekly.WEEK for up to 7 days and 4 weeks.  This also means that once I delete a file, I won’t recover the space that it took (once a snapshot of the file has been created) in my data pool until the end of the 4 week period.  for instance, hourly.0 will be the last hours snapshot, hourly.1 will be the 2nd last hours snapshot, etc.

the following bash script will take care of the desired snapshots.  It’s based on a concept I took from this rolling snapshots made easy post but I like my scripted way of doing rotating snapshots much better.

#!/bin/bash

#print out usage
if [ $# -ne 2 ]
then
echo “Usage: snapshot.sh [snapName] [max]”
echo “  eg. snapshot.sh hour 24″
fi

#if the max snapshot already exists, just delete it
if [ `zfs list -t snapshot | grep datastore@$1.$2 | wc -l` -eq 1 ]
then
zfs destroy -r datastore@$1.$2
fi

#
for ((i=$2-1; i >= 0; i–)); do
if [ `zfs list -t snapshot | grep datastore@$1.$i | wc -l` -eq 1 ]
then
#this snapshot exists, so we want to move it up one
zfs rename -r datastore@$1.$i @$1.$[$i+1]
fi
done

zfs snapshot -r datastore@$1.0

so with this snapshot beauty in place, lets say I had an existing file and structure in place

root@thumper:/datastore/backups/MacShell# pwd
/datastore/backups/MacShell
root@thumper:/datastore/backups/MacShell# tree
.
|– hello_world.txt
`– someDir
`– someFile.dat

1 directory, 2 files

BUT, I had a snapshot in place

# /snapshot.sh hourly 24

then I did something silly like delete my entire backup directory (Oh No!!)

# rm -R *
# ls -l
total 0

never fear! check the snapshots

root@thumper:/datastore/backups/
MacShell/.zfs/snapshot/hourly.0# tree
.
|– hello_world.txt
`– someDir
`– someFile.dat

they’ll eventually roll off my snapshot cycle and be removed in 4 weeks with my plan, but hey, pretty good at this point

See Part 2 for a post on how to set up cron jobs to automatically call this script

Other posts to come in the series:
1. Selecting the hardware
2. Installing the Operating System
3. Setting up File systems & Snapshots
4. Allowing access through NFS & SAMBA
5. Setting up encrypted off-site backups
6. Configuring Windows & Linux clients to dump backup info to the FileServer
7. My router setup, configuring IP tables & torrents on a low-powered server.

Note: This post is one in a series aimed to be a tutorial eventually, it’s not currently finalised and at the moment exists as a place for collating thought and collecting feedback

Installing OS and setup Network

For the following set of posts, I have chosen to use VirtualBox to run through how to use ZFS in building your FileSystem. The first step is downloading and installing OpenIndiana. Get the latest build from http://openindiana.org/download/ (at the time of writing, I’m using oi-dev-148-x86) and install it onto your system. In VirtualBox I chose to install onto a 64 bit Solaris setup.

Make a hard disk when you’re setting up your VM image (I called mine OS_SSD1 because the HD is eventually going to be installed onto a solid state drive.)

Now, the VM is booted, we can start having some fun (SSH into it and Away we go)

Our first step is to setup the address for the box. I must admit, I’m pretty new to Solaris but from what I’ve found, we’ll run these commands to disable Auto Configuration via DHCP then enable our static config.

svcadm disable physical:nwam
svcadm enable physical:default

My fileserver is currently not on a domain (I’ll change this later), so I’ve added the line into my /etc/hosts file

10.12.1.1 thumper.local thumper

Put your hostname that you want to use (‘thumper’ for me) in /etc/nodename

Your default gateway (routers) address should go in /etc/defaultrouter

The last thing to do is tell the host about what subnet it’s on, For me, I added (for my server subnet)

10.12.1.0 255.255.255.0

The next step is set up your nameserver for DNS (/etc/resolv.conf) mine looks like this

nameserver 10.12.1.254

Copy /etc/nsswitch.dns to /etc/nsswitch.conf – so dns is used.

Now so the adaptor comes up on boot, find out the status of your network I/O by running

dladm show-link

(for me was e1000g0). Once you have this, you need to ‘plumbe” to set up the software in the kernel to set this interface on the TCP/IP stack.

ifconfig e100g0 plumb
echo 10.12.1.1/24 > /etc/hostname.e100g0

Last but not least for your network stack,

svcadm restart milestone/network

From this point on, that concludes the base setup with networking that I’m using for the FileServer. If this happened to be a critical server for you, perhaps you’d consider setting up redundant bootable drives with ZFS. It looks pretty cool.

Setting up the storage pool

Now we can get into the fun part. The first thing I want to do with this server is be able to store my data on it, so lets set up our storage pool. In my VM I’m using to test this I’ve added the disks I want to include in my pool (1GB disks for this test)

Once we’ve booted out VM (first thing I always do is ‘sudo bash’ because I’m evil in these silly little test environments).

I want to find out the device ID’s for these hard disks I just added

root@thumper:~# iostat -En | egrep Size\|Soft
c1t0d0 Soft Errors: 0 Hard Errors: 6 Transport Errors: 0
Size: 0.00GB <0 bytes>
c1t1d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 17.18GB <17179869184 bytes>
c1t2d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 1.07GB <1073741824 bytes>
c1t3d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 1.07GB <1073741824 bytes>
c1t4d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 1.07GB <1073741824 bytes>
c1t5d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 1.07GB <1073741824 bytes>

As we can see, c1t0d0 is my CD-ROM drive, c1t1d0 is my hard disk, so I’ll want to create a Raidz-2 (two redundant drive) storage pool with the drives c1t2d0 c1t3d0 c1t4d0 c1t5d0

root@thumper:~# zpool create datastore raidz2 c1t2d0 c1t3d0 c1t4d0 c1t5d0
root@thumper:~# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
datastore 3.94G 256K 3.94G 0% 1.00x ONLINE –
rpool 15.9G 4.17G 11.7G 26% 1.00x ONLINE –
root@thumper:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
datastore 128K 1.93G 44.8K /datastore
rpool 4.52G 11.1G 45K /rpool
rpool/ROOT 3.61G 11.1G 31K legacy
rpool/ROOT/openindiana 3.61G 11.1G 3.58G /
rpool/dump 383M 11.1G 383M –
rpool/export 1002K 11.1G 32K /export
rpool/export/home 970K 11.1G 32K /export/home
rpool/export/home/scott 938K 11.1G 938K /export/home/scott
rpool/swap 544M 11.5G 187M –

We can see now we’ve created a pool of storage across our data (that’s zfs raided) that gives us double parity so we can loose two drives and still be running and we’ve got 2GB of usable space here (I’m using 1GB hard disks, in my real production box these will be 1TB disks).

Other posts to come in the series:
1. Selecting the hardware
2. Installing the Operating System
3. Setting up File systems & Snapshots
4. Allowing access through NFS & SAMBA
5. Setting up encrypted off-site backups
6. Configuring Windows & Linux clients to dump backup info to the FileServer
7. My router setup, configuring IP tables & torrents on a low-powered server.

Note: This post is one in a series aimed to be a tutorial eventually, it’s not currently finalised and at the moment exists as a place for collating thought and collecting feedback

This will be my first blog post into a guide of setting up a fileserver using Solaris (well, OpenIndiana) and ZFS to create a fileserver that has a main purpose of being a reliable server (the focus on this build is more about reliability then throughput).

My build will probably be different then most. One of the deciding factors in me choosing my hardware would have to be physical space and energy requirements. With this server, I’ve got this relatively unused space sitting behind my 27” monitor that is reserved for the box and as the primary purpose of this box is to backup and store my data in an effort to become paperless, the power requirements are going to be trying aimed at being energy efficient.

I have found a nice tower that I’d like to use that is attractive for a few reasons. It will fit the space behind my monitor nicely but also comes with a very efficient power supply.

For the CPU, at the time of writing (March 2011), the new Sandy Bridge processors are looking like they give a big bang for your buck in terms of power usage. The only problem now is that I have to find a mini-itx motherboard that is compatible with the sandy bridge architecture (has to be mini-itx because of the form factor of the case) and has enough SATA ports (or the ability to expand to meet my requirements) and is compatible with OpenIndiana. So far, the best I’ve found is the the DH67CF. Unfortunately for a fileserver that’s going to be hosting important information, this build won’t support ECC memory, which is pretty important as you can see here (probably a better article required to link there) but hopefully not regrettably, I’ll chose to risk it.

I’ve chosen to go with RAIDZ-2 to give two redundant hard disks in my data pool (with a total of 4 hard drives.) The reason being that if they are coming from the same batch then as hard disks stand, it’s likely that two will fail at more or less a similar time. It’s also worth mentioning for the critical data on my fileserver I’m going to be implementing remote off-site backups so while a dead pool will be frustrating, the likelihood of recovering some data should not be compromised.

I’ve decided that 2TB of storage should be sufficient for my requirements. For my storage array I’ve chosen to go with 4 1TB drives [[ToDo: Choose hard disks and why]] set up in Raidz-2.

Other things that I might require to put in are I/O expansion cards for more SATA drives.

Other posts to come in the series:
1. Selecting the hardware
2. Installing the Operating System
3. Setting up Snapshots
4. Allowing access through NFS & SAMBA
5. Setting up encrypted off-site backups
6. Configuring Windows & Linux clients to dump backup info to the FileServer
7. My router setup, configuring IP tables & torrents on a low-powered server.