BLOG | KaiBrockelt

Beitrag vom 28. Februar 2016

Ich bin ja ein absoluter Fan vom Raspberry Pi, einem kleinen System-on-a-Chip Computer im Hosentaschenformat. Gerade durch seine vielfältigen Einsatzmöglichkeiten verleitet er immer wieder zum Spielen und Basteln. Jetzt habe ich ihn als Backup-Maschine eingesetzt.

Hier beschreibe ich jetzt meine Erfahrungen und Arbeitsschritte bei der Einrichtung des kleinen Supercomputers für automatische Datensicherungen. Der Artikel ist insgesamt etwas länger und geht stellenweise tief in die Linux Materie. Dafür kann sich das Ergebnis durchaus sehen lassen. Ausdauer ist also gefragt. Fangen wir am besten ganz vorne an:

Sicher ist sicher

Wie wichtig und vorteilhaft ein Backup ist, sollte man ja mittlerweile wissen. Das für private Daten und für Websites: Irgendwann ist es mal so weit. Festplatten fallen aus, man löscht versehentlich etwas unwiderruflich, ein Malwarebefall macht die Daten unbrauchbar.Gerade bei lebhaften Websites, auf denen viel gearbeitet und geschrieben wird, sind regelmäßige und automatische Backups Pflichtprogramm. Backups sollten dabei unbedingt auf einem entfernten System liegen, um nicht mit dem Webserver gemeinsam dem GAU ausgesetzt zu sein.

Die meisten Webhosts bieten auch Backups an. Meist sind die Pläne aber „von der Stange“ und unflexibel. Man kann auch tiefer in die Tasche greifen und auf einen individuellen Backup-Plan setzen. 

Oder man schraubt sich selbst was zusammen. 

Einen eigenen Backup Plan entwickeln

Wenn man selbstständig automatisierte Backups machen will, nimmt man in der Regel einen zweiten Server zur Hand. In zeitgesteuerten Abständen werden Dumps erstellt und in Richtung Backupserver gespielt. Dort werden Backups für X Tage aufbewahrt, bis sie den Platz für neue Backups frei geben. Der Backupserver wird anschließend noch zu einem Fort Knox umgebaut, sodass von außen so gut wie nichts und niemand rein darf. 

Bei Daten, die sich regelmäßig ändern, werden Backups entsprechend hochfrequentiert gemacht. Ein Backup-Plan für einen Blog, auf dem mehrmals die Woche etwas geschrieben wird, könnte so aussehen

• Mache jeden Tag ein Backup und halte es 30 Tage vor
• Mache zusätzlich noch ein monatliches Backup und halte es ein Jahr vor
• Für die totale Paranoia mache noch ein jährliches Backup und halte es 10 Jahre vor

Als Server kann man sich dann eine weitere Maschine anmieten. Oder man stellt sich Zuhause einen Rechner hin, der den Backup-Job übernimmt. Und genau hier kommt der Raspberry PI ins Spiel.

Gestatten: Raspberry PI

Wer ihn noch nicht kennt: Der Raspberry Pi ist ein kleiner lüfterloser Ein-Platinen-Rechner in der Größe eines Smartphones. Er ist in der Bastlerszene sehr beliebt, weil er so vielseitig eingesetzt werden kann. Mittlerweile gibt es ihn in der Version 2: 900Mhz Quadcore ARM CPU, 1GB Ram, 100Mbits Ethernet und 4xUSB 2 und mehr sind verbaut. Statt von Festplatten bootet das Betriebssystem von einer Mico-SD Karte. Strom bekommt er über einen Mikro-USB Anschluss. Als Betriebssystem wird häufig „Raspbian“ – eine für das Gerät optimierte Debian Distribution  – eingesetzt. Für nicht mal 35€ bekommt man die nackte Platine. Gehäuse gibt es ab 5 €.

Mit Raspbian hat man ein vollwertiges Linux System auf seinem Pi laufen. Backups produzieren relativ wenig Last auf dem System. Deshalb ist der Raspberry Pi 2 für so etwas ausgezeichnet geeignet. Warum nicht also einen Raspberry Pi für diesen Zweck einsetzten?!

Raspberry Backup: Was brauchen wir?

Ich gehe einfach mal davon aus, dass notwendige Infrastruktur wie ein Router und ein Netzwerkkabel vorhanden sind, in die wir unser Backup integrieren. Besorgen müssen wir uns also folgendes:

