Setting Up a Home Server with Ubuntu 11.10 – Part 1


I am in the process of re-installing my home Ubuntu server, and I figured I’d post my install steps in case it helps anyone else.  This is a multi-part post – see Part 2 and Part 3 for the rest.  I first set up this server with an older version of Ubuntu a couple of years ago. It has been a ragged server from the start, and only become more so over time. I’ve learned a lot from my mistakes, and this time I am trying to be more deliberate about the setup process. I have the following primary goals for the server:

  1. To be a file server.
  2. To be a Digital Video Recorder.
  3. To do something useful while it is idling. Even if it isn’t useful to me, it should do something to benefit the community as a whole.

Specifically, this is the functionality I want:

  1. Samba – for file sharing.
  2. (Future) Web search capability of my file shares. I have been looking into using Regain.
  3. MythTV DVR software for recording video. The video can be managed and watched via the MythWeb front-end.
  4. BOINC client, which allows me to donate idle CPU time to distributed computing projects. I used to run GIMPS, but switched to BOINC due to it’s wide availability of projects. This heats up the CPU and uses more electricity, but I figure it is worth the extra cost to benefit important research projects.
  5. Transmission BitTorrent client – For the few occasions when I need to download something via BitTorrent. It will be left running the rest of the time to act as seed for others to download from.
  6. Git server for software source control.  I use this for my programming projects.
  7. Two primary hard drives in a RAID-1 mirrored configuration, for reliability.
  8. Ability to backup my data. I am currently working on a Perl script to do daily backups, but it is not ready yet… Manual backups will have to do for now. A third hard drive is installed in the server to backup to – I wanted a separate hard drive for extra reliability. And then I occasionally copy the backups from there to offline storage.
  9. Logical Volume Manager partitions on the primary hard drives for easy partition management.
  10. Ability to email me any pertinent information.
  11. S.M.A.R.T. monitoring of all hard drives for reliability.

The server is built out of the following hardware:

  1. Single core AMD 64 bit processor.
  2. 1.5 GB RAM.
  3. Basic video card. The server is meant to be a headless server with no graphics. I can hook it up to a monitor for installation and troubleshooting, but it just sits at a plain text login prompt.
  4. Basic network card built into motherboard.  Plugged directly into wireless router.
  5. Two primary SATA hard drives plugged directly into motherboard.
  6. Third (backup) hard drive plugged into PCI extension card with additional SATA ports (motherboard only has two SATA ports).
  7. Two video capture cards.

I am using Ubuntu Server 11.10 64 bit, although I don’t have enough memory where I need 64 bits. In theory, 64 bit operating systems should be faster than 32 bit since there are more registers and a wider datapath, but I’ve also seen benchmarks that say they are slower for typical applications in Linux… Regardless, I figure it’s best for future expandability. And besides, I can’t stand to waste half of my CPU’s bits 🙂

The information I provide here can be found in various sites, blogs, and forums. But my goal was to pull the sprawled information together into a consolidated install script. Everyone will have specific needs and circumstances not covered here, but hopefully this at least helps. Disclaimer: do your own research, as I’m no server expert, especially not in the area of security. I also assume you have at least some understanding of Linux, partitioning, etc., and that you are familiar enough to know if my instructions will get you into trouble. There were a couple of general guides that are helpful to reference:

Before installing on my real server, I set up a test server inside a virtual machine on my PC (I use Oracle’s Virtualbox VM software). This has helped immensely, and I can test pretty much everything on the virtual server, even the RAID setup (I set up multiple virtual hard drives). The only thing I couldn’t test was the video recording, since I can’t emulate the video capture cards. But even then, MythTV has some features that help. For hardware-oriented applications like MythTV, I also suggest you do a test install on real hardware. I did a test on my actual server, by installing an extra hard drive. Once I did my tests, I could easily remove the hard drive or switch BIOS back to boot off my main drive.

Installing Ubuntu

