Beiträge von Pi31415

    Hallo Zusammen,

    ein dreiviertel Jahr(hundert) ist ins Land gezogen,... man wie die Zeit vergeht.
    Ich habe den Beitrag mal wieder erweitert, und dabei heute sogar zwei Versionssprünge hingelegt.

    V 1.6: Ich bin auf die Erstellung von RSA Keys mit puttygen im Kapitel Benutzer eingegangen.
    Das ganze möchte ich in Zukunft noch etwas erweitern und ggf. zu einem extra Kapitel machen,
    da dies zum einen ein wichtiger Baustein beim Thema Sicherheit ist, und bei jeder SSH Verbindung genutzt werden sollte,
    und zum Anderen wird es sonst etwas undurchsichtig wenn ich es bei jeder Verwendungsstelle neu erklären muss.


    V 1.7 Endlich habe ich eine kleine Beschreibung zum Backup mit Duplicati gemacht.
    Für die Clientcomputersicherung ist es wirklich schön, für die Sicherung über das Netzwerk / Internet zwischen zwei "Servern" ist es noch nicht so mein Freund. Vielleicht fahre ich hier zweigleisig und nutze Duplicati für die Clients, und R-Sync für Server - Server Spiegelungen.


    Kurzer Ausblick auf weitere Inhalte:

    Wie schon erwähnt plane ich das Thema Sicherheit etwas mehr zu behandeln.
    Dabei schwebt mir zum Einen das Absichern des SSH-Zugangs mit Zertifikaten vor,
    als auch das Arbeiten mit Ordner-Rechten auf dem Server damit die Clients nicht auf die
    Sicherungen der anderen Clients zugreifen können.


    Ich würde mich über neues Feedback freuen. Natürlich sind auch Wünsche immer gern gesehen.

    Grüße

    Marcel

    Je nachdem ob Deine Fritzbox das kann könntest Du an Port 4 das Gastnetzwerk aktivieren, und somit deinen Pi von deinem normalen Netzwerk trennen.
    Wenn jemand dann die Kontrolle über deinen Pi hätte, wäre er ziemlich einsam im Netzwerk, weil da nichts anderes ist.

    Nachteil: Du musst auch aus deinem internen Netzwerk immer über das Internet gehen um auf den Pi zu kommen.

    Und beachte: Standardmässig sind beim Gast-Netzwerk nur die Ports für Internet und E-Mail freigeben, ssh ist z.B. gesperrt.

    Grüße

    Marcel

    So mal wieder neues von der Backupfront.

    Ich bin weiter dabei mein System mit duplicati umzusetzen und zu testen.

    Die Performance ist im Vergleich zu rsync bescheiden, das liegt aber vermutlich daran, dass duplicati die Dateien packt und verschlüsselt. Ich sollte das ganze nochmal auf nem Raspi prüfen...

    Gerade spiele ich noch mit ein wenig Fehlerhandling, Freigaben, und natürlich damit ob die Daten wieder hergestellt werden können.

    Aufgrund der Tatsache das ich gerade anderweitig stark beschäftigt bin, könnte sich das
    ganze aber noch etwas ziehen.

    Außerdem bin ich mir noch immer nicht klar, wie ich das Thema aufziehe. Ein komplett neues Thema könnte dahingehend schlecht sein, weil essentielle Einstellungen auch schon in diesem Beitrag beschrieben sind, und ggf. doppelt gepflegt werden müssen. Deshalb tendiere ich dazu, das Kapitel 4 so zu belassen, und in ähnlicher Form mit Duplicati aufzuziehen. Vorher noch ein Vorwort mit einer groben Erklärung der beiden Konzepte mit Vor- und Nachteilen... und dann sollte das die sinnvollere Lösung sein.

    Hallo tarlatun,

    leider habe ich lange nicht geantwortet. Habe deinen Beitrag mal am Handy gesehen und dann vergessen.

    Spontan würde ich es so machen.

    Cronjob der dann startet wenn Du schlafen willst.
    Der ruft ein Bash script aus, das in etwa so aussieht

    ProzessID des laufenden Backupscripts auslesen
    pidof python

    Prozess mit der ProzessID killen

    kill PIDvonPYTHON

    Leider bin ich in Bash nicht sattelfest, und weiß daher nicht, wie Du das Ergebnis von pidof und kill verknüpfst, irgendwo muss sinnvoll ne Pipe o.ä. eingesetzt werden.

    Edit: pkill python sollte es tun! Dann wird das ganze script gekillt und es passiert dir auch nicht, dass nach 10min nochmal ein Versuch gestartet wird.


    Ich bin gerade dabei mein ganzes Konzept neu aufzuziehen.
    Statt einem Raspi benutze ich einen "echten" PC mit Debian (Was aber keinen großen bis keinen Unterschied beim Code macht).

    Statt rsync benutze ich Duplicati (Sowohl für die Clients, als auch auf dem Server mit Mono).

    Besteht hier weiterführendes Interesse?

    Ich könnte mir vorstellen diesen Beitrag anzupassen, oder einen neuen zu machen (im gleichen Stil). Gern nehme ich dazu Vorschläge entgegen.

    Das Stickwort heißt Pull-Down Widerstand.

    Du musst dafür sorgen, dass die Spannung beim ausgeschalteten Ausgang "zusammenbricht".
    Wenn deine Last zu klein ist, könnte es sein das es nicht ausreicht.
    Man kann im Programm Pull-Down oder Pull-Up Widerstände aktivieren, oder wenn das nicht passt (z.B. leuchtet die LED wohl vor dem Starten des Scripts!) kannst du auch einen möglichst großen Widerstand zwischen Ausgang und GND anschließen.

    Grüße

    Marcel


    Siehst Du, das


    Schau vielleicht mal -> hier <- rein ... dann weisst Du warum das nicht geht :fies: ...

    cu,
    -ds-

    Ich weis gar nicht warum du so eine Welle machst?

    Lies dir doch einmal den ersten Beitrag in Ruhe durch, dann wirst du feststellen das es dort folgende Infos gibt:

    Der TE hat den PI mit 2 verschiedenen Netzteilen versorgt (Daraus folgere ich den MicroUSB-Anschluss, alternativ via GPIO-Pins, aber die Info wie der Pi seinen Strom bekommt ist doch vollkommen irrelevant! Die beiden Netzteile liefern genug Strom für den Pi -> Die wichtige Info ist da)

    Dann hat er beschrieben, dass die Kartenleser am USB-Hub nicht gehen. Also geht man davon aus: USB PI -> USB-HUB -> Kartenleser 1-n.

    Anschließend berichtet er wenn er die Kartenleser direkt an den Pi klemmt (Also USB PI1 -> Kartenleser 1, USB Pi 2 -> Kartenleser 2) alles funktioniert.

    Ich bin also der Meinung das er alle wichtigen Informationen gebracht hat, auch wenn man dafür den Text lesen muss und keine bunten Bildchen anschauen kann.

    Aber um dem TE noch etwas input zu geben:

    Kannst du feststellen ob der externe USB-HUB wirklich mit Strom versorgt wird? Vielleicht ist dessen Netzteil beschädigt oder der Stecker wackelig, und der Hub zieht den Strom dann über den Pi!

    Grüße

    Marcel

    Warum erfolgt die Stromversorgung des Pi über die MicroUSB-Buchse und nicht über die 2 Pins am GPIO? Das erspart ein Kabel, ein Stecker und ne Löterei, also Geld.

    Grüße

    Marcel

    Edit: Vergesst es... hab es auch grad gerafft: Es wird statt dem Pi die USV mit Strom versorgt, die regelt dann ob Netz oder USV Betrieb.

    Hallo an Alle,

    ich habe wie in einem meiner Beiträge beschrieben den RPI als NAS/Backupserver im Einsatz. Nachdem das ganze nun eine Weile läuft bin ich dabei mir ein paar Gedanken zu Verbesserungen zu machen. Mein Hauptaugenmerk liegt auf den externen USB Festplatten.
    Diese würde ich gern bei nichtverwendung (90% des Tages) in den Energiesparmodus versetzen wie man es aus Windows kennt (Die Platte geht aus).

    Im /etc/fstab mounte ich meine Platten wie folgt:

    Code
    UUID=C2A83942A839366F   /media/USBHDD1   ntfs  defaults,errors=remount-ro 0       1
    UUID=FC68821B6881D534   /media/USBHDD2   ntfs  defaults,errors=remount-ro 0       1

    Das funktioniert nach dem Booten einwandfrei.

    Wenn ich nun via hdparm die Platte "abschalte" via:

    Code
    sudo hdparm -y /dev/sda

    Wird sie abgeschaltet, und bei Verwendung auch wieder eingeschaltet.
    Aber sie wird dann zum Beispiel als /dev/sdc vom system erkannt und nicht wieder über fstab und die UUID auf /media/USBHDD1 gemountet.

    Die Einstellung in der hdparm.conf das nach einer eingestellten Idle-Time die Platte mit einer bestimmten UUID abschaltet hat auch keine Funktion, hier ist meine Therorie aber das die config nicht beim boot gestartet wird. Aber das gibt erstmal schritt 2.

    Hier die Einstellungen der etc/hdparm.conf


    Code
    /dev/disk/by-uuid/C2A83942A839366F {
    	spindown_time = 60
    }

    Also fasse ich zusammen:

    1. Wie bekomme ich es hin, dass eine abgeschaltete Platte wieder wie im fstab eingetragen gemountet wird

    2. Wie bekomme ich es hin das eine Platte via UUID nach einer einstellbaren Idle-Zeit abgeschaltet wird.

    Grüße

    Marcel

    P.S: Ich werde mein Tutorial zum Backup/Nas-Server entsprechend erweitern und natürlich die passende Antwort als Quelle erwähnen.

    Das ist ne gute Frage...

    ich schreib mal wie der Fabi die "Lebensgeschichte" meiner Pis,... dann kann sich jeder Ausmalen wo das hinführen könnte...

    Pi #1: Lag sehr sehr lang in der Ecke... keine Zeit und kein echtes Projekt
    Irgendwann wurde er mit RASPBMC hinter den TV verbannt und fristete sein Dasein als Mediacenter.
    Als Python bei mir auf dem Programm stand, bekam der Pi Raspian verpasst und wurde zu einem "Client" für die
    Simulation DCS A10C (Details spare ich mir an dieser Stelle mal, wenn mein Projekt irgendwann mal weiter geht könnte
    daraus ja mal ein TUT werden). Jetzt ist er wieder das was er am Anfang war: Er liegt in der Ecke und wartet darauf als Sündenbock
    angeschlossen zu werden falls etwas getestet werden muss, damit ich nicht auf meinen Produktivsystemen rumheizen muss.
    Vielleicht wird er auch erstmal wieder nen RASPBMC ... mal gucken.

    Pi #2 + #3: NAS + Backupserver (Siehe Hier Raspberry Pi als NAS / Backupserver )

    Pi #4: Raspbmc bei der Freundin

    In Planung:

    Pi #5 könnte in den Verbund von Pi #2 und #3 eintreten und die Daten der Freudin als NAS Backupserver verwalten

    Ideen was man noch mit nem Pi machen könnte:

    Pi #6 könnte ein RASPBMC bekommen unter hinterm TV landen (Dann wäre Pi #1 wieder im Schrank)
    Pi #7 könnte bei einem Projekt verbaut werden das am Ende mal eine "CNC"-Fräse ist
    Pi #8 könnte als "Gehirn" in ein Ferngesteuertes Auto eingebaut werden
    Pi #9 könnte ein RASPBMC bekommen und in meinem Elternhaus untertauchen
    Pi #10 könnte ein (Web)Radio / MP3-Player werden
    Pi #11 könnte Unterwegs mit nem UMTS-Stick und WLAN + Akku Pack nen Hotspot aufmachen
    Pi #12 könnte nen Wecker werden (Cronjob + Espeak, MPlayer, etc)
    Pi #14 könnte eine FLARM Bodenstation werden

    Deswegen:

    Die Pi-Familie wird sicher einen als Zuwachs bekommen, da ich dieses Jahr aber schon 2 gekauft habe, und sicher noch einer dazu kommt... vllt. auch zwei... sage ich mal >5 (4 Gibt es ja nicht)

    Grüße

    Marcel

    Ich weis nicht was die Lan Buchse von nem Pi zu 5V DC sagt... im zweifel hast nen Kurzschluss und hämmerst > 60A über die Ethernetbuchse... bye bye Pi... Und wenn wir schon von 2500€ für die Pis reden... dann werden wohl noch 100€ für ne Gescheite verdrahtung der Spannungsversorgung über sein. Lustig wird es wenn man mal schnell nen Laptop mit ner Gibbit-Buchse an so nen Kabel klemmen will um sich auf zu schalten... das Ergebnis steht ja oben ...

    Grüße

    Marcel

    Man kann jetzt direkt auf die PINS gehen: Wobei nen passender Stecker auch ein wenig Geld kostet (Direkt Drauflöten ist doch mal keine Option!)

    Bitte guck mal in das Datenblatt von deinem Netzteil ob es eine Mindestlast hat. Es gibt (günstige) Netzteile die bei einer Leistung unter der Mindestlast eine zu hohe Ausgangsspannung haben, da die sich erst ab einem Gewissen Strom einstellt. Ein 60A Netzteil ist schon nen Klopper!

    Da deine Anwendung nicht auf Redundanz aufbaut (wie dein Link verrät) macht es also auch keinen Sinn mehrere Netzteile zu verbauen.

    Grüße

    Marcel

    Hallo Leute,

    erst einmal ein kleines "Hallo" in die Runde. Ich bin hier schon eine Weile unterwegs, und hab die ein oder andere Information aus dem Forum "abgezogen" und für meine Projekte verwendet. Deshalb habe ich den Entschluss gefasst und mein aktuellstes Projekt hier als Tutorial zur Verfügung zu stellen, um ein wenig was zurück zu geben. Dieses Tutorial baue ich so modular wie möglich auf, damit jeder nur das nutzen kann was er braucht. Es ist nicht notwendig das Projekt 1:1 nachzubauen.

    Noch eine Info vorweg zu mir: Ich bin erst durch den Raspi auf Linux gestoßen, und befinde mich meiner Meinung nach noch ganz am Anfang. Deshalb verzeiht mir bitte Fehler oder "schlechte" Wege in diesem Tutorial, und weist mich bitte darauf hin. Ich bin gern für Vorschläge offen, und markiere auch Punkte bei denen ich weis das noch Handlungsbedarf besteht entsprechend. Mein Projekt das in diesem Tutorial beschrieben wird funktioniert, und ist auch so seit gut einer Woche im aktiven Testbetrieb.

    Ich werde dieses Tutorial nicht am Stück und komplett veröffentlichen, und hoffe es gibt dafür Verständnis! Ich werde diesen Beitrag regelmässig editieren und neue Informationen und Kapitel hinzufügen. Alle Änderungen werde ich in der nachfolgenden Liste dokumentieren, damit jeder nachvollziehen kann was passiert ist.Im Inhaltsverzeichnis sind alle Themen die noch nicht vorhanden sind Orange markiert.

    Neu!!!
    ###############################################################

    Nun ist der Beitrag ein paar Tage alt, und es hat sich ein wenig was getan.
    Wer über die Zeit die Antworten auf den Beitrag verfolgt hat, der hat gemerkt, dass sich ein wenig was getan hat.

    - Mein Server ist kein Raspi mehr sondern ein PC mit Debian (Hoffe ich darf trotzdem im Forum bleiben)
    Das Tutorial ist für Raspian und Debian gültig, somit ergeben sich keine Probleme.
    - Ich mache das Backup nicht mehr mit rsync sondern mit duplicati (http://www.duplicaty.com)
    - Kapitel 4 - das sich mit dem eigentlichen Backup beschäftigt habe ich erweitert. Es gibt nun Kapitel 4a und 4b,
    einmal rsync und einmal duplicati, ihr habt also selbst die Wahl was ihr einsetzen wollt. Es gibt noch einen Hinweis
    vor dem Kapitel



    Versionsliste


    V1.7 Kapitel 4.1b 4.2b und 4.3b hinzugefügt. Backup und Restore mit Duplicati
    V1.6 Kapitel Benutzer hinzufühgen um SSH Keys mit Puttygen erweitert
    V1.5 Kapitel 4 gesplittet in 4a und 4b um Backups mit rsync und duplicati zu erläutern
    V1.4 Kapital 2.8 Energiesparen hinzugefügt
    V1.3 Script für Backup Netzwerk + Lokal unter Cronjobs hinzugefügt
    V1.2 Wo gehobelt wird... Kapitel 2.7 richtig korrigiert
    V1.1 Kapitel 2.7 verändert - Mount über UUID - Alten Beitrag rot markiert hinterlassen
    V1.0 Kapitel 4.6.2 Windows Client eingefügt
    V0.9 Kapitel 4.6.1 Linux Client eingefügt
    V0.8 Kapitel 5.3 Diagnose_Backup.php eingefügt
    V0.7 Kapitel 5.1 Apache Installation und 5.2 PHP Installation eingefügt
    V0.6 Kapitel 4.7 Zugriff auf gesicherte Dateien eingefügt
    V0.5 Kapitel 4.3 Netzwerk Backup mit Python Script "backup_netzwerk.py" eingefügt
    V0.4 Kapitel 4.2 Lokales Backup mit Python Script "backup_lokal.py" eingefügt
    V0.3 Hinweis von raspiServerBastler übernommen und RaspiConfig Kapitel erweitert
    V0.2 Grafiken eingefügt, Kaptiel 4.1, 4.4 und 4.5 geschrieben, Kapitel 4.2 und 4.3 begonnen, Kapitel 2.3 eingefügt
    V0.1 Beitrag erstellt



    Inhaltsverzeichnis

    1. Projektbeschreibung

    2. Raspberry Pi - Installation
    2.1 Betriebssystem
    2.2 Raspiconfig
    2.3 SSH
    2.4 Update
    2.5 Netzwerkeinstellungen
    2.6 Benutzer anlegen + RSA-Key / Putty-Gen
    2.7 Festplatten mounten
    2.8 Energie sparen

    3. Samba einrichten
    3.1 Installtion
    3.2 Config

    4. Backup einrichten

    4.1a rsync Installation
    4.2a rsync Lokales Backup mit Python Script "backup_lokal.py"
    4.3a rsync Netzwerk Backup mit Python Script "backup_netzwerk.py"
    4.4a rsync Log-Files
    4.5a rsync Cronjobs
    4.6a rsync Sicherung der Clients
    4.6.1a rsync Linux Client
    4.6.2a rsync Windows Client
    4.6.3a rsync MacOS Client
    4.7a rsync Zugriff auf gesicherte Dateien

    4.1b duplicati installation
    4.2b duplicati Backup
    4.3b duplicati Zugriff auf gesicherte Dateien

    5. Apache einrichten
    5.1 Apache Installation
    5.2 PHP Installation
    5.3 Diagnose_Backup.php



    1. Projektbeschreibung

    Dieses Projekt widmet sich der Thematik Backup. folgende Hardware ist für dieses Projekt verbaut:

    - 2 x Raspberry Pi B 512mb
    - 4 x externe USB Festplatte (Mit externer Spannungsversorgung)

    An jedem Pi sind je zwei externe USB Festplatten angeschlossen. Diese sollen die Daten unseres NAS und die Backup-Daten aufnehmen. Beide Pi befinden sich an verschiedenen Orten (in meinem Fall ca. 600km auseinander) um die Datensicherheit zu gewährleisten (wenn z.B. ein Haus abbrennt o.ä.). Jede Nacht wird via Cronjob der Ordner Backup von pi#1 auf die 2. Festplatte von pi#2 kopiert und ebenso umgekehrt. Dies geschieht in meinem Fall durch einen VPN Tunnel und SSH. Anschließend werden die Daten noch auf die 2. Festplatte Lokal kopiert.
    Dadurch sind die Daten 4 mal vorhanden:

    1. auf dem Lokalen Gerät
    2. auf der HDD #1 des lokalen Pis
    3. am Folgetag auf HDD #2 des lokalen Pis
    4. am Folgetag auf HDD #2 des entfernten Pis

    Dies bietet wie der erfahrene User vielleicht schon bemerkt hat nur den Schutz vor Verlust, aber nicht vor Veränderung der Daten. Wird von einem lokalen Computer eine Veränderte Datei in das Backup-Verzeichnis eingespielt, ist sie spätestens nach einer Nacht an allen Speicherorten abgeglichen. Ich werde diesen Punkt noch einmal testen, ggf. behält rsync durch das inkrementelle Backup doch alte Versionsstände, ich werde diesen Punkt dann entsprechend anpassen. Solange ich dies nicht 100% garantieren kann weise ich auf diesen Umstand hin!


    Als Informationen die vermutlich als Entscheidungsgrundlage dienen könnten:
    Die nachfolgenden Werte sind mit folgendem Setup gemessen worden:

    USBHDD - PI - LAN (100mbit) - Fritzbox - WLAN N (5GHz) - Win8 PC


    Datei lesen (PI -> PC) : ca. 6-8MB/s
    Datei schreiben (PC -> PI) : ca. 2-4MB/s


    2. Raspberry Pi - Installation

    2.1 Installation

    Als Betriebssystem habe ich mich für Raspian entschieden, da es mir alle Möglichkeiten die ich für dieses Projekt brauche bereitstellt und ich damit bisher am Besten vertraut bin.

    Ich empfehle Noobs für die Installation von Raspian zu benutzen, da es einem viel Arbeit abnimmt
    und keine großen Kenntnisse vorraussetzt. Die aktuelle Version ist in wenigen Sekunden im Internet zu finden.


    2.2 Raspiconfig

    Nach der Installation sollte in der Raspiconfig folgendes eingestellt werden:

    passwort für den benutzer pi ändern
    Hostname ändern: z.B: BACKUPSERVER
    SSH aktivieren
    Overklock kann auf Medium gestellt werden
    Uhrzeit und Zeitzone stellen (Wichtig für Cronjobs)


    Zitat


    Hinweis vom User raspiServerBastler:

    Er hat mich darauf hingewiesen, dass man in der RaspiConfig noch die Sprache auf Deutsch stellen sollte.
    Ich hatte dies nicht erwähnt da die neuste Version von Noobs dies automatisch tut wenn man die Setupsprache auf
    Deutsch stellt, aber da es sicher auch User gibt die sich Noobs sparen, erwähne ich es hier dennoch:

    Sprache und Tastaturlayout festlegen!

    Vielen Dank raspiServerBastler!


    Anschließend rebooten und den ersten Systemstart abwarten (ziemlich lang)



    2.3 SSH

    Ab diesem Punkt kann der Raspberry Pi Headless betrieben werden, also ohne Monitor, Maus und Tastatur.
    Der Zugang via SHH ist hier das Schlüsselwort. Ich nutze hierzu Putty, da ich unter Windows unterwegs bin.
    Unter Linux hat man SSH meist onBoard.
    Hinweise zur SSH bzw. der Anmeldung an dem Pi kommen nochmal detaillierter im Kapitel Benutzer zum Tragen.



    2.4 Updates

    Als erstes sollten alle Pakete aktualisiert werden, das geht so:


    Code
    sudo apt-get update


    2.5 Netzwerkeinstellungen

    Ich habe meinen Raspberry Pis eine statische IP-Adresse verpasst. Da ich von einem Ort via VPN auf den entfernten PI zugreifen möchte, ist der Hostname keine Möglichkeit um z.B. eine SSH Verbindung aufzubauen.


    Code
    sudo nano /etc/network/interfaces


    So in etwa sollte das Ergebnis aussehen (IP-Adresse und Gateway natürlich anpassen!)



    2.6 Benutzer Anlegen + RSA-Key / Puttygen

    Für die Verwendung als NAS ist es sinnvoll Benutzer anzulegen.
    Somit können dann z.B. verschiedene Personen ihre Backups auf dem NAS sichern,
    ohne das der andere Zugriff auf diese Daten hat. Außerdem nutzt man dann nicht
    für alle Funktionen einen User mit Root-Zugriff (pi), das kann nämlich ziemlich ins
    Auge gehen. Unser User heißt hier backupuser. Das Passwort ist frei wählbar,
    der einfachheit halber machen wir im Beispiel mal 1234. Bitte ein besseres wählen!


    Code
    sudo useradd backupuser -m -G users
    
    
        sudo passwd backupuser

    Für die Authentifizierung ohne Passwort gibt es die Möglichkeit einen
    RSA-Key anzulegen.

    Dieser kann notwendig werden wenn man sein Backup via SSH auf
    einen anderen PC übertragen will. Denn wenn der RSA-Key bekannt ist
    wird nicht nach einem Passwort gefragt, das würde bei einem Script eher stören.

    Um den RSA Key zu erstellen muss man sich mit dem user anmelden, also


    Code
    su backupuser


    Nachdem man das korrekte Passwort (1234 bzw. geändertes Passwort) eingetippt hat
    kann man nun Befehle als user backupuser ausführen. Wir erstellen also nun einen RSA Key.
    Dies kann ein paar min dauern! Also keine Sorge! Bitte bei den Abfragen die anschließend
    kommen alle felder einfach mit Enter bestätigen! Keine Eingaben machen.

    Code
    ssh-keygen -t rsa


    Existiert schon ein entfernter PC auf dem man via SSH mit dem Benutzer arbeiten will kann
    man ihn mit folgendem Befehl auf den PC transferieren (nur Linux!). Die IP die am Ende
    steht ist dann die IP-Adresse vom "fremden" PC. Der Benutzer backupuser muss an diesem
    PC existieren.


    Code
    ssh-copy-id -i ~/.ssh/id_rsa.pub backupuser@192.168.1.30


    Nun wieder mit dem Benutzer abmelden, es geht mit den User pi weiter.
    Dafür einfach folgendes eingeben:


    Code
    exit


    Möchte man sich z.B. bei seinem SSH-Zugang etwas besser absichern kann man
    dies ebenfalls mit Zertifikaten tun. Eine gute Lösung ist es ein Zertifikat mit passphrase zu verwenden, und die Anmeldung via Passwort zu deaktivieren.

    Wie erstelle ich ein solches Zertifikat? Ich nutze dazu unter Windows puttygen.exe ( zu finden auf der Putty Downloadseite http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html )

    Eine kurze Anleitung:

    Puttygen starten und Generate auswählen

    Den Mauszeiger ein wenig bewegen um den Zufallskey zu erzeugen

    Als Key-Comment gebe ich immer den Benutzernamen ein z.B. backupuser

    Alle Keys exportieren, OPENSSH key, ssh.com key ... und auch den Key aus dem Fenster "Public key for pasting into OpenSSH authorized_keys file:" kopieren und in einer Datei speichern.

    Somit haben wir jetzt einen Benutzer, ein Passwort und 3 Dateien mit Schlüsseln.
    Diese Schlüssel sind natürlich private Schlüssel, das heißt ihr solltet diese nicht im
    frei in der Welt verteilen, sondern wie der Name schon sagt privat halten.

    Diese Schlüssel finden bei folgenden Punkten in diesem Tutorial verwendung:

    - Anmeldung via SSH
    - RSYNC Backup via SSH
    - Duplicati Backup via SSH


    2.7 Festplatten mounten

    Nun geht es an die externen Festplatten. Ich nutze NTFS formatierte Festplatten, damit ich im Zweifel mit jeder 0815 Windows-Büchse auf die Festplatten zugreifen kann falls ich mal schnell an die Daten muss oder der Pi über den Jordan gegangen ist. Damit der Pi mit NTFS Platten reden kann müssen wir ihm ein Paket installieren:


    Code
    sudo apt-get install ntfs-3g


    Erst einmal sollte man herrausfinden welche Platte wie heißt, das geht mit:


    Code
    sudo blkid

    Nun die UUIDs notieren (am sinnvollsten kopieren). Es handelt sich um die Geräte /dev/sdaX und /dev/sdaY . Die Zahlen sind die Nummer der Partitionen.
    Wenn nur eine partition existiert haben wir also sda1 und sdb1. Das Feld Label ist der Name der Festplatte den ich beim Formatieren unter Windows vergeben habe. Das macht es einfacher die Festplatte zu identifizieren.


    Nun erstellen wir zwei Verzeichnisse für die Festplatten


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


    Nun die Festplatten bei Autostart mounten, das geht so:

    fstab öffnen

    Code
    sudo nano /etc/fstab

    Folgenden Code einfügen (natürlich die passenden UUID eintragen)

    Code
    UUID=C2A83942A839366F   /media/USBHDD1   ntfs  defaults,errors=remount-ro 0       1
    UUID=FC68821B6881D534   /media/USBHDD2   ntfs  defaults,errors=remount-ro 0       1


    Nun ein Reboot damit die Platten gemountet werden.


    Code
    sudo shutdown -r now

    Nun sollten die beiden Platten eingehängt sein. Das kann man ganz einfach testen mit folgenden Befehlen:
    Sollten sich schon Ordner und Verzeichnisse auf den Festplatten befinden werden sie nun angezeigt.


    Code
    ls /media/USBHDD1/


    Code
    ls /media/USBHDD2/


    2.7.ALT Festplatten mounten (ACHTUNG ALTER STAND!!!)

    Die Festplatten werden über ihre Bezeichnung SDA1 und SDB1 gemountet.
    Das ist nicht der Beste weg, denn wenn z.B. SDA1 ausfällt, wird SDB1 automatisch
    SDA1 beim nächsten start. Zu einem späteren Zeitpunkt will ich die UUID auslesen
    und darüber sicherstellen, dass die richtige Platte gemountet ist. Bisher ist der
    einzige "Schutz" das die Ordner auf den Platten unterschiedlich heißen und somit
    nicht "falsch herrum" gesichert werden kann. Wer sich hier gut auskennt darf mir
    gern eine kleine Anleitung schreiben wie ich eine Platte Anhand der UUID mounten kann.
    Vielen Dank!


    Nun geht es an die externen Festplatten.
    Ich nutze NTFS formatierte Festplatten, damit ich im Zweifel mit
    jeder 0815 Windows-Büchse auf die Festplatten zugreifen kann falls
    ich mal schnell an die Daten muss oder der Pi über den Jordan gegangen ist.

    Damit der Pi mit NTFS Platten reden kann müssen wir ihm ein Paket installieren

    Code
    sudo apt-get install ntfs-3g


    Erst einmal sollte man herrausfinden welche Platte wie heißt, das geht mit:


    Code
    sudo fdisk -l


    Dort sollte eine Platte SDA1 heißen, und eine SDB1. Die Zahlen geben die Partitionen an, habt ihr als mehrere Partitionen kann es auch SDA2 usw geben.

    Nun erstellen wir zwei Verzeichnisse für die Festplatten


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

    Nun die Festplatten bei Autostart mounten, das geht so:

    fstab öffnen

    Code
    sudo nano /etc/fstab

    folgende Zeilen am Ende einfügen

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

    Nun ein Reboot damit die Platten gemountet werden.
    wer dem Code vertraut kann sich den Reboot sparen und die Platten direkt mounten:
       

    Code
    sudo mount -t auto /dev/sda1 /media/USBHDD1
    sudo mount -t auto /dev/sdb1 /media/USBHDD2


    2.8 Energiesparen

    Die USB-Platten laufen natürlich im 24/7 Betrieb. Wenn der Server nur für die Datensicherung genutzt wird laufen sie 99% des Tages unnötig.
    Mit dem Program HDPARM kann man Festplatten nach einer gewissen Zeit "schlafen" legen, und bei gebrauch werden sie automatisch geweckt.
    Ich habe die Erfahrung gemacht, dass sich nicht jede Festplatte wieder wecken lässt, dies hat vermutlich mit den Energiesparmodi der Platten zu tun.

    Zunächst müssen wir HDPARM installieren

    Code
    sudo apt-get install hdparm

    Anschließend die Config anpassen

    Code
    sudo nano /etc/hdparm.conf

    Am Ende der Datei wird einfach folgender Eintrag gemacht

    Code
    /dev/disk/by-uuid/AC20D71F20D6EF78 {
       spindown_time = 60
    }

    Wie man die UUID ausliest ist im Kapitel 2.7 Festplatten mounten beschrieben (blkid).
    Die Spindown Time sollte sinnvoll eingestellt werden. Die 60 steht nicht für 60 Sekunden, sondern lässt sich folgendermaßen ermitteln:

    spindown_time = Zahl * 5 Sekunden -> 60 * 5 Sek -> 300Sek -> 5min

    Die Spindown Time sollte nicht zu kurz gewählt werden, ein häufiges Starten und Stoppen der Platten wirkt sich auf die Lebensdauer aus.


    3. Samba einrichten

    Wenn man z.B. Windows-Rechner sichern möchte, oder einfach parallel zum Backup auch noch Netzwerkfreigaben erstellen möchte braucht man Samba. Samba stellt Netzwerkfreigaben bereit.


    3.1 Installation

    Für die Installation von Samba folgenden Befehl ausführen:


    Code
    sudo apt-get install samba samba-common-bin


    3.2 Config

    Anschließend die Samba-Config sichern (Better have your Backup!)


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


    Mittels folgendem Befehl kann die Config editiert werden:


    Code
    sudo nano /etc/samba/smb.conf


    Zunächst sollte eine Sicherheitsoption gesetzt werden.
    Dazu muss im Bereich Authentication die Zeile


    Code
    # security = user


    auskommentiert werden (# entfernen)

    Anschließend kann am Ende vom Dokument nun eine oder mehrere Freigaben erstellt werden
    Das Beispiel heißt "Backup" und hat als Kommentar "Backupordner fuer Backupuser"
    Der Ordner ist nur für den User backupuser freigeben, soll er für alle User freigegeben werden
    einfach @users eintragen, oder mehrere Usernamen durch Komma aufführen.
    Wichtig ist natürlich das auf existierende Ordner zugegriffen werden muss.
    Folgender Befehl erstellt den Ordner /backup/


    Zitat


    sudo mkdir /media/USBHDD1/backup


    Code
    [Backup]
    comment = Backupordner fuer Backupuser
    path = /media/USBHDD1/backup
    valid users = backupuser
    force group = users
    create mask = 0660
    directory mask = 0771
    read only = no


    Nachdem die Config bearbeitet ist muss der Samba-Server neu gestartet werden.


    Code
    sudo /etc/init.d/samba restart


    Nicht jeder User im System hat Zugriff auf die Samba-Freigaben. Es muss für Samba ein eigenes Passwort
    angelegt werden (kann aber das gleiche sein!). Dies geschiet via:


    Code
    sudo smbpasswd -a backupuser


    Nun kann das ganze ausgiebig getestet werden!

    Achtung unter Windows 8: Die Samba Freigabe macht Windows8 zu schaffen. Es gibt ein paar
    Dienste die laufen müssen damit auf Samba-Freigaben zugegriffen werden kann. Näheres verrät das
    Internet.


    4. Backup einrichten

    Anforderungen an mein Backup:

    - Inkrementell
    - Über das Netzwerk / VPN / Internet
    - Ausführliche Log-Files

    Beim Backup hatte ich mich für rsync entschieden, da es alle meine Anforderungen erfüllt und auf dem Raspberry Pi bereits vorinstalliert ist.
    Mit der Zeit habe ich auf duplicati umgeschwenkt, erst für die Clientsicherung, dann auch für die Server.

    Der Grund dafür war einfach:

    - Duplicati läuft, mit etwas aufwand, auf allen Clients (Windows, Linux, MacOS)
    - Duplicati verschlüsselt die Daten vor dem Übermitteln (Wir haben zwar nur vertrauenswürdige Ziele in diesem Projekt, aber das wäre nicht notwendig)
    - Duplicati hat einige Parameter für die Datenübertragung (z.B. Bandbreitenlimits, Dateiblockgrößen, Prioritäten, etc)
    - Duplicati hat ein einfaches GUI mit dem man sehr gut klar kommt und auf jedem beliebigen PC ein Backup wiederherstellen kann

    Achtung! Ab jetzt fahre ich zweigleisig! In den Kapiteln mit a) wird das Vorgehen mit RSYNC beschrieben, in den Kapiteln mit b) wird das
    vorgehen mit duplicati beschrieben. Duplicati braucht deutlich mehr Ressourcen als rsync, da es die Daten verschlüsselt und packt, und
    unter Linux nur mit Hilfe von mono ausgeführt werden kann. Ich habe die Leistung auf einem Raspberry-Pi NICHT getestet - Rückmeldungen erwünscht.


    4.1a rsync Installation

    Rsync ist unter Raspian bereits vorinstalliert. Falls es nicht der Fall ist oder nicht die neuste Version installiert ist:

    Code
    sudo apt-get install rsync


    4.2a rsync Lokales Backup mit Python Script "backup_lokal.py"

    Die Daten werden von USBHDD1/backup nach USBHDD2/backup_lokal kopiert

    Dieses Script hat folgende Aufgabe:

    - Logfile erzeugen welches Informationen über Start, Fehler, oder ein erfolgreiches Ende des Backups enthält
    - Rsync bis zu 3 mal (anpassbar) mit 10min Verzögerung zu starten um zeitlich begrenzte Fehler zu umgehen (z.B. 24h Disconnect)

    Die Parameter für Rsync sind in der Doku nachzulesen und können gern angepasst werden.


    Das Script kann einfach in das Verzeichnis des Users backupuser gelegt werden.
    Wenn es z.B. in die Zwischenablage kopiert wird, kann via SHH eine neue Datei geöffnet werden
    und die Datei so eingefügt werden.

    Dieser Code erstellt das Python File

    Code
    sudo nano /home/backupuser/backup_lokal.py

    Anschließend oberes Programm einfügen, mit Strg + X speichern.

    Jetzt kann das Backupscript getestet werden. Dazu sollten natürlich ein paar Daten im Backupverzeichnis sein.
    (Aber bitte nicht gleich 100GB, das geht eine ganze Weile!)

    Wenn ihr diesen Befehl eingebt wird das Script abgearbeitet. Es passiert keine Bildschirmausgabe, und es scheint
    als würde der Pi sich aufgehängt haben. Das liegt daran, dass ich die Bildschirmausgabe von rsync nicht aktiviert habe,
    da das script normalerweise in einem Cronjob läuft und deshalb niemand diese Ausgabe zu Gesicht bekommen wird.
    Zum Testen kann die rsync Zeile mit -v erweitert werden!

    Da es mit dem Backupuser ausgeführt werden soll melden wir uns wieder an

    Code
    su backupuser

    Und führen das Script aus

    Code
    python /home/backupuser/backup_lokal.py

    Anschließend melden wir uns wieder ab

    Code
    exit


    Wichtig! Damit das Script von einem Cronjob aufgerufen werden kann muss es ausführbar gemacht werden.
    Das geht mit folgendem Befehl:

    Code
    sudo chmod +x /home/backupuser/backup_lokal.py


    4.3a rsync Netzwerk Backup mit Python Script "backup_netzwerk.py"

    Die Daten werden von Pi#1 USBHDD1/backup nach Pi#2 USBHDD2/backup_netzwerk kopiert.
    (Und natürlich in die andere Richtung ebenfalls!)

    Dieses Script hat folgende Aufgabe:

    - Logfile erzeugen welches Informationen über Start, Fehler, oder ein erfolgreiches Ende des Backups enthält
    - Rsync bis zu 3 mal (anpassbar) mit 10min Verzögerung zu starten um zeitlich begrenzte Fehler zu umgehen (z.B. 24h Disconnect)


    Die Parameter für Rsync sind in der Doku nachzulesen und können gern angepasst werden.



    Das Script kann einfach in das Verzeichnis des Users backupuser gelegt werden.
    Wenn es z.B. in die Zwischenablage kopiert wird, kann via SHH eine neue Datei geöffnet werden
    und die Datei so eingefügt werden.


    Dieser Code erstellt das Python File

    Code
    sudo nano /home/backupuser/backup_netzwerk.py


    Anschließend oberes Programm einfügen, mit Strg + X speichern.


    Jetzt kann das Backupscript getestet werden. Dazu sollten natürlich ein paar Daten im Backupverzeichnis sein.
    (Aber bitte nicht gleich 100GB, das geht eine ganze Weile!)


    Wenn ihr diesen Befehl eingebt wird das Script abgearbeitet. Es passiert keine Bildschirmausgabe, und es scheint
    als würde der Pi sich aufgehängt haben. Das liegt daran, dass ich die Bildschirmausgabe von rsync nicht aktiviert habe,
    da das script normalerweise in einem Cronjob läuft und deshalb niemand diese Ausgabe zu Gesicht bekommen wird.
    Zum Testen kann die rsync Zeile mit -v erweitert werden!


    Da es mit dem Backupuser ausgeführt werden soll melden wir uns wieder an

    Code
    su backupuser


    Anschließend führen wir das Script aus.
    Achtung! In diesem Fall wird eine SSH Verbindung aufgebaut! Es gibt einmal die Abfrage ob der Host vertraueswürdig ist!
    Diese Abfrage mit "Y" bestätigen.

    Code
    python /home/backupuser/backup_netzwerk.py


    Anschließend melden wir uns wieder ab

    Code
    exit


    Wichtig! Damit das Script von einem Cronjob aufgerufen werden kann muss es ausführbar gemacht werden.
    Das geht mit folgendem Befehl:

    Code
    sudo chmod +x /home/backupuser/backup_netzwerk.py


    4.4a rsync Log-Files

    Ich nutze die Python Scripte für die Backups um ein paar weitere Infos wie den Startzeitpunkt des Backups, einen Fehler, oder das Erfolgreiche Ende zu protokollieren. Diese Logfiles werden im gleichen Ordner wie die Python-Scripte angelegt, also gibt es in diesem Beispiel folgende Log-Files:

    /home/backupuser/backup_lokal.log
    /home/backupuser/rsync_lokal.log
    /home/backupuser/backup_netzwerk.log
    /home/backupuser/rsync_netzwerk.log

    Öffnen kann man sie z.B. so:

    Code
    nano /home/backupuser/backup_lokal.log


    Ein solches Log-File sieht in etwa so aus:




    4.5a Cronjobs

    Damit die Backups regelmässig ausgeführt werden bieten sich Cronjobs an. Diese stellen eine Art Aufgabenplaner dar, und können ziemlich gut für unsere Backups genutzt werden. Ich nutze die Cronjobs für den User, da ich die Scripte nicht als Root ausführen möchte. Also melden wir uns wieder als backupuser an. Passwort 1234 oder falls geändert -> dieses nutzen.


    Code
    su backupuser

    Nun kann der Crontable geöffnet werden


    Code
    crontab -e

    nach der Beschreibung ein wenig Luft lassen und am Ende folgende Einträge einfügen


    Code
    0 1  *   *   *     python /home/backupuser/backup_netzwerk.py
    0 8  *   *   *     python /home/backupuser/backup_lokal.py

    In diesem Fall wird das Netzwerk Backup um 0 Minuten, um 1Uhr, jeden Tag im Monat, jeden Monat im jahr, jeden Tag in der Woche ausgeführt, das Lokale Backup gegen 8Uhr. Diese Zeiten sind natürlich variabel. Wichtig ist das in dem Moment wo ein Backup durchgeführt wird niemand auf die Daten zugreift und diese verändert. Ich empfehle die Zeit für das Netzwerkbackup in die Nacht zu legen damit man das Internet nicht für sich bremst (der Upload geht natürlich in die Knie!) Zu beachten ist natürlich die Zeit der Zwangstrennung! Ich würde sie kurz vor das Backup legen! Man könnte nun für die Woche und das Wochenede unterschiedliche Zeiten festlegen (über den Parameter Wochentag). Auf die Details will ich nicht eingehen, die Hilfe ist hier sehr aussagekräftig.

    Die beiden Cronjobs sollten sich nicht überschneiden, da der Pi nicht wirklich der performanteste ist.
    Ich empfehle die Backups einmal direkt laufen zu lassen, und erst nachdem große Datenmengen gesichert wurden diese regelmässig
    durch Cronjobs inkrementell zu sichern. Das Backup schafft bei meinem Setup 1,2GB-1,8GB pro Stunde lokal zu sichern.
    Man kann eine Überschneidung ganz einfach ausschließen indem man sich ein Script erstellt, welches die beiden Python-Scripte nacheinander
    aufruft und nur noch einen Cronjob anlegt.

    Das Script könnte z.B. backup.py heißen und so aussehen:


    Code
    #!/usr/bin/env python
    import os
    
    
    # Erst Backup via Netzwerk, dann Lokal
    os.system('/home/backup_aldingen/backup_netzwerk.py')
    os.system('/home/backup_aldingen/backup_lokal.py')

    Natürlich muss auch das ausführbar gemacht werden

    Code
    chmod +x backup.py

    Der Cronjobeintrag muss dann natürlich abweichend so aussehen:

    Code
    0 1  *   *   *     python /home/backupuser/backup.py

    Falls der Cronjob zu einem falschen Zeitpunkt ausführt wird mal die aktuelle Uhrzeit und das Datum kontrollieren


    Code
    date


    Ggf. kann man die Zeitzone anpassen (Achtung mit nem Root-User):


    Code
    sudo dpkg-reconfigure tzdata


    Anschließnd wieder zum User pi zurückkehren


    Code
    exit


    4.6a rsync Sicherung der Clients

    Die automatische Sicherung via Cronjobs funktioniert, wenn die Daten einmal auf dem Pi gesichert wurden werden sie automatisch weiter gesichert.
    Jetzt müssen aber erst einmal Daten auf den Pi kommen. Für unseren Bisherigen Test haben wir via Samba-Freigabe einfach Dateien in den Ordner backup kopiert. Das ist aber zu mühselig, und setzt vorraus das man als User an sein Backup denkt. Deshalb automatisieren wir auch diesen Schritt.


    4.6.1a rsync Linux Client

    Mit einem Linux Client kann man Rsync via SSH nutzen, und kann sich das backup_netzwerk.py Script entsprechend anpassen.
    Man kann sich nun aussuchen ob der Backupvorgang vom Pi aus geführt wird (Daten holen) oder vom Client aus (Daten senden).

    Bitte beachten: Das Beispiel ist so ausgelegt das nur ein Ordner gesichert wird. Man könnte es so ausweiten, dass vor dem Backup alle relevanten Dateien und Ordner in einem Ordner (TMP) gesammelt und gemeinsam archiviert werden.


    4.6.2a rsync Windows Client

    Mit einem Windows Client kann man Robocopy nutzen. Es hat ähnliche Eigenschaften wie rsync.
    Mit folgendem Script wird eine Sicherung von einem Windows Client auf ein Netzlaufwerk gemacht.
    Zu beachten ist: Das Netzlaufwerk muss verbunden sein bevor der Backupvorgang funktioniert.
    Man könnte vermutlich auch Benutzername und Passwort übergeben, das halte ich in einem Script aber für
    nicht angebracht!

    Bitte beachten: Das Beispiel ist so ausgelegt das nur ein Ordner gesichert wird. Man könnte es so ausweiten, dass vor dem Backup alle relevanten Dateien und Ordner in einem Ordner (TMP) gesammelt und gemeinsam archiviert werden.

    Dieses Script bietet keine Log-Funktionen! Es findet ausschließlich eine Ausgabe im Terminal statt!

    Das Script kann einfach als backup.bat gespeichert und ausgeführt werden!

    Zu Ändern sind nur die zwei Pfäde Quelle und Ziel! Bitte die Kommentare in den Zeilen darüber beachten!


    4.6.3a rsync MacOS Client

    Wird erst in einiger Zeit fertig gestellt - Mac OS Client steht zur Zeit nicht zum Testen zur Verfügung

    Bitte beachten: Das Beispiel ist so ausgelegt das nur ein Ordner gesichert wird. Man könnte es so ausweiten, dass vor dem Backup alle relevanten Dateien und Ordner in einem Ordner (TMP) gesammelt und gemeinsam archiviert werden.


    4.7a Zugriff auf gesicherte Dateien

    Jetzt haben wir die Backups eingerichtet, und sie werden regelmässig autmatisch ausgeführt.
    Das ist schön und gut... aber kommen wir an die Daten auch wieder ran? Was bringt die beste Backupstrategie
    wenn man nicht an die zu sichernden Daten kommt?

    Also muss man das testen!

    Man kann z.B. via SSH gucken ob die Dateien und Ordner vorhanden sind


    Code
    ls /media/USBHDD2/backup_lokal/

    Oder man macht eine Samba-Freigabe auf den Ordner (Sicherheitshalber nur Read-Only!)

    Code
    [Backup_Lokal]
    comment = Backupordner Lokal
    path = /media/USBHDD2/backup_lokal
    valid users = backupuser
    force group = users
    create mask = 0660
    directory mask = 0771
    read only = yes

    Und ein weiterer Test ist den Pi herrunter zu fahren und anschließend die Festplatte an einem Windows PC zu öffnen und zu schauen ob man Zugriff auf die Dateien und Ordner hat.

    Hier der Code für den sauberen Shutdown:

    Code
    sudo shutdown -h now


    4.1b duplicati Installation

    Duplicati gibt es für diverse Betriebssysteme hier: http://www.duplicati.com/news/duplicati134available

    Die Installation ist durch den Wizard ziemlich selbsterklärend.
    Wenn ihr alles in Standardeinstellungen installiert läuft Duplicati ab jetzt immer und startet die Sicherungen
    selbstständig, wenn diese so angelegt wurden.

    Details zur Installation in der Komandozeile folgen.


    4.2b Duplicati Backup einrichten

    Wir richten also mal ein Backup über den Wizard ein... Zum Start wählen wir also aus
    "Eine neue Sicherung einrichten"

    Vergeben einen sinnvollen Namen (z.B. PC-Name + Benutzername)

    Auswahl der zu sichernden Dateien, ich wähle immer die Benutzerdefinierte Ordnerliste, es können beliebig viele Ordner ausgewählt werden.

    Sicherung mit einem Kennwort schützen. Ich nutze automatisch generierte Kennwörter in Keepass.
    Wichtiger Gedanke! Schön wenn man die Keepass-Datenbank ins Backup mit einbezieht, das Passwort zum Wiederherstellen sollte aber entweder bekannt sein oder anderweitig nochmals aufgehoben werden (Ausdrucken, weitere Backups, Datenträger...)

    In unserem Beispiel sichern wir via SSH auf unseren Raspi, es gibt aber diverse Einstellmöglichkeiten für das Backup, z.B. auch in die Cloud.

    Jetzt kommen die Einstellungen.

    Server: IP unseres PI also 192.168.1.20
    Pfad: z.B. /media/USBHDD1/BACKUP/PC
    Benutzername: backupuser
    Passwort: Passwort des Backupusers (Oder Passphrase für Schlüsseldatei falls Anmeldung via Passwort gesperrt ist)
    Schlüsseldatei: Zertifikat das wir mit Puttygen erstellt haben, es ist der openssh Schlüssel der hier verwendet wird.
    Port: 22 - Außer SSH hört bei euch auf einen anderen Port
    Verbindung Testen - Wenn alles klappt sollte eine OK Meldung erscheinen.

    Erweiterte Einstellungen, folgende Haken bitte setzen damit die nachfolgenden Einstellungen vorgenommen werden können.

    Zeitplan: Ich mache Täglich um 20Uhr Backups, da dort die Wahrscheinlichkeit am Höchsten ist das mein PC eingeschaltet ist. Ich glaube verpasste Backups werden nicht nachgeholt, bin mir aber nicht sicher.

    Strategie für die Sicherung:

    Hier muss jeder selbst wählen.
    Ich mache rein Inkrementelle Backups, mit der Gefahr die dadurch einhergeht.
    Es ist aber nicht praktikabel jeden Monat das Komplette Backup nochmal durchlaufen zu lassen (wir sprechen bei einem PC von 120GB -> Und diese dann nebenher per VPN auf einen anderen Pi zu sichern dauert... ewig.)

    Ich empfehle euch die Standardeinstellung zu nutzen und jeden Monat ein neues Full-Backup anzulegen.

    Hier stellt man ein wie viele alte Backups vorgehalten bleiben bis sie gelöscht werden.

    Hier können Limits eingestellt werden, was gerade bei Backups über das Internet sinnvoll sein kann,
    um nicht die ganze Bandbreite zu fressen oder schwache Netzwerke oder PCs nicht zu belasten.

    Die Größe eines Sicherungsvolumens ist auch nicht unteressant:

    Je kleiner das Volumen ist, desto besser ist es für das Backup via Internet geeignet, da im Fehlerfall
    nur kleine Datenmengen neu geladen werden müssen.

    Im Lokalen Netzwerk können diese gern größer gewählt werden.

    Nachteil: Je kleiner die Pakete, desto länger dauert ein Auflisten der Pakete und ein Restore.

    Jetzt geht es ein wenig in die Tiefe. Wenn man über das Internet sein Backup fährt ist die Option asynchronus-upload praktisch. Ist dieser Haken nicht gesetzt läuft der Ablauf wie folgt: Backup-Paket in TMP-Ordner zusammenstellen, Hochladen, zusammenstellen, hochladen. Mit dem Haken passiert dies parallel und es wird ziemlich permanent hochgeladen.

    Hat man eine unsichere Verbindung (Eine die öfters mal abbricht oder ausfällt) empfehle ich den Haken bei list-verify-uploads zu setzen. Dies kostet ziemlich viel Zeit, da die Daten hochgeladen und dann nochmal geprüft werden, aber ich hatte schon öfters Probleme damit das wenn ein Teilarchiv defekt ist, man an bestimmte Dateien nicht mehr kommt. Sehr ärgerlich!

    So nun ist alles geschafft! Eine kleine Zusammenfassung, und praktischerweise unter Command Line auch ein Beispiel für die Komandozeilenversion der zuvor eingerichteten Sicherung.

    Wenn der Haken "Sicherung jetzt Starten" gesetzt ist, wird gleich im Anschluss das Backup gestartet.

    Im Duplicati-Statusfenster (erreichbar über das Tray-Icon) gibt es eine Übersicht über die Sicherungen.


    4.2b Duplicati Zugriff auf Dateien

    So jetzt kommt der wichtigste Punkt beim Backup, den viele vernachlässigen.
    Ich muss im Falle eines Falles auch an alle meine Dateien kommen.

    Wie funktioniert das bei Duplicati?

    Fall1: Es wurde nur eine Datei / ein Ordner gelöscht.

    Im Duplcati Statusfenster den Duplicati Assistenten öffnen

    Dateien aus einer Sicherung wiederherstellen

    Die Sicherung auswählen

    Den Stand auf den Wiederhergestellt werden soll auswählen (Hier gibt es nur einen Stand von meinem Demobackup)

    Den Zielordner auswählen. Sollten nur einzelne Elemente der Sicherung wiederhergestellt werden den Haken bei "nur die unten ausgewählten Elemente wiederherstellen" setzen. Das ganze kann je nach Sicherungsgröße ziemlich lange dauern, da erst einmal alle Dateien aufgelistet werden.

    Achtung! Der Zielordner sollte IMMER ein anderer als der Ordner sein in dem die Originaldateien liegen die gesichert werden. Ich mache immer einen Ordner C:\Restore für diesen Zweck.

    Anschließend bekommen wir eine kleine Zusammenfassung was gemacht wird, und können den Vorgang starten.


    Fall2: Das Gerät das gesichert wurde ist defekt - nicht mehr verfügbar

    Dazu ist der einfachste Weg folgender:

    Auf den Backupserver zugreifen und die Duplicati-Sicherungsdateien auf z.B. eine externe Festplatte kopieren.

    Im Duplcati Statusfenster den Duplicati Assistenten öffnen

    Dateien aus einer Sicherung wiederherstellen

    Dateien Direkt wiederherstellen

    Datei-Basierend auswählen

    Den Stand auf den Wiederhergestellt werden soll auswählen (Hier gibt es nur einen Stand von meinem Demobackup)

    Den Zielordner auswählen. Sollten nur einzelne Elemente der Sicherung wiederhergestellt werden den Haken bei "nur die unten ausgewählten Elemente wiederherstellen" setzen. Das ganze kann je nach Sicherungsgröße ziemlich lange dauern, da erst einmal alle Dateien aufgelistet werden.

    Achtung! Der Zielordner sollte IMMER ein anderer als der Ordner sein in dem die Originaldateien liegen die gesichert werden. Ich mache immer einen Ordner C:\Restore für diesen Zweck.

    Anschließend bekommen wir eine kleine Zusammenfassung was gemacht wird, und können den Vorgang starten.


    5. Apache einrichten

    Für eine einfache Diagnose des Backupverlaufs habe ich einen Apache-Server aufgesetzt.
    Mittels einer PHP-Seite werden relevante Informationen wie z.B. die Log-Files oder der Status der Festplatten auf jedem
    Gerät mit einem Browser dargestellt.


    5.1 Apache Installation

    Die Installation des Apache-Servers ist sehr schnell passiert:


    Code
    sudo apt-get install apache2

    Das Ergebnis kann sofort getestet werden. Einfach in den Browser die IP-Adresse des Pi eingeben, und
    es sollte eine HTML Seite öffnen die einem sagt das alles geklappt hat!


    5.2 PHP Installation

    Die PHP-Installation ist genau so schnell erledigt wie die des Apache-Servers:


    Code
    sudo apt-get install php5

    Zum Testen ob PHP läuft kann eine phpinfo.php erstellt werden.


    Code
    sudo nano /var/www/phpinfo.php


    Folgender Code kommt in die PHP-Datei:

    PHP
    <?php phpinfo(); ?>

    Datei mit STRG+X speichern + schließen.

    Nun die Seite im Browser öffnen:


    Code
    http://IP_DES_PI/phpinfo.php


    5.3 Diagnose_Backup.php

    Nachfolgendes PHP-Script bietet eine kleine Diagnosemöglichkeit für den Backupserver.
    Es zeigt folgende Informationen an:

    Die Inhalte der Log-Files (Fehler sind rot markiert)
    Ob die Festplatten gemountet sind

    Das ganze ist noch in der Anfangsphase, ich will noch ein paar mehr Funktionen einbringen mit der Zeit... geplant ist folgendes, ob
    man es alles umsetzen kann steht aber noch in den Sternen:

    - Anzeige des letzten erfolgreichen Backups
    - Anzeiges des letzten fehlerhaften Backups
    - Restart-Button für den Pi (vllt. etwas heikel, will Sudo nicht via PHP ausführen können)
    - Manuelles anstarten eines Backups (Button)
    - Anpassen der Crontabs um Backupzeiten zu verändern
    - Download von Backups (ggf. Archiv) vllt. mit Auswahl nach Unterordnern etc.
    - Eine rudimentäre Komandozeile (Ohne Sudo!)


    Das oben gezeichte Script kann als Index.php in das Verzeichnis /var/www gelegt werden. Somit wird diese Seite automatisch als Startseite geöffnet wenn die IP-Adresse des PI in den Browser eingegeben wird.

    Zunächst müssen wir aber die index.html von der Apache installation löschen


    Code
    sudo rm /var/www/index.html

    Dann erstellen wir die neue index.php und fügen obriges Script ein:


    Code
    sudo nano /var/www/index.php

    Speichern mit Strg + X und anschließend testen ob es funktioniert hat.

    Wenn keine Log-Files angezeigt werden kann es daran liegen, dass sie nicht existieren.
    Die aktuelle Uhrzeit und der Status der Festplatten sollte aber immer angezeigt werden.


    Für Fragen oder Anregungen stehe ich natürlich zur Verfügung!

    Grüße

    Marcel