Posts by 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.

    Hallo Ciprian,


    ich kann Dir leider nicht ganz genau folgen.


    Wenn das Script gestartet wird, dann macht es das Backup und wenn es fertig ist ist das Script beendet. Oder möchtest Du das Script beenden bevor das Backup fertig ist?


    Grüße


    Marcel

    Ich werfe mal Tinkerforge in den Raum. Damit lassen sich Stepper steuern, direkt über den PI mit Python, C und was immer man will.


    Grüße


    Marcel

    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

    Hallo!


    Danke für die Blumen und vor allem für das Feedback!


    Ich muss den Beitrag nochmal ein wenig anpassen, Fehler wie diesen hab ich noch ein paar Gefunden!
    Es liegt daran, dass ich öäü in den Kommentaren verwendet habe...


    Grüße


    Marcel


    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.

    Ich hab es im Beitrag zum Editor schonmal erwähnt, und werd es hier einfach auch nochmal machen.


    Der Editor der im Forum aktiv war (Ich weis nicht wie lang, bin ja grad erst ne Weile hier) wurde deaktivert, da er einige Fehler aufwies. Nun gibt es den mutmaßlichen Standardeditor, der auch noch in seiner Breite eingeschränkt wurde weil Firefoxuser Probleme mit dem seitlichen Scrollen hatten (ich auch). Nun sieht es komisch aus wenn man auf 27" bei ner riesen Auflösung nen 200px. breiten Editor hat und der Rest Bildschirm ungenutzt durch die Gegend fährt... (Ja ich weis das man ihn aufziehen kann, aber ich will das nicht jedesmal machen müssen... man ist ja faul)


    Daher mein Vorschlag:


    Dieses Board unterstützt mit Sicherheit mehrere Editoren.
    ich kenne es aus diversen Foren, dass es drei Editoren zur Auswahl gibt, und der Lieblingseditor vom Admin (Der mit den wenigsten Fehlern) der Standard-Editor ist.
    Jeder User kann aber für sich im Kontrollzentrum festlegen welchen der Editoren er nutzen kann.


    Somit wäre jedem geholfen:


    Firefoxuser mit Scrollbalkenproblem können es mit anderen Editoren probieren
    Ich muss meinen Beitrag nicht auf 1/10 meines Bildschirms verfassen
    Wenn ein Editor buggy ist kann man halt wechseln


    Grüße


    Marcel

    Passt die GPIO Nummer zur Einstellung GPIO.BOARD?


    Es gibt ja zwei Zählweisen der GPIO!


    Außerdem empfehle ich dir die Pullup oder Pulldown-Widerstände der GPIO zu aktivieren, damit du ein definiertes Signal bekommst!


    Grüße


    Marcel

    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 http://www.forum-raspberrypi.d…y-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



    [hr]
    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


    [hr]

    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



    [hr]


    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





    [hr]



    2. Raspberry Pi - Installation



    [hr]


    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.


    [hr]


    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)





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


    [hr]

    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.


    [hr]

    2.4 Updates


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



    Code
    sudo apt-get update


    [hr]


    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!)




    [hr]


    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…atham/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


    [hr]


    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



    [hr]


    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.


    [hr]



    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.


    [hr]


    3.1 Installation


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



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


    [hr]


    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/



    Quote


    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.




    [hr]



    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.




    [hr]


    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


    [hr]


    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


    [hr]


    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


    [hr]


    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:




    [hr]

    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



    [hr]


    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.


    [hr]


    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.


    [hr]


    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!




    [hr]


    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.


    [hr]


    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


    [hr]


    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.


    [hr]


    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.



    [hr]


    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.




    [hr]


    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.


    [hr]


    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!


    [hr]


    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



    [hr]


    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.





    [hr]



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


    Grüße


    Marcel