If you have any old hard drives with existing data, I suggest you leave them disconnected until you finish the install. See the Ubuntu Software RAID reference for more info on setting up RAID. Keep in mind when choosing partition sizes that it is generally easier to grow a partition than it is to shrink it.

  1. By default, the installer autoconfig sets up the network using DHCP. I then go back later and manually change it to use a static IP address. You can also leave the network cable disconnected, which casues the network autconfig to fail and gives you the option to configure the network manually (I’m sure there’s another way, but I didn’t research it too much). But I prefer to leave the cable connected to allow the installer to connect to the Internet when it needs to.
  2. Before you start, you might want to check your hard drives. Various manufacturers have there own check programs, but Seagate’s Seatools works with any brand. I burn it to a bootable CD.
  3. Boot off of the Ubuntu installation CD and select your language.
  4. Check the disc for defects. Testing the memory might not be a bad idea, either. The memory test will continuously repeat until you reboot – I like to let it run overnight, or at least long enough to get a few passes, to make sure it is thoroughly tested. For some reason, the memory test locked up on my PC when I ran it off the Ubuntu CD, so I used a bootable memtest CD, which worked fine.
  5. Choose “Install Ubuntu Server”.
  6. Go through the language setup.
  7. Choose a hostname.
  8. Select your timezone.
  9. Choose “Manual” partitioning.
  10. You should see a list of existing partitions as well as options for creating new ones. Create partition tables on any drives that don’t have one – you get the option when you select the drive. Also remove any existing partitions on the primary drives. Be careful not to delete anything you want to keep. From this point forward, I assume your primary hard drives do not have any partitions. I had trouble deleting an old RAID/LVM partition on one of my primary drives since the installer said it was active (I assume it was activated by the installer). I rebooted and the partition was gone. It probably would have been better to just boot off a GParted CD, and remove the partition there.
  11. Choose “Configure software RAID” (see the Ubuntu Software RAID installation guide for more info). You will be prompted to save pending changes before you can continue. I happened to have an old swap partition in the system, and it said it would be formatted. I didn’t seem to have any choice in the matter, but I guess I don’t care since it will be going away.
  12. Select “Create MD device”. Choose “RAID1”.
  13. Select 2 for the number of active devices in the RAID array, and 0 for the number of spare devices
  14. Select your two primary hard drives as the RAID partitions. In my case, I chose /dev/sda and /dev/sdb. Note that we are selecting the whole hard drive, and not using numbered partitions.
  15. You will be prompted to save changes before you can continue. After that, select “Finish”.
  16. On the main screen, select “Configure the Logical Volume Manager”. You will need to confirm you are satisfied with existing changes before continuing.
  17. Select “Create volume group”. I named mine mainvg. This was about the most descriptive name I could think of.
  18. Select your RAID partition (mine is /dev/md0). Don’t pick the one that is marked unusable. You will once again need to confirm that you are satisfied with the setup.
  19. Select “Create logical volume”. This is your main operating system partition. Select to create it in your newly created volume group. Name the logical volume. I named mine ubuntu1110 to distinguish it from future versions of Ubuntu I might install in the volume group. I chose a size of 50G.
  20. Create another logical volume. This is the swap partition. I chose to make mine twice the size of my RAM (see the Ubuntu SwapFAQ). I named mine ubuntu1110swap.
  21. Once done, select “Finish”.
  22. On the main screen, select the main operating system partition. Choose to “Use as” Ext4. Set the mount point to /. Select “Done setting up the partition”.
  23. On the main screen, select the swap partition. Choose to “Use as” swap area. Select “Done setting up the partition”.
  24. Back on the main screen, select to “Finish partitioning and write changes to disk”.
  25. Select to boot system if RAID is degraded.
  26. Select to write partition changes to disk.
  27. Wait for the base system to install.
  28. Enter your admin user’s full name, account name, and password.
  29. I did not encrypt my home directory.
  30. Enter your proxy info. I left it blank.
  31. Wait.
  32. Choose “No automatic updates”. We’ll set those up later manually.
  33. Do not install any additional collections of software. We’ll install those as we go.
  34. Wait.
  35. Install GRUB in the master boot record.
  36. Ubuntu will spit out your CD. Select to continue and reboot.
  37. Once the server reboots, you should have a login prompt where you can log in with your admin user account.