• Einen Raspberry Pi 2: 35€
• Eine Class 10 Mikro SD Karte mit mindestens 4 GB Speicherplatz: 5€
• Einen (oder mehrere) hochwertige USB-Sticks als Backup Speicher. 32 GB kosten momentan rund 15€
• Ggf. ein USB Netzteil und Mikro-USB Kabel. Es sollte 2 Ampere bei 5 Volt Ausgangsspannung liefern. Falls nicht vorhanden: bis 10€

Macht Summa Summarum 65€ Materialkosten. 

Es gibt auch verschiedene Sets, bei denen der Raspberry mit Gehäuse, eingerichter SD Karte, Stromversorgung, Wifi und mehr geliefert wird. Je nach dem, was man braucht, kann so ein Set sinnvoll sein.

Beim USB Stick ist es wichtig, dass er die anliegenden USB Ports nicht bedeckt, falls du sie noch nutzen willst. Ein schmaler Formfaktor ist also wichtig. Mein Router hat noch einen USB Port frei. Diesen nutzte ich für die Stromversorgung. Das Netzteil kann ich mir also sparen. Allerdings muss ich sicherstellen, dass der Port genug Strom liefert, sodass der Pi sich nicht aufhängt.

Betriebs­kosten­vergleich

Für vollwertige Backups-as-a-Service können im kleinen Rahmen schon locker mal 50 Flocken im Monat fließen. Die Grenzen sind nach oben offen. Kleinere FTP Server kann man im Internet für rund 5€ im Monat mieten. Mehr Leistung kostet natürlich auch mehr Geld.

Beim Pi sitze ich – solange die Hardware nicht gewartet werden muss – nur auf den Stromkosten. Powerpi.de hat das schon mal durchgerechnet und ist bei einem Kilowattstundenpreis von 0,28€ auf 6,48 € Jahresverbrauch gekommen. Dabei gingen sie von einem Mittelwert zwischen Idle und Vollast aus. Da der Pi in unserem Szenario nur wenige Lastspitzen am Tag erreicht und wir keine Peripherie angeschlossen haben, sollte der Verbrauch noch mal deutlich geringer sein.

Bei einem Laptop als Backup Server habe ich im Vergleich für ein 85W Netzteil jährliche Kosten von 210€ errechnet. 

Benefits

Den Raspberry Pi als Backupserver einzusetzen ist also sehr günstig. Es ist außerdem sehr praktisch, dass man die Backups immer vor Ort hat und nach Belieben den Speicher erweitern oder austauschen kann. Er sitzt außerdem hinter dem Router und ist  –  wenn keine eingehenden Verbindungen durchgelassen werden – von außen nur schwer angreifbar. Da er nur während des Backupvorgangs ein wenig Last erzeugt, sind noch genügend Ressourcen vorhanden, um ihn für andere Aufgaben im lokalen Netzwerk zu nutzen. 

Kosten und Nutzen stehen nach unserer Analyse in einem sehr guten Verhältnis. Es ist deshalb an der Zeit, los zu legen. Die meisten Anleitungsschritte für die Script-Konfiguration funktionieren auch unter fast jedem anderen Linux Betriebssystem und sind entsprechend übertragbar.

Grund­installation und Konfiguration

Ich halte die Micro SD Karte bereit und lade mir ein aktuelles Image von Raspbian herunter. Auf einen vollwertigen Desktop kann ich verzichten, also reicht mir die LITE Version. Ich flashe das Image anschließend auf die SD Karte. Wer nicht weiß, wie das geht, findet hier mehrere Möglichkeiten in Englisch.

Die fertige SD Karte schiebe ich dann in den Pi. Ich verbinde das Netzwerkkabel mit dem Router und klemme anschließend die Mikro-USB Stromversorgung an den freien USB Port, sodass der Pi jetzt aufleuchtet und das frisch installierte Raspbian von der SD Karte bootet. 

Über das Admin Interface meines Routers finde ich die IP des Pis. Hier vergebe ich gleich eine feste Adresse, sodass ich sie nicht immer suchen muss. Falls das Gerät nicht erscheint hat entweder das Flashen nicht funktioniert, oder die Stromversorgung des Routers ist nicht stark genug. Im Zweifelsfall klemmt man einen Monitor an den HDMI Port und schaut, ob irgendwas passiert. 

Ich melde mich via SSH an dem Raspberry an. Der Standardbenutzer heißt pi und das Passwort raspberry.

