Der Raspberry Pi ist eine kleine Allzweckwaffe: Ein kompletter Rechner für ca. 35€, so groß wie eine Scheckkarte und mit einer sehr geringen Leistungsaufnahme (deren Kehrseite natürlich auch eine ziemlich geringe Leistung ist). Aber für manche Anwendungsfälle ist der Raspberry Pi genau das richtige Gerät. Ich kenne einige Leute, die sich vor lauter Begeisterung einen Raspberry Pi gekauft haben und nun nicht so richtig wissen, was sie mit dem schicken Teil nun eigentlich anfangen sollen. Mein Tipp: Als Backupmaschine verwenden.

Was der Raspberry Pi bei mir alles so backupt will ich in diesem Beitrag grob skizzieren. Voraussetzung ist ein fertig installiertes Raspian oder ein vergleichbares System, Grundkenntnisse im Umgang mit Linux (z.B. der crontab), dem Raspberry Pi an sich und zumindest eine gewisse Lernbereitschaft und Offenheit gegenüber z.B. Shell- und PHP-Skripten. Ich werde keine kompletten Anleitungen schreiben, eher so eine Gedankensammlung. Es muss und soll also weiter gebastelt und gegooglet werden!

0) Setup des Raspberry Pi

Zunächst kurz zu meinem Setup: Da der Raspberry Pi (ich besitze noch kein „Model B+„) nicht all zu viele USB-Anschlüsse hat habe ich ihm diesen aktiven USB-Hub spendiert. Der Vorteil ist, dass man den Raspberry Pi direkt von dem aktiven Hub aus mit Strom versorgen kann und somit kein extra Netzteil für den Pi braucht. Da ich lediglich remote auf den Pi zugreife brauche ich weder Monitor noch Eingabegeräte wie Tastatur und Maus. Ansonsten ist er nur noch per LAN-Kabel an meiner Fritzbox 7390 angeschlossen. An dieser wiederum hängt eine 2,5″-Festplatte zur Speicherung der Backups, die ich im Raspberry Pi mit einem Eintrag in der /etc/fstab so gemountet habe:

# USB-Platte an der Fritz!Box einbinden (seit Fritz!OS 6):
//fritz.box/FRITZ.NAS/ /mnt/fritz cifs user,uid=pi,gid=pi,exec,username=hehehehe,password=hahahahaha 0 0

Das Verzeichnis /mnt/fritz habe ich natürlich vorher angelegt und die dann darin auftauchende Platte „Samsung-G2Portable-01“ mit</pre>
<pre>

ln -s /mnt/fritz/Samsung-G2Portable-01/ ~/backup

in mein Home-Verzeichnis verlinkt.

1) Backup der Google Kalender

Ich finde es wichtig, von diversen Cloud-Diensten Backups der dort gelagerten Daten zu haben. Zu Zeiten, als man seine Kalender und Kontakte noch z.B. in Outlook lokal verwaltet hat, reichte ein normales Backup des eigenen Rechners. Es gibt mehr als genug Geschichten davon, wie z.B. ein Google Account und mit ihm die dort gespeicherten Daten einfach verschwinden kann. So etwas wäre mehr als ärgerlich, denn die dort gelagerten Daten sind zumindest mir ziemlich wichtig und wurden über Jahre (ein-) gepflegt.

Ein Backup der eigenen Google-Kalender ist relativ einfach. Man braucht dazu lediglich die private ICAL-Adresse des entsprechenden Kalenders. An die kommt unter https://www.google.com/calendar/:

Die URL hinter dem ICAL-Symbol hat diese Form:

https://www.google.com/calendar/ical/deinegooglemail%40gmail.com/private-vielezahlenundbuchstaben/basic.ics

Mit dieser URL macht man jetzt einen Eintrag in seine Crontab auf dem Raspberry Pi und ist fertig:

0 1 * * * wget --quiet -O - https://www.google.com/calendar/ical/deinegooglemail%40gmail.com/private-vielezahlenundbuchstaben/basic.ics | gzip > ~/backup/Google\ Kalender/backup-google-calendar-privat-`date +\%Y-\%m-\%d`.ics.gz

2) Backup der Google Kontakte

UPDATE: Der hier vorgestellte Weg klappt nicht mehr. Wie doch alles gut werden kann: https://dasaweb.de/2015/06/26/oauth-2-0-lord-have-mercy/

Ein Backup der Google Kontakte ist schon nicht mehr ganz so einfach möglich. An dieser Stelle verwende ich ein kleines PHP-Skript, welches mir die Kontaktdaten als XML-Datei speichert. Nicht mitgespeichert werden allerdings die Kontaktfotos, was im Falle eines Datenverlustes schon herb wäre. Aber besser so als gar nicht:

<?PHP

// Pfad zur ZendFramework-Library setzen:
set_include_path('/home/pi/skripte/ZendFramework-1.12.3-minimal/library');

// Zend Gdata-Libraries laden:
require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata');
Zend_Loader::loadClass('Zend_Gdata_ClientLogin');
Zend_Loader::loadClass('Zend_Http_Client');
Zend_Loader::loadClass('Zend_Gdata_Query');
Zend_Loader::loadClass('Zend_Gdata_Feed');

// Zugangsdaten für Google-Account.
// Bei "Bestätigung in zwei Schritten" muss ein extra "anwendungsspezifisches Passwort" angelegt werden:
$user = "deineadresse@gmail.com";
$pass = "Dein_Google-Passwort,_im_Idealfall_ein_separat_vergebenes_nur_für_diesen_Zweck";

// Einloggen und richtige Protokollversion setzen:
$client = Zend_Gdata_ClientLogin::getHttpClient($user, $pass, 'cp');
$gdata = new Zend_Gdata($client);
$gdata->setMajorProtocolVersion(3);

// Abfrage starten, die einfach mal alle (max. 2000) Kontakte holt:
$query = new Zend_Gdata_Query('http://www.google.com/m8/feeds/contacts/default/full');
$query->maxResults = 5000;
$feed = $gdata->getFeed($query);

#var_export($feed); # Geht nicht, dazu reicht der Speicher nicht...

// Alle Einträge durchgehen:
foreach($feed as $entry) {
// Der Einfachheit halber die Daten auch in XML konvertieren:
$xml = simplexml_load_string($entry->getXML());
var_export($xml); # In der Hoffnung, das im Notfall auch wieder irgendwie einlesen zu können...
echo "\n";
}

Dieses Skript speichert man z.B. unter backup-google-contacts.php, evtl. müssen die Rechte des Skripts noch mit chmod angepasst werden. Das Skript verwendet Code aus dem Zend Framework 1, welches man sich hier herunterladen kann. Einfach in irgend ein Verzeichnis packen und das im PHP-Skript entsprechend referenzieren. Ach ja, und PHP muss natürlich installiert werden, falls nicht schon geschehen:

sudo apt-get install php5

Fehlt nur noch der entsprechende Eintrag in die Crontab:

0 1 * * * php ~/skripte/backup-google-contacts.php | gzip > ~/backup/Google\ Kontakte/backup-google-contacts-`date +\%Y-\%m-\%d`.txt.gz

3) Backup von IMAP-Konten

OfflineImap ist ein Tool, welches IMAP-Accounts synchronisieren kann. Für meinen Anwendungszweck kann es aber auch einen IMAP-Account mit einem lokalen Archiv synchronisieren, oder besser gesagt: ihn backupen.

OfflineImap sollte man auf dem Raspberry Pi ganz normal mit

sudo apt-get install offlineimap

installieren können. Anschließend richtet man sich im Home-Verzeichnis ein Konfigurationsfile names ~/.offlineimaprc ein. In meinem Fall sieht dieses vereinfacht so aus:

[general]
accounts = VariomediaBla, VariomediaBlubb
metadata = ~/backup/IMAP/offlineimap_metadata
maxsyncaccounts = 2
readonly = True

[Account VariomediaBla]
localrepository = LocalVariomediaBla
remoterepository = RemoteVariomediaBla
expunge = no
readonly = True

[Repository LocalVariomediaBla]
type = Maildir
localfolders = ~/backup/IMAP/VariomediaBla

[Repository RemoteVariomediaBla]
type = IMAP
createfolders = False
ssl = yes
remotehost = imap.variomedia.de
remoteuser = bla@adresse.de
remotepass = PasswortBla

[Account VariomediaBlubb]
localrepository = LocalVariomediaBlubb
remoterepository = RemoteVariomediaBlubb
expunge = no
readonly = True

[Repository LocalVariomediaBlubb]
type = Maildir
localfolders = ~/backup/IMAP/VariomediaBlubb

[Repository RemoteVariomediaBlubb]
type = IMAP
createfolders = False
ssl = yes
remotehost = imap.variomedia.de
remoteuser = blubb@adresse.de
remotepass = PasswortBlubb

Zunächst werden darin allgemeine Dinge konfiguriert, wichtig ist hier vor allem das readonly = True. Und anschließend werden die einzelnen Accounts dann separat definiert, IMAP-Zugangsdaten, lokale Ordner etc. Eigentlich selbsterklärend.

Am Ende den Aufruf wieder in die Crontab packen und fertig:

30 */3 * * * offlineimap -u quiet

4) Backup von Webspace und mySQL-Datenbanken

Wer ein eigenes Blog oder eine Webseite betreibt hat sicher auch Interesse daran, diese Sachen zu backupen. Viele Provider machen das, mir ist es lieber, selbst noch Kopien der Daten zu haben. Das sind nicht nur auf dem Webserver abgelegte Dateien, sondern auch dort gespeicherte Datenbanken, üblicherweise mySQL-Datenbanken. Zu diesem Zweck hab ich mir mal einen kleines Bash-Skript gebastelt, welches jeden Tag einen Ordner anlegt, in den dann die Daten der Webpräsenz inkl. der Datenbank abgelegt werden. Selbstverständlich will man nicht jeden Tag die kompletten Daten ziehen, daher wird das Backup über rsync durchgeführt und mit Hardlinks gearbeitet. Somit enthält jedes Tages-Verzeichnis die kompletten Daten, der physikalisch benötigte Speicherplatz ist aber nur der der geänderten Dateien:

#!/bin/bash

# Das Script muss so gestrickt sein, dass es keine Ausgabe erzeugt, wenn alles glatt läuft (cronjob!)

# Falls keine Parameter übergeben wurden:
if [ $# -eq 0 ]
 then
 echo " "
 echo "Es wurden keine Parameter übergeben!"
 echo " "
 echo " 1.Parameter: Domainname (z.B. 'dasaweb.de')"
 echo " 2.Parameter: SSH-User (z.B. 'u123456')"
 echo " 3.Parameter: mySQL-Host (z.B. 'db1.dasaweb.de')"
 echo " 4.Parameter: mySQL-User (z.B. 'u234567')"
 echo " 5.Parameter: mySQL-Passwort (z.B. 'nenekeinpasswort')"
 echo " "
 echo " "
 echo " Bsp.:"
 echo " "
 echo " backup-Variomedia.sh dasaweb.de u123456 db1.dasaweb.de u234567 nenekeinpasswort"
 echo " "
 echo " "
 echo " "
 echo " Hinweis: Das ganze funktioniert so natürlich nur, wenn ein SSH-Login auf den Webserver mit einem Schlüsselpaar eingerichtet ist."
 echo " "
 echo " "

 exit
fi

# Jetzt der Übersichtlichkeit halber die übergebenen Variable an ordentlich benannte übergeben:
DOMAIN=$1
SSHUSER=$2
DBHOST=$3
DBUSER=$4
DBPASS=$5

# Variablen für das Datum erzeugen (z.B. "2013-08-19"):
HEUTE=$(date +"%Y-%m-%d")
GESTERN=$(date -d yesterday +"%Y-%m-%d")

# Absolutes Verzeichnis für die Backup-Dateien setzen (ohne Slash am Ende):
VERZ=~/backup/Variomedia

### Jetzt der eigentliche Backupvorgang:

# 1) Prüfen, ob das Backupverzeichnis überhaupt exisitert:
if [ ! -d $VERZ/$DOMAIN ]; then mkdir $VERZ/$DOMAIN; fi

# 2) Komplette Kopie des gestrigen Verzeichnisses lokal anlegen, nur Hardlinks (eigentlich sollte das auch direkt per rsync und --link-dest gehen, geht es aber nicht, weil das über ssh läuft und die Dateien dann lokal andere Rechte etc haben und somit IMMER kopiert werden...):
cp --archive --link $VERZ/$DOMAIN/$GESTERN $VERZ/$DOMAIN/$HEUTE 2>/dev/null

# 3) Jetzt das rsync auf das heutige Verzeichnis ausführen:
rsync --archive --no-links --quiet --delete --rsh=ssh $SSHUSER@$DOMAIN:~/ $VERZ/$DOMAIN/$HEUTE # Besser wäre ohne --no-links --quiet, geht aber nicht, so lange die Fritzbox ihren Bug mit den Symlinks hat...

# 4) Abschließend die Datenbank noch in das heutige Verzeichnis dumpen:
mysqldump --all-databases --compress --host=$DBHOST --user=$DBUSER --password=$DBPASS | gzip > $VERZ/$DOMAIN/$HEUTE/mysql-dump-$DOMAIN-$HEUTE.sql.gz

Das Skript z.B. unter ~/skripte/backup-Webspace.sh speichern und per Cronjob ausführen:

00 1 * * * ~/skripte/backup-Webspace.sh dasaweb.de u123456 db1.dasaweb.de u234567 nenenekeinpasswort
15 1 * * * ~/skripte/backup-Webspace.sh dasasweb2.de u345678 db1.dasaweb.de u456789 nönönökeinpasswort

Evtl. müssen vorher noch rsync und mysqldump installiert werden, das sollte aber jetzt kein Problem mehr sein…

Zusätzlich will ich von jedem Monat einen Snapshot meiner Webpräsenzen erstellen. Das mache ich einfach am Monatsersten über einen weiteren Crontab-Eintrag:

0 4 1 * * tar -czf ~/backup/Variomedia/`date +\%Y-\%m-\%d`_Variomedia.tgz ~/backup/Variomedia/*/`date +\%Y-\%m-\%d`/ --exclude=*.mp3 --exclude=*.pptx

5) Backup der Delicious-Bookmarks

Ich bin einer von denen, die den Dino unter den Social-Bookmark-Diensten Delicious 1) noch kennen und 2) auch noch verwenden.  Ungern möchte ich meine dort gespeicherten Bookmarks verlieren, auch wenn ich sie wirklich nur selten zum Nachschlagen benutze. Manchmal aber doch.

Ich verwende für das Backup ein Skript, welches so auf der ursprünglichen Github-Seite nicht mehr zu finden ist. Daher hier der Quellcode:

#!/bin/sh
#
# NAME
# Delicious.sh - Download your bookmarks
#
# SYNOPSIS
# Delicious.sh   path>
#
# DESCRIPTION
# Downloads the bookmarks at Delicious as an XML file.
#
# How to export at midnight every day:
#
# First, make sure nobody else can read your crontab. If not, they can
# get access to your password, and I'm not good at sympathy.
#
# $ git clone git://github.com/l0b0/export.git
#
# $ crontab -e
#
# Insert a new line with the following contents (replacing the example
# paths and login with your own):
#
# @midnight /.../export/Delicious.sh user password /.../bookmarks.xml
#
# BUGS
# https://github.com/l0b0/export/issues
#
# COPYRIGHT AND LICENSE
# Copyright (C) 2010, 2011 Victor Engmark
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see .
#
################################################################################
set -o errexit -o nounset

if [ $# -ne 3 ]
then
echo 'Wrong parameters - See the documentation on top of the script'
exit 1
fi

USERNAME="$1"
PASSWORD="$2"
EXPORT_PATH="$3"

# Export
EXPORT_URL=https://api.del.icio.us/v1/posts/all
EXPORT_DATE="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
chunk_size=1000 # Delicious now only supports exporting 1000 bookmarks at a time
header_lines=3
chunk_lines=$(($chunk_size + $header_lines))
EXPORT_COMPATIBILITY='
s#^tag="[^"]*"\) \(total="[^"]*"\) \(user="[^"]*"\)>##;
s#^description="[^"]*"\) \(extended="[^"]*"\) \(hash="[^"]*"\) \(href="[^"]*"\) private="[^"]*" shared="[^"]*" \(tag="[^"]*"\) \(time="[^"]*"\)/># #'
EXPORT_REMOVE_LINES='3,${/^</d}'
bookmark_prefix='<post '

> "$EXPORT_PATH" # Empty bookmarks file

bookmarks_count() {
# How many bookmarks have we fetched?
grep -o "${bookmark_prefix}" "$EXPORT_PATH" | wc -l || true
}

while [ $(($(bookmarks_count) % $chunk_size)) -eq 0 ]
do
wget \
--user="$USERNAME" --password="$PASSWORD" \
-O- \
--no-check-certificate \
"$EXPORT_URL?start=$(bookmarks_count)" >> "$EXPORT_PATH"
done
sed -i -e 's#><#>\n<#g' "$EXPORT_PATH" # Introduce newlines
sed -i -e "$EXPORT_COMPATIBILITY" "$EXPORT_PATH"
sed -i -e "$EXPORT_REMOVE_LINES" "$EXPORT_PATH"
echo '' >> "$EXPORT_PATH"

Wie immer: Speichern, in die Crontab eintragen und fertig:

0 2 * * 6 ~/skripte/backup-delicious.sh dasaweb meindeliciouspasswort ~/backup/Delicious/backup-delicious-dasaweb-`date +\%Y-\%m-\%d`.xml > /dev/null 2>&1; gzip ~/backup/Delicious/backup-delicious-dasaweb-`date +\%Y-\%m-\%d`.xml

6) Backup der Remember The Milk-Aufgaben

Remember The Milk ist eine von mir sehr geschätzte und intensiv genutzte (ca. 10.000 erledigten Aufgaben in den letzten Jahren) Aufgabenverwaltung. Ich will gar nicht daran denken, was ein Datenverlust hier für Konsequenzen hätte. Die Aufgaben lassen sich im ics- und xml-Format sichern:

0 4 * * * wget --quiet --http-user=RTMUSER --http-passwd=RTMPASS -O - https://www.rememberthemilk.com/icalendar/RTMUSER/ | gzip > ~/backup/RememberTheMilk/backup-rememberthemilk-`date +\%Y-\%m-\%d`.ics.gz
5 4 * * * wget --quiet --http-user=RTMUSER --http-passwd=RTMPASS -O - https://www.rememberthemilk.com/atom/RTMUSER/ | gzip > ~/backup/RememberTheMilk/backup-rememberthemilk-`date +\%Y-\%m-\%d`.xml.gz

7) Backup der Dropbox

Ich habe einige Zeit investiert, um auch meine Dropbox auf den Raspberry Pi zu backupen. Lange im Netz gesucht, irgendwann dieses Skript hier gefunden, gekämpft, um die ganze für mich neue Python-Sache ordentlich zum Laufen zu bekommen, sogar in dem Python-Skript noch gepfuscht, weil es komische Sachen gemacht hat, und am Ende festgestellt, dass mein Raspberry Pi mit großen Dateien in der Dropbox so seine Probleme bekommt. Vielleicht ist auch nicht der Pi schuld sondern ich, aber egal. Ich habe aufgegeben, immerhin sind die Dropbox-Inhalte ja auch lokal auf meinem Laptop vorhanden, und dieser wird sehr regelmäßig gesichert. Ende.

8) Backup des Homeverzeichnisses des Raspberry Pi

Wenn sich im Laufe der Zeit diverse Skripte und Konfigurationsdateien im Home-Verzeichnis des Raspberry Pi ansammeln, dann sollte man auch dieses regelmäßig auf die externe Platte sichern. Ich mache das wöchentlich:

0 9 * * sun tar -czvf ~/backup/RaspberryPi/home-backup_`date +\%Y-\%m-\%d`.tgz ~ > /dev/null

9) Backup der Crontab

Genau so verhält es sich mit der Crontab an sich, auch die will gesichert sein. Das erste, was meiner Meinung nach also in einer Crontab stehen sollte, ist sowas hier:

1 0 * * * crontab -l > ~/cron.job; chmod 600 cron.job

Die so gesicherte Crontab kann jederzeit mit

crontab cron.job

wieder hergestellt werden.

Stimmt nicht ganz, das wirklich erste (es muss in der ersten Zeile stehen) in der Crontab sollte so aussehen:

MAILTO="<daniel@adresse.de>"

Meine Crontab-Einträge sind immer so gestrickt, dass sie keine Ausgabe erzeugen, wenn ein Skript fehlerfrei durchläuft. Mit diesem MAILTO-Eintrag sorgt man dafür, dass evtl. auftretende Fehler dann per Mail an die definierte Adresse zugestellt werden. Dazu muss der Raspberry Pi natürlich erst mal Mails versenden können ;o) Ich verwende dazu das schlichte sSMTP, eine kleine Anleitung zur Installation findet man z.B. hier.

10) Backup der SD-Karte des Raspberry Pi

Für den Fall eines Ausfalls der SD-Karte des Raspberry Pi ist es nützlich, von dieser ein Image auf der externen Festplatte zu haben, um dieses dann ggf. auf eine neue SD-Karte aufzuspielen und ohne weitere Konfigurationsmühen wieder loslegen zu können. Ich verwende dazu ein Shell-Skript, welches ich hier (unter „automatisches Backup) gefunden habe.

Speichern und ab in die Crontab damit:

0 10 * * sun sudo ~/skripte/backup-RaspberryPi-SD-card.sh

11) Was fehlt

Das ist schon eine ganze Menge, was der Raspberry Pi mir da auf die Backupplatte schaufelt. Ein paar Dinge fehlen mir aber noch:

• Backup meiner bei Remember the Milk verwalteten Aufgaben. Hatte übersehen, dass ich das schon am Laufen habe…
• Backup meiner beruflichen und freiberuflichen Arbeitszeiten, die ich mit mite. erfasse.
• Backup meiner Feedreader-Abos bei Feedly.
• Ein Mechanismus, der alte Backups so löscht, dass z.B. ab einem Alter von 3 Monaten nur die des Monatsersten stehen bleiben. Sollte nicht so wild sein, muss nur mal gemacht werden. Oder eben gegooglet…
  UPDATE: Besser wäre es z.B. beim Backup des Webspaces gleich rsnapshot zu verwenden, das bringt das gleich mit.
• Besserer Schutz meiner Passwörter, die hier und da im Plaintext in den Skripten stehen…