Initial Configuration

 Default Text Editor

I use nano as my text editor. But throughout this guide, I will use the $EDITOR environment variable in my commands so that you can choose your editor.  To set the $EDITOR variable permanently:

  1. Edit this file: ~/.bashrc
  2. Add the following line at the end of the bashrc file:
    export EDITOR=nano
  3. The next time you log in, it should be set for you.

While we’re on the subject, when you are editing configuration files, you might want to back them up (copying them and tacking on a .bak extension seems like a popular way to do this).  For the most part, I leave this up to you.

Network Settings

Make the server use a static IP address – this way you can set up your router to do port forwarding, and you can reference the server using the IP address. You also need to check the DNS configuration.

  1. sudo $EDITOR /etc/network/interfaces
  2. Change the applicable network interface section to look like this (replacing the xxx‘s as appropriate):
    auto eth0
    iface eth0 inet static
  3. sudo $EDITOR /etc/resolv.conf
  4. I left the domain and search lines as they were. There should be a nameserver line for each DNS server. Adjust the nameserver lines as you feel appropriate. I use the OpenDNS DNS servers first, followed by my router’s DNS server (


Install an SSH daemon. This will allow you to connect to the server remotely using SSH.

  1. sudo apt-get install openssh-server

I also open another SSH port to listen on. This is so that I can forward the port through my router if I need to SSH in from outside my home (I don’t leave the forwarding enabled by default, though – I only enable it during the time I plan on using it). I could forward the standard port 22, but I like to use a different number to make it less susceptible to attack. Security by obscurity isn’t that great, but I figure it helps a little:

  1. sudo $EDITOR /etc/ssh/sshd_config
  2. Add this line (substituting in the port number you choose):
    Port 12345

Activate Power Button

My server sits in my living room, and I prefer to shut it down by pressing the power button on the front of the computer, like I can with my desktop PC.  I do this by installing the acpid package. I know that ACPI encompasses a lot of other power options, and I ‘m not sure exactly what else the acpid package activates besides the power button. I need to look into it, but I haven’t had any issues so far.

  1. sudo apt-get install acpid


At this point I like to restart the server using this command:

sudo shutdown -r now

To shut it down, you can use this command:

sudo shutdown -h now

Remote Login

Now that you’ve installed the SSH server, you can SSH into your server from a remote PC. Note that after a while you will see messages saying various filesystems will be checked on the next reboot. But, even after rebooting, the messages still appears, and no check appears to have happened. This appears to be a bug and is discussed in this forum.

Initial RAID Build

You will probably notice a lot of hard drive activity. This is because the server is still building the RAID array, i.e. mirroring the first drive to the second drive. The RAID array is not redundant until this is finished. You can view the progress with this command:

cat /proc/mdstat

Manual Update

Now would be a good time to install the latest updates.

  1. Update the local package index:
    sudo apt-get update

    You don’t have to do this – but if you run into problems with apt-get, this is the first thing to try to fix it.

  2. Do the update:
    sudo apt-get dist-upgrade

    dist-upgrade sounds like it will do a major upgrade, but it won’t. As I understand, it’s just a more thorough version of the upgrade option. I don’t fully understand the difference, but their are many discussions out there if you want to Google it.

SSH Notes

During the setup, there are a couple of times where you will need graphics. I have a headless server, so I can’t see graphics even if I hook a monitor up to my PC. And it would be inconvenient anyway. Fortunately, you can view graphic windows via SSH using X11 forwarding. To connect to the server, I use the ssh command line client from within a Linux PC (or virtual machine). I just add a -X (that’s an upper case X) parameter to the command line to enable X11 forwarding. And then when I run a command on the server that spawns a windows, it shows up on my local PC.

Note: I get this error the first time I SSH into my server with X11 forwarding enabled:

/usr/bin/xauth: file /home/andre/.Xauthority does not exist

But, it goes away on subsequent logins.

Besides SSHing into the server, you can also perform SFTP transfers to and from the server using the same SSH port. I use the FileZilla client to do SFTP.

Setting up Outgoing Email

Many system components will email the root account with statuses and problems. So, I set up the the server to email out early on. Here are some references I used:

You need an email account and an SMTP server you can use to send email. I chose to use the email account that comes with my Internet Service Provider (ISP), which is Earthlink. You will need to get the specific information for the SMTP server you use. Some of the security setup may differ for your ISP. Keep in mind that emails are not secure and can be read by anyone who may intercept them, since they are in plain text.  I use the Postfix mail server software, although there are others.

First, install the packages.

  1. sudo apt-get install postfix mailutils
  2. When the config screen comes up, select “Internet Site”.
  3. Enter a system mail name. I use the same name as my server name. I’m still not sure if this is the right thing to do.

Create the generic database file. This tells what From email address should be used for different user accounts. If you send from an account that is not in this file, the email will probably be rejected by your email provider. After filling in the information, you need to generate a Postfix .db file, which is required to provide quicker lookups.

  1. sudo $EDITOR /etc/postfix/generic
  2. Enter the following into the file. Substitute with the email address your server will be sending from, and adminuser with your admin user account. This sets the “From” address in your outbound email.
  3. sudo postmap hash:/etc/postfix/generic

Set up the email login database. Note this file contains a password, so we make sure to lock down the permissions first before entering in the info. Note that initially, we will be using the IP address of the SMTP server. Later, we will go back and use the host name of the SMTP server so that we are not hardcoding the IP address. I found this two step process makes troubleshooting easier, especially because of the way Postfix is configured.

  1. sudo touch /etc/postfix/sasl_passwd
  2. sudo chown root:root /etc/postfix/sasl_passwd
  3. sudo chmod 600 /etc/postfix/sasl_passwd
  4. sudo $EDITOR /etc/postfix/sasl_passwd
  5. Enter the following line. Substitute the IP address of the SMTP server you use. 587 is the standard SMTP port. Substitute in the username and password you need to log into the email account. username:password
  6. Create the .db file:
    sudo postmap hash:/etc/postfix/sasl_passwd
  7. Verify the sasl_password and sasl_password.db files are locked down:
    ls -l /etc/postfix

Edit the main Postfix configuration file.

  1. sudo $EDITOR /etc/postfix/
  2. Edit the relayhost line to include the IP address of SMTP server:
    relayhost =
  3. Comment out the “TLS parameters” that start with smtpd/smtp (my email provider does not use TLS – you may need to do something different here for your email provider) and add the following lines:
    smtp_generic_maps = hash:/etc/postfix/generic
    # SASL parameters
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

Now lets restart Postfix and do a test:

  1. sudo /etc/init.d/postfix restart
  2. Send a test message to yourself from the server. Substitute with the email address where you would like the server to send emails to.
    echo "test message" | mail -s "test"

Did you get your email? If not, you can check a couple of places

  • Check the log files /var/log/mail.log and /var/log/mail.err.
  • Check your admin user’s mail. Run this while logged in as the admin user:
  • Check root’s mail. Run:
    sudo mail

Once you’ve got it working, lets replace the SMTP IP address with a hostname.

  1. sudo $EDITOR /etc/postfix/sasl_passwd
  2. Change the IP address to a hostname: username:password
  3. sudo postmap hash:/etc/postfix/sasl_passwd
  4. sudo $EDITOR /etc/postfix/
  5. Replace the IP address here too:
    relayhost =

Restart Postfix and do another test. If you have problems with resolving the server name, check this file to make sure it is accurate: /var/spool/postfix/etc/resolv.conf. For security reasons, Postfix uses this file instead of the default config file in /etc/resolv.conf. However, the two files appear to be kept in sync automatically.

Add an alias so that email sent to root and to your admin user will be forwarded to your email instead of being stored locally.

  1. sudo $EDITOR /etc/aliases
  2. Add these lines:
  3. Process the aliases file:
    sudo newaliases

Restart Postfix and test again. This time, send the email to root and your admin user.

  1. echo "test message to root" | mail -s "test to root" root
  2. echo "test message to admin user" | mail -s "test to admin user" adminuser

I would like to figure out how to specify what computer the email is coming from – this would come in handy if you have multiple computers emailing you (I can’t distinguish between emails from my test VM server and my real server). I also noticed that when I receive the email, the “To” address contains the email account that the email is being sent from (i.e. the “From” address). Not sure why. I need to look into it….

I once had a problem where my cron tasks were getting an error when sending email out, even though email was working fine elsewhere. I don’t remember the exact details of what was wrong, but I remember I had to edit the mydestination list inside the /etc/postfix/ file. To test things out, I make a cron task that will email me every minute.

  1. sudo $EDITOR /etc/cron.d/emailtest
  2. Put in this line (the change should be picked up automatically):
    * * * * * root echo "This is a cron email test"
  3. Look in the system log, and you should eventually see the job run:
    cat /var/log/syslog
  4. Verify you got an email.
  5. Delete the task:
    sudo rm /etc/cron.d/emailtest

Running Jobs

Background Jobs

There are times when you need to run long jobs, such as copying files from one folder to another, or doing backups.  You can use the bg command or add an ampersand at the end of the command line, but I’ve had trouble getting these to work the way I want them to.  And trying to use them with sudo, or redirecting output can get tricky.  I have lately gotten into the habit of using the at command instead. This will run the job as a separate process, so you don’t need to stay logged in, and it will email you the results.

To run a job now (the -m option tells at to send an email to you even if the job does not have any output):

at now -m

To run a job at midnight:

at 0:00 -m

To run a job at midnight with elevated rights:

sudo at 0:00 -m

After entering the above command lines you will get a “>” prompt to enter the actual commands. You can enter multiple commands to run in a row. When you are finished, hit Ctrl+D to finish. at will email you any output from the commands. The at man page has more details and also other commands to manage queued jobs.

Cron Jobs

You can make regularly-scheduled jobs using the cron daemon.  You can do this in one of the following ways:

  1. Add an entry to the /etc/crontab file.
  2. Add a file in the /etc/cron.d folder.
  3. Add an entry to one of the following folders inside the /etc folder: cron.hourly, cron.daily, cron.weekly, or cron.monthly.

I won’t go into details, but there is plenty of information available.

Redirecting Output

When running commands, you might want to redirect to a file by adding this after the command:

2>&1 > ~/logfile.log

Or, you can email root the output by adding this after the command:

2>&1 | mail -s "My Subject" root

I include 2>&1, which redirects the standard error output to standard output, so that it is included in the file. Otherwise, the error output shows up in your command window. You may want this in some cases, in which case you can omit the 2>&1. For example, you may want to run a command with the at command, redirecting normal output to a file, but letting at email you the errors.

RAID Failover Test

Now that we have email working, this is a good time to test the RAID failover. This will make sure you get a notification, and also give you practice rebuilding the array. You need to wait until the RAID array has finished it’s initial build after the install. Unfortunately, doing this test will require the array to be built a second time.

  1. Pick a primary drive to disconnect. Figure out the device of the RAID partition that is on that drive (e.g. /dev/sda1). To list hard drives/partitions, use this command:
    sudo fdisk -l

    While you’re at it, now would be a good time to make a list of your hard drive devices for future reference.

  2. Disconnect the drive. This will be your “failed” hard drive. I do this while the server is off.
  3. Start up the server. It should boot off of your remaining hard drive.
  4. You should get an email, as well as a warning at the login prompt.
  5. Login.
  6. View the RAID status with the following command.
    cat /proc/mdstat

    There should only be one drive in the array.

  7. Now re-attach the “failed” hard drive (again, I do this while the power is off). The hard drive is already partitioned properly. But, if you were attaching a new hard drive, you would need to to set up a RAID partition on it (the RAID partition needs to be of type “Linux raid autodetect”).
  8. Add the RAID partition on the “failed” hard drive back into the array (assuming the RAID array is md0 and the re-attached RAID partition is sda1):
    sudo mdadm --add /dev/md0 /dev/sda1
  9. Now, the re-attached RAID partition will be re-built to mirror the RAID partition on your existing hard drive, just like it did after the initial install. To monitor progress, look at mdstat again:
    cat /proc/mdstat

You can also verify you have GRUB installed on both hard drives. Try booting off each primary hard drives by selecting each one as the boot drive in your BIOS. You should be able to boot off of either one.

Hard Drive SMART Monitoring

Let’s start monitoring the hard drives – this will hopefully give us an early warning before a hard drive fails. I use smartmontools. I used the following guides:

Here we go:

  1. Install the package:
    sudo apt-get install smartmontools
  2. Make sure SMART is enabled for each of your hard drives. Run this for each drive:
    sudo smartctl -s on /dev/sda
  3. Run this command to view SMART information for a given drive:
    sudo smartctl -a /dev/sda
  4. Edit the configuration file:
    sudo $EDITOR /etc/smartd.conf

    We don’t want to use the default “auto” configuration, so comment out the following line (see the comments above it for more info):

    DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

    Add a line for each hard drive. The following line is typical of what I use. I will not explain everything here, but you can use the guides. Unfortunately figuring everything out can get tricky. The temperature limit can take time to adjust properly.

    /dev/sda -a -o on -S on -W 2,0,34 -R 5 -m root -s (S/../../7/02|L/../01/./02)
  5. Restart SMART to pick up changes (I guess you can also send it a signal, but I just restart it):
    sudo /etc/init.d/smartd restart
  6. To do a test of the email notification, edit the smartd.conf file and add -M test onto each hard drive line. For example:
    /dev/sda -a -o on -S on -W 2,0,34 -R 5 -m root -s (S/../../7/02|L/../01/./02) -M test

    When you restart smartd you will get an email. You can then remove the -M test directive and restart again. Another way you can test is to set the temperature limit to a low value so that the hard drive temperature exceeds the limit.

Creating LVM Partitions

Here are the directions to create a new LVM partition:

  1. Create the logical partition. Adjust the -L parameter to the size you want – in this example it is set to 1 GB.  Remember, it is generally easier to grow a partition than to shrink it.  mypartition is the partition name, and mainvg is the volume group it should be created in:
    sudo lvcreate -L 1G -n mypartition mainvg
  2. Create a file system on the new partition (in this case I use ext4):
    sudo mkfs.ext4 /dev/mainvg/mypartition

To mount the partition:

  1. Make the mount point (in this example, I make it under the /srv folder):
    sudo mkdir /srv/mymountpoint
  2. sudo $EDITOR /etc/fstab
  3. Add a line (<tab>‘s should be replaced with actual tabs):
  4. sudo mount /srv/mymountpoint

Samba File Sharing

Now that you have the basic configuration done, lets set up file sharing.

I like to create a separate partition for my file share data. This partition will contain multiple folders, one for each share that I want to create.  Create the partition and mount it.  I name my partition usershare and mount it in a folder named /srv/usershare.

Set the permissions on the new share folder:

  1. I like to give owner and group full permissions, but not let anyone else into the shares:
  2. sudo chmod 770 /srv/usershare
  3. I create a group just for my shares:
    sudo groupadd usershare
    sudo chgrp usershare /srv/usershare
  4. Make sure to add any users to the group who need access. I add my admin user:
    sudo adduser adminuser usershare
  5. log out and back in to let group permissions take effect.

Now let’s set up a share folder:

  1. sudo mkdir /srv/usershare/myshare
  2. Copy in any files you have to the user share. I mount the old partition from which I want to copy under /mnt. Assuming the old partition is mounted under /mnt/source, I use the following command to copy the data over (there are many other ways to do this, though). See the rsync man pagefor details on the options.
    sudo rsync -av --progress /mnt/source/ /srv/usershare > ~/usershare_sync.log

    You can monitor progress by looking at the log file:

    cat ~/usershare_sync.log
  3. I now set the permissions on all files underneath the share:
    sudo chmod -R 770 /srv/usershare/myshare
    sudo chgrp -R usershare /srv/usershare/myshare

Now let’s set up Samba:

  1. sudo apt-get install samba
  2. sudo $EDITOR /etc/samba/smb.conf
  3. Uncomment this line:
    security = user
  4. Add a section for each share, using this as a template:
        comment = My share
        path = /srv/usershare/myshare
        browsable = yes
        guest ok = no
        read only = no
        create mask = 0770
        directory mask = 0770
        force group = usershare
  5. I also uncomment all the lines in the homes section. There is a section to make a cdrom share. I have not used this yet, but it seems intriguing. I don’t have a printer hooked to the server, so I don’t do anything with the printer section. I would like to hook my inkjet printer to the server, but I have not had great experiencing hooking these printers up to Linux machines. They tend have limited functionality when not using the proprietary drivers that come with Windows.
  6. Let’s set up Samba to sync its accounts with the system accounts on the server:
    sudo apt-get install libpam-smbpass
  7. sudo restart smbd
  8. At this point I still can’t access the Samba share. So, per this thread, I log out and back onto the server again (using SSH). Once I do that, it appears my account is synced up and I can access the new share via Samba at this path: \\serverip\myshare . Not sure how the syncing works when you have multiple users….


Backup Hard Drive Setup

I have a third hard drive permanently mounted in my server for backups. It’s still physically located with my primary hard drives, and is always online, so it’s not the most secure backup. But, it at least provides a separate drive in case my RAID array gets corrupt, and I also store multiple backups of the same location. So, if I find out I accidentally deleted a file before my last backup, I can still go back further in time to get it from an earlier backup. To mount the backup hard drive:

  1. Run fdisk passing in the backup hard drive device (I’ll assume the device is /dev/sda and we are creating a partition /dev/sda1
    sudo fdisk /dev/sda
  2. At this point I assume you are ready to create a new partition.
  3. At the prompt, enter n to create a new partition.
  4. Go through the partition setup. I will be using an ext4 partition, so I leave the default partition type (id=83/system=Linux).
  5. Create the file system on the new partition:
    sudo mkfs.ext4 /dev/sda1
  6. Find the UUID of the new partition:
    sudo blkid /dev/sda1
  7. Make the mount point:
    sudo mkdir /srv/backup
  8. sudo $EDITOR /etc/fstab
  9. Add a line, using the UUID you just found (<tab>‘s should be replaced with actual tabs):
  10. sudo mount /srv/backup
  11. Set permissions on the new folder as you like.

Manual Backup

I am working on a PERL script to do routine backups of my server. For now, I just manually run tar. I run the following command to do a backup:

sudo tar -czf "/srv/backup/backupname_`date +%Y-%m-%d_%H%M%S`.tar.gz" -C / srv/usershare/backupfolder

I generally use the at command as described earlier, stringing together multiple backup commands for each folder I want to back up.

Take a break

At this point, I take a break. Now that I’ve got the file shares set up, the rest can be set up later. I will be posting additional parts describing the rest of my setup.

Guard Rails for Computer Desk

I sometimes accidentally push objects off the edge of my desk when trying to rearrange it (the speakers are a common victim).  I was concerned that one day I would push one of the four legs of my monitor stand over the edge, leading to a smashed monitor.  A while back, I added some strips of wood around the side and back edges of the desk to act as guard rails.  The strips are big enough to stop a sliding object, but still small enough that they do not get in my way.  Here is a summary of what I did:

1) Obtained strips of wood and small nails.  I believe the strips of wood were furring strips.  They had a 1/4 inch by 1/4 inch cross-section.  Here is a picture:

2) Cut the strips to fit the size of the desk and sanded down the ends to make them smooth.

3) Drilled pilot holes in the strips, large enough to accommodate the nails without splitting the wood.  I placed a nail about every 3 inches:

3) Prepared the nails by hammering them into all of the pilot holes.  I only hammered them partially in, so that the nails were not sticking out the bottom.

4) Laid the strips down on the desk.  Once I was happy with the placement, I finished hammering the nails through the strips and into the desk.

5) The strips I bought were a little too short to span the entire back of the desk, so I cut some small pieces that would fill the empty space.  Rather than nail them down, I started by making them slightly larger than the empty space, and then sanded them down until I could wedge them in between the nailed-down strips.  This ensured a tight fit so that they would not fall out.  You can see one piece in the last photo below.

Here is the finished product: