Timecapsule on Banana Pi

This blog page is an addendum to the very good blog of Alex (in german) which can be found here:


Before the setup was working I had to do some troubleshooting. The collected ideas and experience is covered by this blog page:

  • Update for netatalk version 3.1.7: How to compile with Zero Configuration and how to add additional authentication methods
  • Subsequently the setup for individual users. The initial blog assumes that you come as guest.
  • Service Configuration with Avahi: my Mac had some trouble recognizing the Time Capsule
  • Some tipps on debugging
  • Useful script for Maintenance
  • Misc Stuff
I realize that the full setup of a Timecapsule Backup server has become quite an extensive effort. I still hope that the write up below is useful and can be an extension to the above referred to blog.


Netatalk

At the time of writing, the current 3.1.7 version of netatalk can be downloaded here:


When compiling netatalk I noticed that the command line says Zero Conf, but the summary after config says no zero conf.You should use the following command line option to enable zero configuration:

--enable-zeroconf

In case you decided to run a newer version of Bananian, you may need install a newer version of libdb5.1dev:

Jeezy:
Libdb5.1dev becomes libdb5.3-dev

In addition, it is required to install the avahi lib. Otherwise, the option won't have any effect:

Apt-get install libavahi-client-dev

In order to get additional user authentication methods you may install the following libraries:

apt-get install libcrack2-dev libssl-dev libgcrypt-dev

After running ./configure on netatalk, you review the config summary. Of specific interest are the UAMS. You may want to have DHX2 (I think DHX(1) is no longer supported by Apple). Also it is important that it is positive about Zeroconf support:

Configure summary:
    INIT STYLE:
         debian-sysv
    AFP:
         Extended Attributes: ad | sys
         ACL support: yes
         Spotlight: no
    CNID:
         backends:  dbd last tdb
    UAMS:
         DHX     ( SHADOW)
         DHX2    ( SHADOW)
         RANDNUM (afppasswd)
         clrtxt  ( SHADOW)
         guest
    Options:
         Zeroconf support:        yes
         tcp wrapper support:     no
         quota support:           yes
         admin group support:     yes
         valid shell check:       yes
         cracklib support:        no
         ACL support:             auto
         Kerberos support:        auto
         LDAP support:            no
         AFP stats via dbus:      no
         dtrace probes:           no
    Paths:
         Netatalk lockfile:       /var/lock/netatalk
         init directory:          /etc/init.d
    Documentation:
         Docbook:                 no


List of UAMS: /usr/local/lib/netatalk:
uams_clrtxt.so
uams_dhx2_passwd.so
uams_dhx2
uams_dhx_passwd.so
uams_dhx.so
uams_guest.so
uams_passwd.so
uams_randnum.so


syslog -k Sender com.apple.backupd | tee ~/Desktop/TMreport.log | more

Before you start using the setup, you need to create the users in the UNIX (adduser) and assign them to the right group (100 = users).

To give users a network drive, it is necessary to fill the Homes Section in afp.conf


Debugging


A couple of Notes on debugging:

Logfiles:

  • On the Banana Pi check /var/log/netatalk.log
  • On the Mac, use "syslog -k Sender com.apple.backupd" to obtain the log of the TimeMachine.

Bonjour

The bonjour browser is helpful to see, if the avahi stuff works properly:

BonjourBrowser.dmg (can be found using google)

Network Performance

It is advised to make sure that there is a Gigabit Link between the Mac and the Banana Pi. In my experience the Mac does not necessarily choose the fastest network connection, but one that works. As a consequence, the Gigabit Wireline Network connection may not be used. Instead the traffic runs over a slower WLAN connection. If you suspect a performance issue, you may want explicitly disable WLAN.

You should expect a performance of 20+ Gbyte per hour. Compared to a "real" NAS this about a third of the possible performance.

This can be easily verified with the syslog command described above. In case you suspect network performance issues, you may want to try one of the following approaches:

Command Line

I found a useful description for netcat and pipe viewer here:


# Server side
$ nc -v -v -l -n -p 2222 >/dev/null

# Client side 
$ pv -t -r -a -b /dev/zero | nc -v -v -n 192.168.1.1 2222 >/dev/null

On the Mac the pipe viewer is not installed by default. You may get it using homebrew:

Homebrew install pv

Iperf

Another option is to install iperf on both machines. The installation with apt-get on the Banana Pi will currently install version 2.

Apt-get install iperf

