By far the most popular set of articles I have written is my Raspberry Pi Email Server tutorial. Clearly, there are plenty of people who don't like relying on freemail providers like Yahoo, Outlook and Gmail for a variety of privacy and security reasons. However, there is one major drawback of hosting your own email server: if your server is taken offline for maintenance, or your internet connection is interrupted, then incoming email can not be delivered and may bounce. This tutorial will describe how to set up another server to act as an MX backup. The backup server will be hosted on a separate internet connection with a different WAN IP address, and have a lower priority than your primary mail server in your Mail Exchanger (MX) DNS record. When your primary server is offline other MTAs will send email to the backup instead, and the backup will hold them until your primary mail server comes back online, and then deliver them. No more bounced emails. The biggest challenge when setting up a backup MX is convincing a friend or family member to allow you to run a RasPi or some other server on their network; the rest of the setup is a breeze compared to the full mail server installation described in the main tutorial, because fewer components are required (just Postfix). This guide is written for Debian and its derivatives (Raspbian, Ubuntu etc.) but since a basic postfix installation is more or less the same across different distributions you should be able to use it for any distro. My backup server runs openSUSE.

This article aims to explain what various DNS records are and how to use them. It is aimed at people hosting websites and email servers on a home server such as a raspberry pi.

How DNS Works

DNS stands for Domain Name System. In a nutshell, it's the system that we use to translate human readable domain names (e.g. samhobbs.co.uk) into the Internet Protocol (IP) addresses for those services (e.g. 195.166.151.235). The DNS system has a strict hierarchy, and lookups are performed recursively using a client/server model. This means that when your computer asks for the IP address for "subdomain.example.com", the DNS resolver you are using starts at the top and works backwards to find the address. The servers at the top of the pyramid (root name servers) direct clients to the name servers reponsibe for Top Level Domains (TLD, e.g. .com), and that server in turn is able to tell the client which name server is authoritative for the second level domain (e.g. example.com), and so on. Usually for small sites, the DNS records for your domain are managed by your Domain Name Registrar. The DNS resolver doesn't have to perform all these lookups every time, because each record has a Time To Live (TTL) in seconds, which tells the client how long they can cache the information for until it should be refreshed. That's Time To Live (live free), not Live (live electrical circuit), which is how I first read it! There are loads of different types of DNS record, so I've picked the most important ones you might need or want to use. These are:

1. DNS A - used to map a host name to an IP address
2. Mail Exchanger (MX) - used to tell clients which hostnames are used for email services
3. Sender Policy Framework (SPF) - used to define which servers are allowed to send email from your domain name
4. Pointer (PTR) - the opposite of DNS A, this record maps an IP address to the hostname

For a website, you only need a DNS A record. For an email server, you need at least a DNS A record and an MX record; PTR and SPF records will help you get your email through spam filters. I'll be illustrating how to set up the different types of record using Namecheap, my Domain Name Registrar, as an example. If you haven't registered a domain name yet, I'd recommend Namecheap -avoid GoDaddy if you can, since they have some pretty horrible pricing practices and consistently back the wrong side when it comes to internet censorship acts like SOPA and PIPA.

This is something I have been meaning to write up for a while: how to automate backups using cron and Drush, a commandline tool for Drupal. Drush makes creating backups of your Drupal website's database and files really easy, and I have written a script that calls Drush to create a backup, and then manages your existing backups so you don't use up too much space on your drive. Once a month, it will also create an encrypted copy of that day's backup file and email it to an external email address. Personally, I think that daily backups from a month ago aren't useful to me any more - if I was going to revert to a backup from that long ago, I'd be looking to restore a weekly backup. Similarly, after several months, I'd only be interested in monthly backups. After creating your daily backup, the script runs through the other files in the backup directory and deletes the files you don't need any more. The script will keep:

• One week of daily backups
• One month of weekly backups (1st, 8th, 15th and 22nd)
• Monthly backups for one year
• Yearly backups for ever

Before I wrote the script, samhobbs.co.uk was a WordPress site hosted on a Raspberry Pi until the drive I was using bricked. I didn't have a recent backup so I lost the lot. Now I make backups to an external hard drive, so that if the SSD in the my Intel NUC gets corrupted I'll be able to recover. The encrypted copies sent to an external email address protect against the server being stolen or lost in a fire.