Ich rufe mit sudo raspi-config die Raspbian Konfiguration auf und konfiguriere das System durch:

1. Ich update zunächst das Config Tool unter dem Menüpunkt“Advanced –>Update“.
2. Dann wird das Dateisystem erweitert, sodass die gesamte SD Karte genutzt werden kann.
3. Ich ändere das Standardpasswort, sodass sich nicht jeder Depp an meinem Pi anmelden kann. 
4. Die Lokalisierung stelle ich auf Deutsch – sprich Zeitzone, Tastaturlayout und Zeichensatz (Nimm bitte DE_UTF8!).
5. Der verfügbare Grafikspeicher wird auf das Minimium von 16Mb runter geschraubt, damit das System den RAM für’s Arbeiten voll zur Verfügung hat.
6. Da der Raspberry keine eingebaute Batterie hat, wird sich die Uhrzeit nicht gemerkt. Damit das System so früh wie möglich die Uhrzeit aus dem Internet empfängt, aktiviere ich noch die Option „Wait for Network at boot“. So wird unser Cron später nicht mit ungültigen Uhrzeiten arbeiten.

Ich verlasse das Tool und starte den Raspberry mit sudo shutdown -r now neu, damit die neue Konfiguration ins System geladen wird. Nachdem ich mich wieder verbunden habe, spiele ich noch mit sudo apt-get update && apt-get upgrade die aktuellen Updates ein und der Pi ist startbereit. 

Lasttest

Da ich meinen Pi nicht über ein Netzteil betreibe und den Strom aus dem USB Port meines Routers beziehe, weiß ich leider nicht, ob die Leistung des Anschlusses für den Pi auch unter Last ausreichend ist. Genau das möchte ich aber brennend wissen und unterziehe deshalb den Pi einen Lasttest. Via sudo apt-get install stress installiere ich mir das Tool „Stress“. Um die Stromversorgung zu testen erzeuge ich mit stress -c 4 -t 60 1 Minute Volllast auf allen 4 Prozessorkernen.

Mein Pi friert Gott sei Dank nicht ein und übersteht den Lasttest. Deshalb darf er weiterhin seinen Strom über den Router beziehen.

Vorbereitung des Backup­speichers

Kümmern wir uns jetzt erst einmal um den USB Speicher. Als aller Erstes mache ich den USB Stick platt und formatiere ihn. Da ich ihn später auch mal unter Windows und OSX verwenden möchte, um die Backups einzusehen oder zu verwenden, formatiere ich ihn auf FAT32. In einer Linux-Only Umgebung wäre ext4 vermutlich eine bessere Wahl, da die maximale Dateigröße bei FAT32 die 4 Gigabyte Grenze nicht überschreiten kann. So groß werden meine Backups aber erst einmal nicht. Von daher passt FAT32.

Die neue Partition erhält das Label „BACKUP“. Später soll der Speicher automatisch über das Label eingebunden werden, sodass wir ihn einfach austauschen können. Nach der Formatierung kann der Stick an den Pi angeschlossen werden.

Mit dem Befehl sudo blkid -o list prüfen wir, ob der Stick am Pi erkannt wird. Hat alles geklappt, sehen wir einen Eintrag vom Typ vfat mit dem Label „BACKUP“. Das ist unser USB Stick. Ganz links finden wir die Gerätedatei des Sticks – vermutlich ist es die /dev/sda1. Die merken oder kopieren wir uns.

Im Verzeichnis /media/ erstellen wir uns einen neuen Ordner, in dem der Stick gleich eingehängt werden soll. Bei mir heißt er „usb“. Mit dem Befehl sudo mount -t vfat -o utf8,uid=pi,gid=pi,noatime /dev/sda1 /media/usb bzw. sudo mount -t ext4 -o defaults /dev/sda1 /media/usb bei ext4 binden wir den Stick ein.

Jetzt können wir auf dem USB Stick mit mkdir /media/usb/daily && sync einen Ordner für unsere täglichen Backups erstellen. Zum Test werfen wir den USB Stick noch mal mit sudo umount /media/usb aus. Ist der Ordner verschwunden? Gut!

Damit der USB Stick automatisch nach einem Stromausfall oder Neustart eingebunden wird, müssen wir ihn in die Datei /etc/fstab eintragen. Die Gerätedatei kann sich gerade nach Updates gerne mal ändern. Da es möglich sein soll, auch einen anderen USB Stick mal automatisch einzubinden, ist die Geräte-UUID auch ungeeignet für die automatische Einbindung. Deshalb binden wir ihn über das Label ein. 

