Beiträge von Alti

    Hallo zusammen,

    Ich hatte mich schon recht früh mit dem Booten ohne SD Karte beschäftigt, da mein Pi3 Fileservice und Backup Prozesse im Netz bereit stellt. Bekannter Massen ist die Lebenszeit einer SD begrenzt und abhängig von den Zugriffen.
    Meine erste (erfolgreichen) Versuche waren im August 2017. Leider gab es noch zu viele Seiteneffeckte, wie Speicher nich voll erkannt, deutlich erhöhte Last und Temperatur, etc., dass es mir für einen Serverbetrieb zu riskant war.
    Also hatte ich dann den Bootprozess weiter über die SD Karte gemacht und Root war auf der Platte (eine PiDrive).
    Nun da das USB Booting im regulären Image ist, habe ich einen neuen Anlauf unternommen.

    Nun zu meiner Frage:
    Seit ich die SD Karte entfernt habe, läuft der Pi3 mit einer Dauerlast von 0,2 von 5,0. Außerdem blinkt permanent die Grüne LED, vermutlich weil die SD Karte gesucht wird. Möglicherweise ist diese permanente Suche auch der Grund für die Grundlast.

    Wie kann ich dem Pi3 beibringen, das er keine SD Karte hat und auch keine bekommen wird. Bzw. wie kann ich die Abfrage nach der Karte stoppen?
    Oder weis jemand den Grund für die Grundlast des PI3?


    Backup ist ein wichtiges Thema und deshalb wollte ich mir auch mal Deinen Code ansehen. Da Du aber leider keinerlei Einrückungen im Code hast um die Struktur leichter lesbar zu machen habe ich gleich wieder aufgegeben.

    So wie ich es ohne Deinen Code gelesen zu haben verstehe kann man auch alles mit raspiBackup und einem angepassten WrapperScript dazu erschlagen ;)

    Hallo framp,
    Kompliment für Dein Werk.
    Ich denke die Abgrenzung zu meinem Script und auch der Grund, warum ich mich selber daran gegeben habe etwas zu schreiben, ist, dass ich ein tägliches Backup mit vertretbaren Laufzeiten haben wollte, so dass ich maximal 24 Stunden verliere und ich nicht jeden Tag im Hintergrund der Backupprozess läuft. Meine Platten sind nicht partitioniert um flexibel zu bleiben. Damit würde ich beim Partitionsbackup die 1.5TB auf einmal sichern müssen und mit Kompression würde das 6 Tage laufen (Erfahrungswert mit einem Pi3).

    Nicht desto trotz werde werde ich Dein Backup nutzen um mein Boot - und Root - Verzeichnis als Image zu sichern. Da mein Pi ohne SD Karte über eine Platte läuft, habe ich zwar nicht die Gefahr einer crashenden Karte, aber you never know :cool: .

    PS: Da wohl einiges nicht so deutlich war habe ich den Text oben nochmal etwas bearbeitet.

    [font="Tahoma, sans-serif"]Hallo, hier möchte ich euch mein (inzwischen) kleines Projekt vorstellen.[/font]
    [font="Tahoma, sans-serif"] [/font]
    [font="Tahoma, sans-serif"]1. Hintergrund[/font]
    [font="Tahoma, sans-serif"] [/font]
    [font="Tahoma, sans-serif"]1.1 Gegebenheiten[/font]
    [font="Tahoma, sans-serif"]Ich habe ein Heimnetz mit 7 Windows - Rechnern, einen RPi3 als Fileserver mit 1,5 TB mit Samba hinter einer Fritz.Box und Benutzer die auch mal unüberlegt klicken. Glücklicher Weise bisher ohne größere Schäden. Das war auch Ausgangspunkt der Idee.[/font]
    [font="Tahoma, sans-serif"] [/font]
    [font="Tahoma, sans-serif"]1.2 Entwicklung der Idee[/font]
    [font="Tahoma, sans-serif"]Systeme wiederherstellen nach Virusbefall ist nervig und zeitraubend aber überschaubar. Anders sieht es bei Ransomware aus. Wenn einer die Maleware runtergeladen hat, werden alle Daten verschlüsselt, inkl. aller Filme, Videos und Fotos die halt auch unwiederbringlich sind. Einzig durch Backups kann man sich zurzeit schützen. Backups sind aber auch nervig, besonders wenn man sie immer wieder manuell durchführen muss, denn automatische Backups werden gleich mit verschlüsselt, - dachte ich. [/font]
    [font="Tahoma, sans-serif"]Deshalb war meine erste Idee über den Pi per GPIO eine Steckdose zu schalten, die eine Externe Festplatte für den Backup Prozess einschaltet und danach wieder abschaltet (nach dem unmount). Denn eine nicht laufende Platte kann nicht verschlüsselt werden, so der Gedanke. Damit wollte ich das abkoppeln der externen Festplatte ersetzen. [/font]
    [font="Tahoma, sans-serif"]Als nächstes musste ich mich um einen effektiven Vierenschutz für den Pi kümmern, damit nicht auch der Pi angegriffen oder infiziert wird. Denn ich wusste, es gibt inzwischen auch schon einige Vieren für Linux. Das Finden eines effektiven Vierenschutzes gestaltete sich schwieriger als gedacht, nein es war/ist unmöglich...[/font]
    [font="Tahoma, sans-serif"]Bei der Recherche und dem lesen in den Foren musste ich feststellen, dass es eigentlich keine Vierenschutzsoftware für den PI gibt, denn der Pi ist (noch) immun gegen Viren (weitestgehend).[/font][font="Tahoma, sans-serif"] Ich hoffe ich führe das jetzt richtig aus: [/font][font="Tahoma, sans-serif"]Die meiste Schadsoftware wird auf Machinenebene programmiert, d.h. sie läuft nur auf bestimmten Prozessorfamilien in Verbindung mit bestimmten Betriebssystemen (Intel & AMD => Windows oder Linux). Da sich aber (bisher) keiner für die ARM Prozessoren interessiert hat, weil die PIs in ihrer Nutzung, Konfiguration und Installation zu heterogen sind und nicht unbedingt einen konventionellen Internetzugang (über Browser) haben oder nutzen, ist es wohl auch kein lohnendes Angriffsziel.[/font]
    [font="Tahoma, sans-serif"]Damit schrumpften rapide die Anforderungen an das Projekt. Denn wenn der PI nicht angreifbar ist und somit unsichtbar für Schadsoftware, dann ist auch eine Platte, die nur der PI kennt auch sicher vor der Schadsoftware. Somit kann ich mir auch das Abkoppeln der Platte sparen. Also klemmte ich noch eine große Platte an den PI und suchte nach einer Backupmöglichkeit. Es war klar das es ein Inkrementellbackup sein müsste, denn bei einer Spiegelung oder Update Prozess, hätte der PI die verschlüsselten Dateien gleich mitgespiegelt. Mit dem incremental backup würde zwar das Script im Falle einer Vollverschlüsselung inkrementell ein quasi Vollbackup machen, da alle Dateien verändert wurden, aber die unverschlüsselten Daten stehen mir weiter zur Verfügung durch die Vorangegangenen Backups.[/font]
    [font="Tahoma, sans-serif"]Als ich dann unter https://wiki.ubuntuusers.de/Skripte/inkrementelles_Backup/ ein Backupscript gefunden hatte, das alles in allem auch ganz gut funktionierte, war das Projekt als Projekt zunächst gestorben.[/font]
    [font="Tahoma, sans-serif"]Das änderte sich als ich die ersten Performance-Daten sah. Durch den USB2.0 und auch möglicherweise durch die Prozessorleistung braucht der PI 1 Stunde um 10 GB zu sichern, das heißt 150 Stunden bzw. mehr als 6 Tage bei 1.5TB. Bei einem täglichen Backup müsste immer wieder bei den rotierenden Vollbackups manuell eingreifen, den cronjob löschen usw. Also auch wieder nicht vollautomatisch. Dazu kam dann noch das mein PI eine Leerlauftemperatur von 48°C hatte und beim Backup-Prozess auf 65°C stieg. Sobald ein zweiter Backup Prozess dazu kam stieg die Temperatur auf 79°C in spitzen bis 81°C. Das bedeutete wenn ich mal das manuelle Abschalten des cronjobs vergesse und er wärend des Backups (6Tage) ein 3. Mal startet grille ich meinen PI. (Um das Temperaturproblem habe ich mich nebenbei auch gekümmert (siehe unten ... kommt noch).)[/font]
    [font="Tahoma, sans-serif"]So ist folgende Script entstanden basierend auf dem oben genannten.[/font]
    [font="Tahoma, sans-serif"] [/font]
    [font="Tahoma, sans-serif"]2. Das Script[/font]
    [font="Tahoma, sans-serif"]2.1 Was kann das Script?[/font]
    [font="Tahoma, sans-serif"]- täglich aktuelle Backups mit überschaubaren Laufzeiten[/font]
    [font="Tahoma, sans-serif"]- Kaskadierendes Vollbackup einer Platte "beliebiger" Größe mit [/font]
    [font="Tahoma, sans-serif"]- inkrementell Backup über einen einstellbaren Zeitraum mit[/font]
    [font="Tahoma, sans-serif"]- anschließendem wegsichern der Sicherung und erneutes Vollbackup.[/font]
    [font="Tahoma, sans-serif"]- Interne Mail mit Backup Report[/font]
    [font="Tahoma, sans-serif"]- Backup chain[/font]
    [font="Tahoma, sans-serif"]- Kompression des Archivs[/font]
    [font="Tahoma, sans-serif"]- "Loadkontrolle" [/font]
    [font="Tahoma, sans-serif"]- einfach einstellbar[/font]
    [font="Tahoma, sans-serif"] [/font]
    [font="Tahoma, sans-serif"]2.2 Was kann das Script (noch) NICHT?[/font]
    [font="Tahoma, sans-serif"]- prüfen, ob genug Platz auf der Backupplatte ist.[/font]
    [font="Tahoma, sans-serif"]- löschen der überholten Bachups.[/font]
    [font="Tahoma, sans-serif"]- kontrollieren ob bereits eine Instanz des Scripts läuft.[/font]
    [font="Tahoma, sans-serif"]- den Report an eine externe eMail Adresse senden.[/font]
    [font="Tahoma, sans-serif"] [/font]
    [font="Tahoma, sans-serif"]2.3 Funktionsweise[/font]
    [font="Tahoma, sans-serif"]Es ist mein erstes Bash Script, deshalb bitte ich um Nachsicht, wenn zum Beispiel das Quoting oder andere Syntax nicht optimal ist. Außerdem nochmal der Hinweis das es auf einem Script von [font="Tahoma, sans-serif"] [/font]https://wiki.ubuntuusers.de/Skripte/inkrementelles_Backup/[font="Tahoma, sans-serif"] basiert.[/font][/font]
    [font="Tahoma, sans-serif"][font="Tahoma, sans-serif"]Gedacht ist das Script für den täglichen Gebrauch, einzutragen in der crontab. Damit gehen einem nur die Änderungen und neuen Dateien maximal der letzten 24 Stunden verloren.[/font][/font]
    [font="Tahoma, sans-serif"]Im Einstellungsbereich werden in zwei Arrays die Verzeichnisse, die einzeln gesichert werden sollen und die Tage bis zum nächsten Vollbackup abgelegt. Die Arrays werden nacheinander abgearbeitet. Das heißt die erste Zahl bezieht sich auf das erste Verzeichnis. Wenn keine Zahl eingetragen ist (wie bei meinen letzten 3 Verzeichnissen) wird das Defaultvalue genommen. Somit kann man bei den Benutzerverzeichnissen ein monatliches Vollbackup anstoßen, während Videos (ich mache da nicht so viele) jedes halbe Jahr komplett gesichert werden und somit die Deltas und das alte Vollbackup überflüssig werden. [/font]
    [font="Tahoma, sans-serif"]Bei den Verzeichnissen kann man auch als letzten Eintrag ein "" eintragen, dann wird das komplette Ober- bzw. Elternverzeichnis gesichert OHNE die bereits gesicherten Verzeichnisse aus dem Array.[/font]
    [font="Tahoma, sans-serif"]Eine Schleife arbeitet die Arrays ab und erstellt aus den RAW-Verzeichnissen die Verzeichnisse die es benötigt. Wenn das Verzeichnis leer ist wird ein Vollbackup gemacht ist. Wenn die Anzahl der Tage erreicht ist wird der gesamte Backupordner verschoben und ein neues Backup wird erstellt.[/font]
    [font="Tahoma, sans-serif"]Das Script überprüft ob bereits ein Vollbackup durchgeführt wurde um die Gesamtlaufzeit des Scriptes überschaubar zu halten. [/font]
    [font="Tahoma, sans-serif"]Wenn bereits ein Vollbackup durchgeführt wurde, wird trotz Erreichen der Maximaltage ein weiteres Inkrementellbackup gemacht.[/font]
    [font="Tahoma, sans-serif"]Wenn noch gar kein Backup erstellt wurde wird dieses Backup für diesen Tag übersprungen. Das bedeutet, dass dieses Script auch beim ersten Start vollautomatisch funktioniert.[/font]
    [font="Tahoma, sans-serif"]Beispiel:[/font]
    [font="Tahoma, sans-serif"]1. Tag: 1.Verz. Vollbackup, 2. Verz. kein, 3. Verz. kein, 4. Verz. kein …[/font]
    [font="Tahoma, sans-serif"]2. Tag: 1.Verz. inkr.backup, 2. Verz. Vollbackup, 3. Verz. kein, 4. Verz. kein …[/font]
    [font="Tahoma, sans-serif"]3. Tag: 1.Verz. inkr.backup, 2. Verz. inkr.backup, 3. Verz. Vollbackup, 4. Verz. kein …[/font]
    [font="Tahoma, sans-serif"]4. Tag: 1.Verz. inkr.backup, 2. Verz. inkr.backup, 3. Verz. inkr.backup, 4. Verz. Vollbackup …[/font]
    [font="Tahoma, sans-serif"]5. Tag: 1.Verz. inkr.backup, 2. Verz. inkr.backup, 3. Verz. inkr.backup, 4. Verz. inkr.backup …[/font]
    [font="Tahoma, sans-serif"]Deshalb sollte man vermeiden ein Verzeichnis mit mehr als 200-250 GB am Stück zu sichern, denn das dauert ca. 20 Stunden und würde so in den nächsten Start des Scriptes laufen.[/font]
    [font="Tahoma, sans-serif"]Beim ersten Start des Scriptes bedeutet das, dass es zunächst entsprechend viele Durchläufe/Tage bedarf bis alle Verzeichnisse im Arrey ihr erstes Vollbackup erhalten haben. Danach ist nie wieder ein Teil ungesichert.[/font]
    [font="Tahoma, sans-serif"]Die wichtigsten Ereignisse werden als Report am Ende an den eingetragen User geschickt.[/font]
    [font="Tahoma, sans-serif"] [/font]
    [font="Tahoma, sans-serif"]2.4 Das Script[/font]
    (ich habe PHP-Code genommen damit wenigstens ein bischen Syntaxhighlighting ist)
    [code=php]#!/bin/bash
    # Script fuer inkrementelles Backup mit 30 taegigem Vollbackup

    #################### >>>>>>>>>>>>>>>>>>>> Customizing Area <<<<<<<<<<<<<<<<<<<< ############################################################
    ### Einstellungen ## ##
    MAILUSER="root" ## User der die Backupreports bekommen soll
    RAWSOURCE="media/usbhdd1" ## Stammverzeichnis (oder Laufwerk) das gesichert werden soll
    RAWBACKUPDIR="media/usbBackUp/backup" ## Backupverzeichnis (oder Laufwerk) mit Namensprefix für die Unterordner (hier backup)
    TYPES=("TV" "Videos" "Bilder" "Musik" "Archive" "Benutzer" "Downloads" "") ## Inhalt der Backups bzw. Unterordner des Stammverzeichnis die separt gesichert werden sollen. ("" = Gesamtes Stammverzeichnis ohne Unterverzeichnisse, wenn soll(te) es immer am Ende stehen)
    DEFAULTDAYS=30 ## Standard an "Tagen" bis zum nächsten Vollbackup
    DAYS=( 180 180 90 90 720 ) ## Differenziert "Tage" pro Unterordner (siehe Types) bis zum nächsten Vollbackup
    ## wenn DAYS auskommentiert ist wird immer DEFAULTDAYS genommen (hier bekommen die letzten 3 die DEFAULTDAYS)
    #################### >>>>>>>>>>>>>>>>>> Customizing Area Ende <<<<<<<<<<<<<<<<< ############################################################

    MSG="Hallo Admin,\n\n"
    FFBU="false" ##FFBU ist das first-full-backup Flag das gesetzt wird wenn das erste Vollbackup gelaufen ist, damit nicht alle Vollbackups an einem Tag laufen
    i=-1
    for TYPE in "${TYPES[@]}"
    do
    ((i++))

    if [ "${TYPE}" = "" ]
    then
    TYPE2=""
    SOURCE="${RAWSOURCE}" ## Verzeichnis(se) welche(s) gesichert werden soll(en)
    EXCLUDE="${EXCLUDETEMP}"
    else
    TYPE2="-${TYPE}"
    SOURCE="${RAWSOURCE}/${TYPE}" ## Verzeichnis(se) welche(s) gesichert werden soll(en)
    EXCLUDETEMP="$EXCLUDETEMP--exclude=${RAWSOURCE}/${TYPE} "
    fi

    BACKUPDIR="${RAWBACKUPDIR}${TYPE2}" ## Pfad zum Backupverzeichnis
    ROTATEDIR="${RAWBACKUPDIR}${TYPE2}/rotate" ## Pfad wo die Backups nach 30 Tagen konserviert werden
    TIMESTAMP="timestamp.dat" ## Zeitstempel
    DATUM="$(date +%d-%m-%Y)" ## Datumsformat einstellen
    ZEIT="$(date +%H.%M)" ## Zeitformat einstellen

    if [ -z "${DAYS[$i]}" ]
    then
    DAYS[$i]=$DEFAULTDAYS
    fi
    MSG=$MSG"Backup von ${TYPE} startet um $(date +%H:%M)\n"

    ### Wechsel in root damit die Pfade stimmen ##
    cd /

    ### Backupverzeichnis anlegen" ##
    mkdir -p ${BACKUPDIR}

    ### Test ob Backupverzeichnis existiert und Mail an Admin bei fehlschlagen ##
    if [ ! -d "${BACKUPDIR}" ]; then

    MSG=$MSG"das Backup am ${DATUM} konnte nicht erstellt werden. Das Verzeichnis ${BACKUPDIR} wurde nicht gefunden und konnte auch nicht angelegt werden.\n"

    continue
    fi

    ### Alle Variablen einlesen und letzte Backupdateinummer herausfinden ##
    set -- ${BACKUPDIR}/backup${TYPE2}-???.tgz
    lastname=${!#}
    backupnr=${lastname##*backup${TYPE2}-}
    backupnr=${backupnr%%.*}
    backupnr=${backupnr//\?/0}
    backupnr=$[10#${backupnr}]

    ### Backupdateinummer automatisch um +1 bis maximal 30 erhoehen ##
    if [ "$[backupnr++]" -ge ${DAYS[$i]} -a "${FFBU}" = "false" ]; then

    mkdir -p ${ROTATEDIR}/${DATUM}-${ZEIT}

    ### Test ob Rotateverzeichnis existiert und Mail an Admin bei fehlschlagen ##
    if [ ! -d "${ROTATEDIR}/${DATUM}-${ZEIT}" ]; then

    MSG=$MSG"die alten Backups konnten am ${DATUM} nicht verschoben werden. Das Verzeichnis ${ROTATEDIR} wurde nicht gefunden und konnte auch nicht angelegt werden.\n"


    continue
    else
    mv ${BACKUPDIR}/b* ${ROTATEDIR}/${DATUM}-${ZEIT}
    mv ${BACKUPDIR}/t* ${ROTATEDIR}/${DATUM}-${ZEIT}
    fi

    ### Abfragen ob das Backupverschieben erfolgreich war ##
    if [ $? -ne 0 ]; then

    MSG=$MSG"die alten Backups konnte am ${DATUM} nicht verschoben werden.\n"

    continue
    else

    MSG=$MSG"die alten Backups wurde am ${DATUM} erfolgreich nach ${ROTATEDIR}/${DATUM}-${ZEIT} verschoben.\n"

    ### die Backupnummer wieder auf 1 stellen ##
    backupnr=1
    fi
    fi

    if [ "$[backupnr]" -ge ${DAYS[$i]} -a "${FFBU}" = "true" ]; then
    MSG=$MSG"das Vollbackup ${Type} wurde als Inkrmentell fortgesetzt, da bereits ein Vollbackup ausgeführt wurde.\n"
    fi

    backupnr=000${backupnr}
    backupnr=${backupnr: -3}
    filename=backup${TYPE2}-${backupnr}.tgz

    if [ "${backupnr}" = "001" -a "${FFBU}" = "true" ]; then
    MSG=$MSG"das Vollbackup ${Type} wurde übersprungen, da bereits ein Vollbackup ausgeführt wurde.\n"
    continue
    fi

    ### Nun wird das eigentliche Backup ausgefuehrt ##
    tar --no-check-device -cpzf ${BACKUPDIR}/${filename} -g ${BACKUPDIR}/${TIMESTAMP} ${SOURCE} ${EXCLUDE}

    ### Abfragen ob das Backup erfolgreich war ##
    if [ $? -ne 0 ]; then

    MSG=$MSG"das Backup ${filename} am ${DATUM} wurde um $(date +%H:%M) mit Fehler(n) beendet.\n"

    else

    MSG=$MSG"das Backup ${filename} am ${DATUM} wurde um $(date +%H:%M) erfolgreich beendet.\n"
    if [ "${backupnr}" = "001" ]; then
    FFBU="true"
    fi

    fi

    done
    MSG=$MSG"Das gesamte Backup wurde am $(date +%d-%m-%Y) um $(date +%H:%M) beendet\n\n"
    MSG=$MSG"Mit freundlichem Gruss Backupscript\n"

    echo -e $MSG | mail -s "Backupreport" ${MAILUSER}
    [/php]

    bei crontab -e musst Du den root weglassen.

    außerdem musst du python vor den Pfad setzen.

    Für crontab -e

    Code
    1 16 * * *        python /usr/bin/bewässerung.py

    und für sudo nano /etc/crontab

    Code
    1 16 * * *        root    python /usr/bin/bewässerung.py

    oder ist es in python 3 geschrieben?

    Hast Du schon mal mit unixoiden Systemen gearbeitet? Die unterscheiden zwischen Groß- und Kleinschreibung.

    Außerdem rufst Du mit Deinem Kommando den Editor (nano) auf mit dem script zum editieren. Darüberhinaus wenn Du sowieso das mit sudo aufrufst warum packst Du den Aufruf nicht direkt in die /etc/crontab mit root als user?

    Wo liegt Dein Script? Angenommen in /usr/bin/script/python/bewässerung.py
    Der Eintrag in der /etc/crontab würde lauten:

    Code
    13 12      * * *     root       python /usr/bin/script/python/bewässerung.py


    und die # am Ende der Liste nicht vergessen bzw nicht löschen. (die größeren Lücken sollen TABs sein)

    Bei Deiner UserCrontab lässt Du einfach root weg, bin mir aber nicht ganz sicher, weil ich alles in die /etc/crontab packe.

    wenn du mit sudo nano /etc/crontab aufrufst sollte unter anderem sowas da stehen:

    Code
    # m h dom mon dow user  command
    17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
    25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
    47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
    52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
    0 1     * * *   root    php5 /etc/PiData/script/php/wpDownload/wpDownload.php
    0 22    * * *   root    bash /etc/cronbackup/backupAll
    #

    in der obersten Zeile steht die Zuordnung zu den Spalten:
    m = Minuten
    h = Stunde
    dom = day of month / Tag des Monats
    mon = Monat
    dow = day of week / Wochentag (für wöchendlich)
    user = der der es ausführen soll (meistens root)
    command = was halt gemacht werden soll

    wenn Du damit leben kannst das Dein script auch um 6:25 ausgeführt wird stell es einfach in das /etc/cron.daily -Verzeichnis.
    sonst orientiere Dich an meinen beiden Jobs (PHP um 1:00 und bash um 22:00). Du muss verm. nur Python selbst mit aufrufen wie PHP oder bash.

    Achja, bei mir sind zwischen Zeit, Tage, User und Kommando ein Tab (0 22 [TAB] * * * [TAB] root [TAB] bash /etc/cronbackup/backupAll)

    Eine gute Seite ist https://wiki.ubuntuusers.de/Cron/

    Ich habe mal ein kleines Backup gestartet und wenn die Syntax:

    Code
    tar --no-check-device -cpzf ${BACKUPDIR}/${filename} -g ${BACKUPDIR}/${TIMESTAMP} ${SOURCE} ${EXCLUDE}


    richtig ist, klammert tatsächlich tar die DeviceID einfach aus. Es wird ganz normal das nächste incremental angelegt.


    Deinem udev+mount Gedankengang kann ich grad nicht wirklich folgen...


    Die Frage für mich war, wenn ein physisches USB Gerät eingehängt wird, heisst es zunächst (als Platte) sd?x. Dann biege ich den Namen in der udev auf fileservice (oder backup wie bei meigrafd) um und mounte es über die fstab an meinem /media/usbhdd1.

    Dass tar für den device check nicht /media/usbhdd1 nimmt, ist klar sonst hätte ich diese Problem nicht. Die Frage ist nun, nimmt tar fileservice als device oder weiterhin sdc1 (in meinem Fall). Leider befürchte ich, dass es weiterhin sdc1 sein wird, da ich bisher in der fstab auch über die UUID und nicht über die sd?x gemounted habe.

    Wenn das jetzt ausgeräumt ist, werde ich in den nächsten Tagen mal mein Backup "Projekt" vorstellen mit einem kaskadierenden (modifizierbarem) Backup script für eine Vollsicherung meiner 1.5TB Platte.
    :danke_ATDE: für Eure Unterstützung

    He he, wie soll's auch anders sein, trotz zig reboots wird die Platte immer wieder als sdc1 eingehängt und ich kann nichts testen.

    Ich denke die [font="monospace"]--no-check-device[/font] Option die ist die flexibelste Lösung, wenn sie funktioniert ;) , werde es testen wenn ich mal wieder an der Platten rumstöpsel. Achja, wenn ich jetzt die Option mit aufnehme, fängt tar dann wieder überall mit eine Vollbackup an, oder kann tar die DeviceID rausrechnen?

    Wenn ich die udev Lösung nehmen würde, würde ich dann [font="monospace"]SYMLINK+="fileservice"[/font] eintragen und dann im /etc/fstab [font="monospace"]/dev/fileservice /media/usbhdd1/ ntfs-3g defaults,umask=000,users 0 0[/font] zum mounten? Nur eine geänderte Device ID wie sda1 (zB) würde bleiben. Oder würde dann auch die Device ID in stat für "fileservice" und nicht für sdc1 angezeigt?

    Wenn ich mir das so ansehe befürchte ich, egal wofür ich mich entscheide, ich muss erstmal wieder mit einem Vollbackup anfangen, oder?

    Vielen Dank Dreamshader für das gemeinsame Kopfzerbrechen :lol:

    Es sieht so aus, dass ich Dein EDIT widerlegen muss.

    denn ich habe herausgefunden das die Device ID in hex simultan zu den Device ID aus dem blkid ist.
    Hier meine leihenhafte Annahme:
    8 an der 3. Stelle von rechts entspricht "sd", die 2. Stelle von rechts entspricht dem Devicebuchstaben (a, b, c etc.) und die rechteste Stelle der Partition.
    Demnach muss diese Platte jetzt unter /dev/sdc1 hängen und sie tut es auch.

    Dann dachte ich mir ich mache nun jedesmal ein kleines backup und boote neu um zusehen ob das inkrementell backup mit eine gleichen DeviceID normal fortgeführt wird...
    Brauchte ich aber nicht, denn wenn die Platte unter sdc1 hängt werden die inkrementell backups normal fortgeführt.

    Code
    File: ‘TV’
     Size: 0               Blocks: 0          IO Block: 4096   directory
    Device: 821h/2081d      Inode: 445532      Links: 1
    Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2016-06-01 08:45:10.296291600 +0200
    Modify: 2016-02-06 10:08:38.030488200 +0100
    Change: 2016-02-06 10:08:38.030488200 +0100
    Birth: -

    Das heißt: Wie bekomme ich raspbian dazu jede Platte immer wieder unter der gleichen Device ID einzuhängen, also dass die Fileserviceplatte immer sdc1 ist.

    Noch eine Frage zu rsync: Macht rsync auch incremental und komprimiert rsync auch?

    Wie gesagt die Idee fand ich gut und sehr plausibel :thumbs1:
    aber es scheint etwas anderes zu sein :s .

    Code
    File: ‘TV’
     Size: 0               Blocks: 0          IO Block: 4096   directory
    Device: 811h/2065d      Inode: 445532      Links: 1
    Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2016-06-01 08:45:10.296291600 +0200
    Modify: 2016-02-06 10:08:38.030488200 +0100
    Change: 2016-02-06 10:08:38.030488200 +0100
    Birth: -

    Auf der Seite http://linuxwiki.de/tar steht:

    Zitat

    So, wie geht das nun: tar kennt den Schalter '-g', mit dem ein Log aller Verzeichnisse mit Prüfsummen angelegt wird. Anhand dieser Prüfsummen entscheidet tar dann später, welche Dateien bei einem inkrementellen Backup zu sichern sind. Ausgangspunkt ist das /home Verzeichnis, das gesichert werden soll. Die Archive und die Logs landen in /backup:

    Es scheint beim erneuten Einhängen der Platte (über fstab) nach einem Neustart wird eine neue Prüfsumme gebildet.
    Deshalb ist die Frage wie kann ich das vermeiden, DENN(!) mein Testbackup das ich von meinem /home Verzeichnis mache ist von den Neustarts total unbeeindruckt!!!
    Automatisch zusammengefügt:
    Das was sich nur verändert hat nach dem reboot ist Device:

    erste Abfrage:

    Code
    File: ‘TV’
    Size: 0               Blocks: 0          IO Block: 4096   directory
    Device: 811h/2065d      Inode: 445532      Links: 1
    Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2016-06-01 08:45:10.296291600 +0200
    Modify: 2016-02-06 10:08:38.030488200 +0100
    Change: 2016-02-06 10:08:38.030488200 +0100
    Birth: -

    zweite Abfrage:

    Code
    File: ‘TV’
     Size: 0               Blocks: 0          IO Block: 4096   directory
    Device: 821h/2081d      Inode: 445532      Links: 1
    Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2016-06-01 08:45:10.296291600 +0200
    Modify: 2016-02-06 10:08:38.030488200 +0100
    Change: 2016-02-06 10:08:38.030488200 +0100
    Birth: -

    Sorry hatte ich vergessen hier der tar Befehl:

    tar -cpzf ${BACKUPDIR}/${filename} -g ${BACKUPDIR}/${TIMESTAMP} ${SOURCE} ${EXCLUDE}

    BACKUPDIR=media/usbBackUp/backup-TV
    filename=backup-TV-${backupnr}.tgz
    TIMESTAMP="timestamp.dat"
    SOURCE="media/usbhdd1/TV"
    EXCLUDE=""

    Die Idee mit dem Mountpunkt fand ich gut, aber das TV bereits ein Verzeichnis auf der Platte ist denke ich nicht, dass es das ist oder?

    Hallo,

    ich habe folgendes Problem.
    Ich habe ein bash script das nach einer Vollsicherung mit tar nur noch inkrementell sicher. Das funktioniert auch sehr gut, bis ich den Pi neu starte. Dann scheint tar alles zu vergessen und sichert im nächsten inkrementell ALLE Datein. Ich sichere von einer gemounteten Platte auf eine gemounteten Platte.
    Ich habe erfahren das tar mit den Checksummen der Verzeichnisse arbeitet um das inkrementell zu steuern. Ich vermute nun, dass durch das erneute Einhängen der Platten die Checksumme vom Verzeichnis ändert und somit alles als geändert angesehen wird.

    Gibt es eine Möglichkeit die Platten so einzuhängen dass es die Checksumme nicht verändert?
    Oder hatte schonmal jemand anderes so ein Problem und wie hat er es gelöst.

    Viele Grüße

    Ich hatte meine ersten Schritte mit
    https://www.privux.de/raspberry-die-ersten-schritte/
    gemacht.

    Dort ist auch ein Abschnitt:

    Zitat

    [font="Roboto, sans-serif"]Raspberry Konfigurieren[/font]
    Raspbian bringt ein rudimentäres Konfigurationsmenü mit:
    $ raspi-config
    Mit „1 Expand Filesystem“ gibst du dem PI die komplette Kapazität der SD Karte. Da die Mädels von Raspbian nicht die Größe deiner SD Karte im vorfeld kennen können, wird initial nur die minimale Größe verwenden.
    Im Bereich „4 Internationalisation Options“ kannst du dein Raspbian auf Deutsch umstellen. Zwar lasse ich die Sprache in Ruhe, stelle aber das Tastaturlayout um. Ebenfalls solltest du die Zeitzone auf „Europe/Berlin“ umstellen.

    Da das Projekt auf Pi2 basiert weis ich nicht ob das Expand Filesystem noch notwendig ist. Bei mir hat es funktioniert. Bei mir läuft eine 64MB Karte, wenn ich sie drin hab.

    Wenn Du den Raspberry Pi im Blick halten willst, installiere den rpimonitor https://jankarres.de/2013/11/raspbe…r-installieren/. Der ist mit Speichernutzungsangabe der SD Karte über den Webbrowser.


    FAQ => Nützliche Links / Linksammlung => Firmware/Kernel downgrade mit "rpi-update"

    Erst mal vielen Dank, meigrafd, für den Link, das Downgrade hat einwandfrei funktioniert.

    p.s.: Hab noch nicht getestet ob ein einfacher Austausch von bootcode.bin auch funktionioert...

    das geht. nach dem Downgrade habe ich lediglich die bootcode.bin und start.elf ausgetauscht und er bootet weiter von der Platte.

    Ich habe nur einen sonderbaren special effect, denn plötzlich hab ich nur noch 100MB Ram. Nein gegrillt habe ich ihn nicht, denn mit dem Beta Build ist wieder 1GB da und voll verfügbar.

    Was mir noch aufgefallen ist, ist das mit dem HDD Boot der Prozessor im PiMonitor eine permanente Grundlast von 0,5 (von 5max) hat und die Prozessortemperatur ist ca. 2 - 4 °C höher. Von der Karte gebootet hat er 0 Last im Ruhezustand auch die Temperatur ist niedriger bei ca. 48°C .