So, how many of us remember to have redundancy in files and other data that we trust a computer to store for us? Have you ever lost data to a faulty drive? Well I certainly have and it sucks trying to retrieve it after the drive fails. For the most past I have been able to recover the data but I don’t want my luck to run out. Hence, I wanted and needed a backup solution. I have thought long and hard about getting some kind of a RAID solution but in the meantime decided it was worth the money to use a Raspberry Pi and a couple USB drives. This post will explain as simple as possible the steps to getting it setup.

Note: This article assumes you have a Raspberry Pi, 2 identical USB drives and the Raspberry Pi already has an OS installed.

One link I recommend reviewing is Here. This link for “How to Geek” was really helpful and provided a great guide. I will summarize the steps within and add where I ran into problems.

Steps
1. Mounting the drives

This is typically done using the a combination of a couple commands.

sudo apt-get install ntfs-3g

to install the proper file system format.

sudo fdisk -l

will then list out the connected drives allowing you to find the connected USB drives. When the list returns you are looking specifically at the sda and sdb entries. These are the ones that represent the USB drives. Now this is also where I ran into my first issue. The issue was actually with the next step is to mount the drives. As it turned out the drives mounted themselves. How dare they, right?

Well because the already mounted themselves I ended up editing the fstab file manually and create the directories I wanted the drives to mount to specific directories so that I could control the mounting directory for future steps. Therefore I used the following steps for the mounting:

sudo mkdir /media/USBHDD1
sudo mkdir /media/USBHDD2

creating the directories I wanted and then

sudo nano /etc/fstab

to open the fstab file to make the change to have the drives mount to the directories I wanted by adding the following to the end of the file:

/dev/sda1 /media/USBHDD1 auto noatime 0 0
/dev/sda2 /media/USBHDD2 auto noatime 0 0

save the file and the mounting is complete… reboot and the drives should not mount to the designated directories.

2. Create share directories and install Samba to enable Windows shares

sudo mkdir /media/USBHDD1/shares
sudo mkdir /media/USBHDD2/shares

will create directories on both of the drives. Since we want the drives to be identical it is important to keep them in sync with the same directories. Once you have the share directories let’s install Samba:

sudo apt-get install samba samba-common-bin

The install will prompt for continuing at which point ‘Y’ is a good response if you want the install to complete successfully. Once it does complete you can now take a backup of the config file (for safe keeping) and modify the file using the following commands:

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.old
sudo nano /etc/samba/smb.conf

Once inside of the file modify the workgroup if one is being used. After that we can modify the authentication to prevent just anyone from getting to the files. This is generally a good idea as you don’t want just anyone connected to your wireless to have access. To do this scroll down in the file and remove the ‘#’ from the ‘security = user’ line. This will enable the security to use a usernamepassword authentication mechanism. I realize we haven’t created a user yet, no worries, we also haven’t stored anything in the share we didn’t create yet either…

Speaking of the share we didn’t create, before closing the config file let’s add the information about our share. Add this to the end of the file:

[Backup]
comment = Backup Folder
path = /media/USBHDD1/shares
valid users = @users
force group = users
create mask = 0660
directory mask = 0771
read only = no

Hey we have a share… Can you guess the name? The name is actually what you put inside of the [], or in our example above Backup.

Note, you only need one share as the second drive is truly a disaster recovery drive in this case. Once you finish that you can save the config file and restart.

sudo /etc/init.d/samba restart

This will restart Samba so we have a share all ready to go. How about we create a user to access that share.

sudo useradd backups -m -G users
sudo passwd backups

The second command will ask that you type a password in and then confirm that password. Make sure you remember this to ensure you can use this user to access the share later. Note, this still didn’t add the user as a valid Samba user.

sudo smbpasswd -a backups

at this point you are ready to test the share from another computer and add some files. You must run the above in order to access the file, though…

3. install rsync

sudo apt-get install rsync

Will install a component known as rsync. Once installed you can test if you have files in the shared directory by running the following command.

sudo rsync -av --delete /media/USBHDD1/shares /media/USBHDD2/shares/

All this component does is the backup from drive 1 to drive 2. Notice that we had to run this manually. If we stop here we can have the backups occur but we would have to come back to the machine and manually run the rsync command each time we want to update the backup.

4. setup Cron

Cron, this sounds like the villain in some superhero comic… Well, although that would be a great name, it is actually the mechanism for running scheduled events. To open the file for entering the jobs use this command:

crontab -e

and then you can enter the following as an example scheduled job:

0 5 * * * rsync -av --delete /media/USBHDD1/shares /media/USBHDD2/shares/

Now this looks a lot like the test line we used in the previous step with a couple additions. Mainly 0 5 * * *. let’s examime:

0 – (day) 0 indicates to run every day
5 – (hour) 5 would be 5 am
* – (year) every year
* – (month) every month
* – (day) every day

with this setup you can add a couple new files to the share and wait overnight to see if the files are added to the backup location.

One issues I hit here is that I added GBs of data, roughly 90GB, to the drive and woke up the next morning and the Pi seemed unresponsive. I reviewed a few things and realized the Pi was actually still running rsync from that night. I used the task manager to see rsync running and monitored the size of the directories using the properties to show that the file size continued to grow. After hours of running and seemingly unresponsive it completed successfully. Key here is that the Pi isn’t high powered, it may take a while to copy things but if this is the purpose of the Pi, does it matter how long it runs?…