LABEL=BACKUP /media/usbstick/ vfat utf8,uid=pi,gid=pi,noatime 0 0

Wir erinnern uns, dass wir unseren USB Stick „BACKUP“ genannt haben. Solange ein USB Stick mit dem Label angeschlossen ist, wird er automatisch eingebunden. Wir können also – wenn der Speicher knapp wird – den USB Stick einfach austauschen.

Um unsere Einbindung zu testen, starten wir den Pi noch mal neu. Falls bei der Konfiguration etwas schief gegangen ist, wird der Pi in einen Recovery Modus starten und nicht mehr via ssh erreichbar sein. Für diesen Fall sollte man noch mal Monitor und Tastatur bereit halten.

Ist nach dem Neustart unser Verzeichnis „daily“ in /media/usb vorhanden, ist der Stick erfolgreich eingebunden. Wir können uns also an den nächsten Schritt wagen 🙂

Der Backup Prozess

Unser Backup soll täglich via Cron gestartet werden und folgendermaßen ablaufen:

1. Der Pi wählt sich über eine sichere SSH Verbindung ein. Dort stößt er ein Script an, das unsere Webroot-Verzeichnisse sowie Dumps der Datenbanken in einem tgz-Archiv namens „Backups.tgz“ speichert.
2. Via SCP wird das Packet abgeholt und unter den Namen „Website-HeutigesDatum.tgz“ auf den USB Stick gespeichert. 
3. Das Archiv wird via SSH wieder vom Webserver gelöscht.
4. Wir räumen zu guter Letzt den USB Stick auf und löschen alle Backups im „daily“ Verzeichnis, die älter als 30 Tage sind.

Analog dazu können auch monthly und yearly Sicherungen verwaltet werden. Das ist das Gleiche noch mal in grün und wird deshalb nicht tiefer behandelt.

Um die Backups anzustoßen, läuft auf dem Pi ein Cronjob, der ein lokales Script ausführt, der die oben gelisteten Schritte anstößt. Für die Archiverstellung wird via SSH auf dem Server auch ein Script erstellt, welches dann vom Backup-Job aufgerufen wird.

Schlüssel erstellen und hinterlegen

Damit unser cron sich ohne Passworteingabe auf dem Webserver anmelden kann, brauchen wir einen Public Key, den wir auf dem Pi generieren und auf dem Webserver hinterlegen. Das Schlüsselpaar erstellen wir uns via ssh_keygen. Die Passphrase lassen wir leer. Sonst kann der Cron nicht ohne Weiteres den Schlüssel verwenden. Diesen Schlüssel hinterlegen wir entweder via ssh-copy-id benutzer@webserver oder per Editing in die ~/.ssh/authorized_keys Datei des Webservers. Nein, wir hinterlegen die Datei nicht beim Root-User. Besser ist es, sie in den Benutzer des Webhosts zu legen. Noch besser ist es, einen eigenen Benutzer für den Job  – und wirklich nur diesen Job – anzulegen, der über die Gruppenberechtigungen auf dem Webroot Verzeichnis lesen kann.

Um die Scripte leichter lesbar zu machen, erstellen wir uns für jeden Host noch einen Eintrag in der Config-Datei des pi-Users in ~/.ssh/config:

Host meinserver
     Hostname Webserverip-oder-domain
     User der-eben-angelegte-User

Mit einem Aufruf von ssh meinserver sollten wir uns jetzt auf direktem Wege auf dem Webserver anmelden können.

Serverseitiges Backup einrichten

Falls du die Verbindung schon wieder getrennt hast, baue sie gleich noch mal auf. Wir befinden uns jetzt im Home Verzeichnis des Benutzers, welches sich hoffentlich außerhalb des Webroots befindet. Hier legen wir ein neues Verzeichnis für die Backups an. Immernoch im Home Verzeichnis erstellen wir ein Shellscript, das erst die Datenbanken in das Backup-Verzeichnis Dumpt und dann via tar die Webroots und die frischen Dumps in eine Archivdatei legt. Für die einfache Anpassbarkeit des Scripts werden Verzeichnisse und DB-Logins in Variablen hinterlegt. Du möchtest das Script ja vielleicht noch auf anderen Servern verwenden.

