Posts by Willy B. aus S.

    Erledigt. Ein kleiner Eintrag im config File macht alles, was ich brauche:

    DEFAULT_AFTER_STARTSERVICES="cp -afru [Quelle]/* [Ziel]/USB-Stick"

    Das wird automatisch nach Ende des raspiBackup ausgeführt, wenn die Prozesse wieder gestartet sind.

    Ich habe der Versuchung widerstanden, es mit rsync zu machen. Wenn der USB-Stick die Grätsche macht, findet rsync ein leeres Verzeichnis und löscht auf dem NAS ebenfalls alles weg. Das sollte nicht sein.

    OK, Danke. Dann schaue ich mal, wie ich den Stick am Ende des Backups nochmal separat sichere; ein geeignetes Script sollte sich ja über DEFAULT_AFTER_STARTSERVICES starten lassen.

    Ich habe beim vorigen Raspi mit passender Konfiguration des OS zehn Jahre keine Probleme mit der SD-Karte bekommen. Da war immer vorher der USB-Stick am Ende. Deshalb auch der Backup-Wunsch. Bei einem 24/7 System bin ich knausrig, was den Stromverbrauch angeht; deshalb keine SSD.

    Ich kann mich dunkel erinnern, dass es während der Installation von raspiBackup eine Abfrage zum Intervall der Backups gab. Dort hatte ich Mittwoch und Sonntag, jeweils 4:00 Uhr eingegeben. Das möchte ich jetzt ändern, finde aber nicht, wo das zu tun ist. In der /usr/local/etc/raspiBackup.conf offenbar nicht. Und ein cron-Job wurde dafür auch nicht angelegt => wo sonst?

    Oder muss ich nochmal "drüber installieren", um die Eingabe nochmal zu bekommen 8|?

    Besten Dank schon mal im Voraus für die Antworten.

    Hi,

    ich habe auf meinem neuen Smarthome-Server (Raspi3B+) raspiBackup mit rsync erfolgreich zum Laufen gebracht. Das Backup wird per nfs-mount auf ein Synology NAS geschrieben.

    Um die Schreibzyklen der SD-Karte zu entlasten, werden die Smarthome-Daten auf einen per nfs gemounteten USB-Stick geschrieben. Diesen Stick würde ich gerne ins Backup integrieren, sehe aber nicht, wie das gehen könnte.

    Mit

    Code
    DEFAULT_PARTITIONBASED_BACKUP="1"
    DEFAULT_PARTITIONS_TO_BACKUP="*"

    werden nur die beiden mmcblk0p1/2 Partitionen gesichert.

    Bei

    Code
    DEFAULT_PARTITIONBASED_BACKUP="1"
    DEFAULT_PARTITIONS_TO_BACKUP="3"

    bekomme ich den Fehler

    RBK0093E: Angegebene Partition 3 der Option -T existiert nicht.

    Lässt sich das irgendwie so konfigurieren, dass bei

    Code
    DEFAULT_PARTITIONS_TO_BACKUP="*"

    ein drittes Unterverzeichnis für /dev/sda1 angelegt wird?

    Code
    sudo apt-get dist-upgrade

    kannte ich gar nicht. Ich hatte immer

    Code
    sudo apt-get upgrade

    für richtig gehalten. Ein Wunder, dass das jahrelang lief.

    Also das Backup eingespielt und wie oben von KKoPi beschrieben upgedatet.

    Leider bleibt das dist-upgrade auch irgendwann hängen, und zwar bei "Starting php5-fpm". Restart-Versuche klappen wieder nicht. Für beides sh. angehängte Datei. Ich muss wohl wieder den Stecker ziehen. Falls er nicht mehr bootet wieder das Backup ...

    Hi,

    hoffentlich kann mir Jemand helfen. Ich habe nicht so arg viel Ahnung von Linux, habe aber bestmöglich versucht, das Thema darzustellen.

    Ich versuche auf meinem FHEM-Server (Raspi-2B) libxml-libxml-perl

    zu installieren. Folgende Reihenfolge habe ich eingehalten:

    Code
    sudo apt-get update
    sudo apt-get upgrade
    reboot
    sudo apt-get install -f

    Damit sollte doch hoffentlich alles vorbereitet sein. Dann:

    Code
    sudo apt-get install libxml-libxml-perl

    Anschließend bleibt die Installation an dem im Titel genannten Punkt hängen. Auch warten über Nacht bewegte nichts.

    Die ganze Installationshistory habe ich in der angehängten Datei install.txt abgelegt.

    Wenn ich an dieser Stelle in einem anderen Konsolenfenster einen top aufrufe, dann sehe ich lediglich perl (der FHEM-Server) als Prozess mit nennenswerter CPU-Aktivität. Das sieht nicht aus,als ob sich da noch was tut.

    Wenn ich die Sache mit einem shutdown abwürgen will, dann erhalte ich

    Aber er fährt nicht runter. Nach einen ENTER ist der Prompt wieder da. Nach einem harten Power off (ich weiß ... darf man nicht, aber was sonst?) bleibt der Reboot in einem frühen Stadium hängen, so dass ich per ssh nicht mehr drauf zugreifen kann. Deshalb kann ich diesen Zustand nur mit einem Bildschirmfoto dokumentieren, sh. angehängtes jpg.

    Hat Jemand eine Idee, was da schief läuft und wie ich es beheben kann? Für jegliche Hilfe bedanke ich mich schon mal im Voraus.

    Gruß

    Willy

    Das scheint aber jetzt richtig gut zu sein, danke! Es ist zwar verwunderlich, dass ich auf beiden Raspis dieselbe Samba-Version angezeigt bekomme, und auf dem einen tut's trotzdem nicht, aber nun habe ich immerhin neue Lösungsansätze - und vor allem das richtige Forum mit Leuten, die dasselbe Thema teilen.

    Nein, ich logge mich als user "pi" ein. Aber auch pi hat Root-Rechte und - lokal in der Shell - die Berechtigung, in jedes Unterverzeichnis zu gehen. Nur von Windows aus geht das nicht - warum???.
    Und es kommt noch schlimmer: das Verzeichnis /tmp gehört pi. Auch in dieses Verzeichnis komme ich nicht von Windows aus, obwohl ich ja pi bin.

    Code
    drwxrwxrwx   5 pi     pi         4096 Jan 31 19:30 tmp

    Hi,
    ich probiere schon tagelang rum und bekomme es nicht gebacken, deshalb brauche ich jetzt professionelle Hilfe.

    Ich habe 2 Raspis:

    - raspi1: Raspberry Pi B
    - raspi2: Raspberry Pi 2B

    Die Konfiguration von raspi2 habe ich als Clone von raspi1 erstellt und für die andere CPU upgedatet gemäß Anleitung in RaspberryPi-Geek. Das lief auch immer perfekt - incl. Samba. Aber seit ein paar Wochen geht der Sambazugriff von Windows auf raspi2 nicht mehr.

    • Auf //raspi1/root incl. Unterverzeichnisse kann ich vom Windows-Explorer per Netzlaufwerk zugreifen,
    • auf //raspi2/root komme ich zwar, aber von da an nicht weiter in die Unterverzeichnisse (ging aber vorher monatelang).

    Versuche mit anderen Verzeichnissen verlaufen durchweg positiv, nur root klemmt.

    Ich logge mich jeweils als User pi ein, der auch Root-Rechte hat.

    Die smb.conf beider Rechner ist identisch. Und weil es ja ein Clone ist, sind auch Zugriffsrechte auf Dateien und Verzeichnisse identisch.

    Auch sudo smbpasswd -a pi habe ich schon hinter mir.

    Ich weiß, dass es aus Sicherheitsgründen nicht toll ist, das root-Verzeichnis freizugeben. Es geht mir hier letztlich auch nur noch um den sportlichen Ehrgeiz, das Problem zu lösen. Anschließend werde ich punktuell freigeben, was ich wirklich brauche.

    Ich habe inzwischen auch schon /etc/passwd, shadow und group beider Rechner verglichen und angepasst. Das Problem bleibt.

    Die smb.conf sieht so aus (um die vielen Kommentare und auskommentierten Zeilen gekürzt):

    Und hier das Root-Verzeichnis:

    Selbst in das Verzeichnis /tmp komme ich nicht, obwohl es pi gehört :no_sad:.

    Wer kann mir helfen? Schon mal im Voraus besten Dank dafür.

    Gruß
    Willy

    weil hier immer wieder rsync vorgeschlagen wird: ich habe dann lieber gleich rsnapshot genommen. rsnapshot baut auf rsync auf und nutzt intensiv Hardlinks. Das Ergebnis ist ein tägliches Backup, das in der Verzeichnisstruktur komplett aussieht, aber ungeänderte Dateien nur ein mal pysikalisch ablegt. Man muss dafür nicht selbst Scripte schreiben, sondern lediglich rsnapshot installieren (apt-get install rsnapshot) sowie das config File anpassen (/etc/rsnapshot.conf). Dann noch ein paar Einträge in der crontab für 30 tägliche, 4 wöchentliche und 12 monatliche Backups, und fertig ist die Backuplösung.

    Allerdings kann rsnapshot nicht auf remote Medien via ssh schreiben. Deshalb läuft rsnapshot auf meinem Linux-basierten NAS und greift beim Backup auf den Raspi lesend zu. Alternativ könnte man sicher ein Laufwerk mounten und rsnapshot auf dem Raspi laufen lassen.