Using homebrew on the Mac provides version 3. Unfortunately, version 2 and 3 are not compatible. For this reason, it is recommend to download the executable for version 2 directly:


Useful Script for Maintenance


During the recent months, I experienced several unrecoverable failures of the HFS+ volume. In order to avoid this, I introduced regular fsck commands to hopefully fix problems before they become serious. Point is that TimeMachine backups consists of many files.

Idea for a maintenance script is as follows:  At least every two days, run a fsck command while no backup is running.

In order to achieve this, I'm using two corntab entries and a script:

#!/bin/sh
DEVICE=/dev/sda
LOG=/tmp/fsck.log
LOCK=/tmp/fsck.DONE
MOUNTPOINT=/mnt/TimeCapsule

log() {
dt="$(date)"
echo $dt " " $1 >> $LOG
}

if [ -f $LOCK ]
   then
exit
fi

umount $DEVICE
result=$?
if [ $result -ne 0 ]
   then
if [ $result -eq 32 ]
  then
log "Device is not mounted, mounting now"
mount $DEVICE $MOUNTPOINT
log "Restarting netatalk"
/etc/init.d/netatalk stop
/etc/init.d/netatalk start
log "Done"
  else
log "Could not unmount"
        fi
   else
log "Unmount successfull"
/etc/init.d/netatalk stop
touch $LOCK
log "Starting fsck"
/sbin/fsck.hfsplus $DEVICE >> $LOG 2>&1
log "Done with fsck, mounting device & starting netatalk"
mount $DEVICE $MOUNTPOINT
/etc/init.d/netatalk start
log "Done"
fi

The four variables at the top of the script need to be adjusted to your needs. The script does the following steps:

  1. If the $LOCK file exists do nothing. As crontab will call this script hourly, the file prevents that fsck is executed more often than needed
  2. Try to unmount the device. If the device can be unmounted, this means, no backup is in progress. Otherwise the device would be busy. Obviously no other process should have access to the backup volume (i.e. a terminal), otherwise umount will never work.
  3. Once umount worked, the $LOCK file is created and netatalk is stopped. If netatalk remains running, Mac OS will detect a change in the backup volume plus will start to backup into the local file system. Both are things that are to be avoided
  4. Do the file system check. Due to the larger number of files, this may need 90 minutes or more
  5. Restore mount and restart netatalk

Now the two crontabs entries come into the game:

0  * * * * /root/scripts/dofsck.sh
30 9 */2 * * rm /tmp/fsck.DONE

Apparently the script (above) has been saved as /root/scripts/dofsck.sh.

The first job calls the script every hour. You may need to adjust the path. As described under A) calling the script every hour will do no harm as the actual script execution will not start if the $LOCK file exists.
The second job will every two days at 09:30 remove the $LOCK file. This should make sure that every two days the scripts starts over trying to unmount the disk and subsequently do the fsck.

Misc Stuff


Hard Disk Case

Like shown in the blog by Alex, I got hold of a HDD Protection Box by Delock. When I started the Banana Po for the first time, I could not see the hard disk in the "dmesg" log. Initially, I tried some things in the configuration of the PI - with no success. The solution to the problem was not in software, but in hardware. It turned out, that the slot for connecting the SATA cable of the HDD Box prevented a proper connection between cable and HDD. Somehow, for my cable the hole in the case was too small. I removed the side of the case. Since then the HDD works!

Smartmontools

Alex already points out that the update link for Smartmontools won't work any longer. It seems to have changed again since time of writing the blog. A possible way to get the update is to visiti this page:


Download the file corresponding to the version: 5.41. You can easily copy the link and get the file right in place with wget.

With the 15.08 (jeezy) the update works again.

update-smart-drivedb


Reliability & Maintenance

Having used the Banana Pi as backup device for a couple of weeks now, my observation is as follows:

  1. Total crash of the pi after about 4 weeks. The files system on the SD was corrupted. I realizied that it is a good idea to backup the config files of your backup system.
  2. File System corruption of the atteched SATA HDD after another 2 weeks. Suspicion is that the mounted HFS volume does not like to be disconnected by force - e.g. detaching the Mac Book from LAN cable and Power at once... Interesting enough a 2nd backup device (NAS) does not have such problems.
  3. Banana PI dislikes sudden power down. The SATA HDD is mount read only on the next start, which prevents any backups.

For repairing the SATA HDD, try this. The command may run quite long as the backup creates a large amount of files on the disk:

fsck.hfsplus -r /dev/sda 



Subscribe to: Posts (Atom)