#!/bin/sh
# Script-Name: backup
# Version    : 0.1
# Autor      : Kai Brockelt
# Datum      : 21.02.2016
# Lizenz     : Mach damit was du willst. Ich erhebe keinen Anspruch. 
# Aber ich bin auch nicht für Schäden verantwortlich.

# Das Basisverzeichnis, in dem wir arbeiten.
basedir='~/backups/'

#eine Liste Mit Verzeichnissen, die wir backuppen wollen
d1='/pfad/zum/webroot/verzeichnis/'

#weitere Pfade
#d2='/weiterer/pfad/'
#d3='../pfade/koennen/auch/relativ/sein/'
#...

#Datenbankkonfigurationen, für jede Datenbank, die wir dumpen wollen
dbuser1='User1'
dbpass1='SuperGeheimesPasswort'
db1='Datenbankname'

#weitere Datenbanken
#dbuser2='User2'
#dbpass2='einPasswort'
#db2='eineDatenbank'
#...


############
#LOS GEHTS!#
############

#in das Arbeitsverzeichnis wechseln
cd $basedir

#Einen Dump für jede oben konfigurierte Datenbank erstellen
echo "Datenbank sichern"
mysqldump --user="$dbuser1" --password="$dbpass1" $db1 >./$db1".sql"
#mysqldump --user="$dbuser2" --password="$dbpass2" $db2 >./$db2".sql"
#mysqldump --user="$dbuser3" --password="$dbpass3" $db3 >./$db3".sql"
#...

#Jetzt alles zusammenfassen und in ein Archiv stecken
echo "dump komprimieren"

tar -cvzf backup.tgz $d1 $d2 $d3  $db1".sql" $db2".sql" $db3".sql"


#Aufräumen
echo "Alte files löschen"
rm -rf $db1".sql" $db2".sql" $db3".sql"
echo "done..."

Stelle sicher, dass du die Variablen entsprechend deiner Konfiguration anpasst und auch im tar Befehl nur die Variablen verbaust, die du nutzt. Via chmod 700 machst du die Datei jetzt noch ausführbar. Wenn du das Script da oben verstehst und dir einigermaßen darüber im klaren bist, was hier geschieht darfst du es jetzt ausführen. 😉
Nachdem das Script durchgerödelt ist, sollte sich jetzt eine Datei namens backup.tgz in deinem Backups-Verzeichnis befinden. Die Hälfte des Backups ist also geschafft 🙂

Backup Script auf dem PI einrichten

Da wir jetzt schon mal in der Lage sind, uns Backup Archive auf dem Webserver zu erstellen, müssen wir dem Pi jetzt noch beibringen, die Backups abzuholen. Die notwendigen Vorbereitungen sind soweit ja schon getroffen:

• Der SSH Tunnel zwischen Pi und Webserver steht
• Der Benutzer für die Backups ist angelegt
• das Backupscript ist geschrieben und funktioniert

Hierzu erstellen wir im Homeverzeichnis des pi-Nutzers ein neues Script, das zunächst via SSH das entfernte Script zum Dumpen der Websites aufruft. Wenn das Script durch ist, verbinden wir uns via SCP und kopieren das frisch erstellte Archiv auf unseren USB Stick. Anschließend soll sich der Pi noch mal am Webserver anmelden und das alte Dump löschen, damit der Speicher wieder frei wird. Sind unsere Backups übertragen, möchte ich alle Backups des Daily Ordners löschen, die älter als 30 Tage sind. 

Da ich plane, für mehrere Server Scripte einzurichten, und sie alle auf einen Schlag anstoßen möchte, baue ich ein „Master“-Script, in dem die einzelnen Scripte aufgerufen werden. Die Aufräum-Arbeiten möchte ich auch pro lauf nur einmal machen. Deshalb kommen sie auch in das Master-Script:

#!/bin/sh
# Script-Name: backup
# Version    : 0.1
# Autor      : Kai Brockelt
# Datum      : 21.02.2016
# Lizenz     : Mach damit was du willst. Ich erhebe keinen Anspruch. 
# Aber ich bin auch nicht für Schäden verantwortlich.

#Verzeichnis in dem geloescht werden soll
backupverzeichnis="/media/usb/daily/"

#alter der dateien die geloescht werden sollen in Tagen
days=30


#backupscripte ausführen
echo "starte backups"
/home/pi/scripts/daily/website-1.sh
#/home/pi/scripts/daily/website-2.sh
#/home/pi/scripts/daily/website-n.sh

echo "altbackups löschen"
find $backupverzeichnis -mtime +$days -type f -delete

echo "noch einmal buffer leeren"
sync
echo "fertig!"

Das Ganze speichere ich unter ~/scripts/backupmaster.sh und mache es wieder mit chmod 700 Dateiname ausführbar. Jetzt lege ich noch für jeden Server, den ich sichern möchte das nötige Script an, das sich darum kümmert, mir die Daten auf den Speicher zu schieben.

#!/bin/sh
# Script-Name: backup Script fuer einen Host
# Version    : 0.1
# Autor      : Kai Brockelt
# Datum      : 21.02.2016
# Lizenz     : Mach damit was du willst. Ich erhebe keinen Anspruch. 
# Aber ich bin auch nicht für Schäden verantwortlich.

#variablen definieren
timestamp=`date +%Y-%m-%d-%H-%M`
name="meinBackup"
ext=".tgz"

#server kann eine IP, eine Domain oder ein Host Eintrag deiner ssh/config datei sein
server="website1"
# das Script, das auf deinem Server aufgerufen wird
remotebefehl="~/backup.sh"
# Pfadangabe zur Datei deines Backup-Archivs
quelle="~/backups/backup.tgz"
# Pfadangabe zum Speicherort auf dem USB Stick
ziel="/media/usb/daily/"

echo "backup $name generieren"

#Script zur Archiverstellung aufrufen.
/usr/bin/ssh $server "$remotebefehl" >/dev/null
echo "backup holen"

#Backups kopieren
/usr/bin/scp $server:$quelle $ziel$name$timestamp$ext

#Archiv vom Server löschen.
echo "remote Backup löschen"
/usr/bin/ssh $server "rm -rf $quelle"

# Schreibvorgang auf dem Datenträger erzwingen
echo "buffer flushen"
sync
echo "backup fuer $name ist fertig"

Speichere das Script unter dem Namen, unter dem du es im Master-Scritpt aufrufen möchtest. Jetzt noch schnell ausführbar machen und wir sind fertig. 

Zum Testen rufen wir noch unser Masterscript mit ~/scripts/backupmaster.sh auf und überprüfen, ob etwas auf dem USB Stick angekommen ist.

Letzter Schritt: Cron aktivieren

So,.. alle Scripte sind getestet und laufen. Backups landen auf unserem Speicher. Es ist an der Zeit, den Cron an zu werfen.
Meine täglichen Backups sollen immer Nachts laufen, wenn das Internet sonst nicht gebraucht wird. Tagsüber können größere Datenübertragungen schon mal den Betrieb stören und rumnerven. Mit dem Befehl crontab -e öffne ich meine lokale Cron Konfiguration und trage die Ausführung meines Scripts auf 3 Uhr ein.

0 3 * * * ~/scripts/backupscript.sh

Jetzt läuft mein Cron jede Nacht um 3 Uhr und stößt das Backup-Script an.

Hochrechnung: Wie viel passt auf meinen Stick drauf?

Um den Speicher des Sticks auch auszureizen, möchte ich noch wissen, wie viele Backups so im Schnitt auf den Stick passen, bis ich wieder alte Backups löschen muss. Ein Blick in den Backup Ordner verrät mir, wie viel Speicher pro Backup Zyklus benötigt wird. Da ich in etwa abschätzen kann, wie schnell die Websites wachsen, schätze ich einen zukünftigen mittleren Speicherverbrauch von 150MB (gezippt) pro täglichem Backup je Website.

mit df -h sehe ich, dass auf dem USB Stick effektiv 30GB verfügbar sind. Ich errechne, dass mit 30*1024 MB / 150 MB ganze 204 Backups auf meinen Stick passen. Für den am Anfang angedachten Backup Plan mit insgesamt 52 vorgehaltenen Backups ist der Stick also mehr als ausreichend.

Fazit

Der Raspberry Pi steckt nun im Schrank und macht für mich regelmäßige Backups. Dank der sehr geringen Stromkosten ist diese Lösung die günstigste, die ich bisher gesehen habe. Für mich war es den Aufwand für Setup und Konfiguration voll wert. Mit etwas Erfahrung ist so ein Projekt mal schnell an einem regnerischen Nachmittag umgesetzt. Ich hoffe, dass mein Erfahrungsbericht auch für dich hilfreich ist.

Tags: Backup, Cron, Dump, Linux, Raspberry Pi, SSH

• ← Alles schön neu hier
• CSS3 Viewport Units →