raspiBackup und dynamic mounts

  • Ausgelagert aus raspiBackup 0.6.6 Beta


    So, ich bin mir nicht sicher ob es jetzt hier rein passt, aber ich oute mich als Nr. 3 mit diesem Problem:

    raspibackup und extended Attributes. Der Thread war mir etwas zu alt um es dahinein zu schreiben.

    Ich habe dann dort auch die Hinweise auf eine mögliche Lösung - Punkt 24 gefunden, aber bin nicht so richtig glücklich geworden:

    die dort beschriebenen Optionen 2 und 3 funktionieren bei mir nicht (wo müsste bei Option 2 die Variable im Script gesetzt werden?), Option 4 geht zwar, aber mit dem Loop device kommt es mir doch sehr umständlich vor, vor allem beim Restore.

    Ich habe nun eine ext. USB Platte mit ext4 angeschlossen (Option 1), lieber wäre mir das Backup auf dem NFS share des NAS gewesen. Die Synology Tipps haben mich auch nicht weitergebracht.

    Derzeit kämpfe ich mit dem raspiwrapper, da komme ich mit den Variablen noch nicht klar. Manuell kann ich meine virtuelle Disk mounten, per script klappt es noch nicht. Irgendwie passen die Pfade im Script noch nicht.

    Gruss

    Einmal editiert, zuletzt von hyle (16. Dezember 2020 um 18:04)

  • So, ich bin mir nicht sicher ob es jetzt hier rein passt,

    Nicht so ganz :no_sad: Ein neuer Thread ist besser angebracht da es sich nicht um die Beta sondern um die Problematik der xattrs dreht sowie den wrapper. Den Letzteren brauchst Du allerdings nicht mehr mit der Release 0.6.6 da dort dynamic mount eingefuehrt wurde und damit das Wrapperscript obsolet ist.

    Vielleicht ist hyle so nett und trennt die letzten beiden Beitraege in einem neuen Thread ab. Ansonsten moechte ich Dich bitten einen neuen Thread zu eroeffnen ;)

  • Mit dynamic mounts habe ich noch nicht wirklich gearbeitet.

    Ganz einfach ;)

    1) Defininere Deine Backuspacepartition in /etc/fstab (raspiBackup Default ist /backup).

    2) Mounte die Partition.

    2) Installiere und konfiguriere raspiBackup Release 0.6.6.

    Jetzt kannst Du die Aufrufoption fuer dynamic Mount benutzen. Ich empfehle aber die Konfigurationsdatei abzuaendern.

    Dazu gehst Du in /usr/local/etc/raspiBackup.conf und aenderst

    Code
    # Name der Backuppartition die dynamisch gemounted werden soll (z.B. /dev/sda1 oder /backup), muss sonst leer sein um keinen dynamischen Mount zu benutzen
    DEFAULT_DYNAMIC_MOUNT=""

    in z.B. (wenn Du den raspiBackup Default benutzt) in

    Code
    # Name der Backuppartition die dynamisch gemounted werden soll (z.B. /dev/sda1 oder /backup), muss sonst leer sein um keinen dynamischen Mount zu benutzen
    DEFAULT_DYNAMIC_MOUNT="/backup"
  • Das Backup läuft jetzt und die dynamischen mounts brauche ich gar nicht.

    War ein Denk- und Tippfehler meinerseits. Die virtuelle Disk habe ich ständig gemountet, da kann das Backup wunderbar hinschreiben.

    Aber: gerade festgestellt, das alles vergeblich war! :wallbash:

    Das Backup läuft, aber beim restore kommen wieder auf jeder Datei Attributsfehler.. WTF??? :helpnew:.

    Sieht so aus: rsync: rsync_xal_set: lremovexattr("/tmp/raspiBackup/etc/sane.d/.umax1220u.conf.FpA5ck","security.selinux") failed: Permission denied (13).

    Dabei spielt es keine Rolle, ob der restore mit sudo oder direkt als user root gestartet wird.

    Ich glaube für heute lass ich es und werde morgen mit dd testen... dann kann ich das ganze virtuelle Disk einhängen sparen.

    Gruss

  • Ja, deswegen wollte ich ja auch lieber rsync nutzen. Nur, was nutzt es, wenn die Backups jetzt ohne den Attributsfehler laufen, aber der Restore dafür nicht :conf:?

    Habe die Karte vorhin mit Clonezilla kopiert und der Clon läut jetzt im PI, als Notlösung geht das.

    ich werde es morgen aber noch mal mit einem Debian10 versuchen, hatte vorhin nur ein CentOS greifbar.

    Wobei ich nicht glaube, das es am OS hängt.

    Gruss

  • wenn die Backups jetzt ohne den Attributsfehler laufen, aber der Restore dafür nicht

    noch mal mit einem Debian10 versuchen, hatte vorhin nur ein CentOS greifbar

    Warum nimmst Du nicht Raspbian? Das ist die getestete und somit supportete Methode zum Restore. Ich restore bei mir auch auf einem Mint System. Das ist zwar nicht offiziell supported :no_sad: aber funktioniert. Warum es jetzt beim CentOS Restore Probleme gibt verstehe ich nicht:conf:

  • Manche Dinge können nicht warten... :D

    --- RBK0010I: mail01: raspiBackup V0.6.6 (7989828) stopped at Thu 17 Dec 2020 12:03:57 AM CET with rc 0.

    --- RBK0076I: Restore finished successfully.

    pi@raspberry:~ $

    Aus einer VM mit

    pi@raspberry:~ $ uname -a

    Linux raspberry 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux

    pi@raspberry:~ $ lsb_release -d

    Description: Debian GNU/Linux 10 (buster)

    pi@raspberry:~ $

    Damit kann man das Problem mit den Attributen umgehen! :thumbup:

    Gruss

  • So soll es funktionieren :thumbup:

    Merkwuerdig warum es mit CentOS Probleme gibt :conf: Vermutlich ist da eine aeltere rsync Version drin die irgendwie inkompatibel zu der im Buster ist. Aber man muss ja nicht alles verstehen. Ist aber interessant zu wissen denn ich dachte eigentlich dass es mit jeder Linuxdistri geht.

    Du schreibst VM. Welchen Hypervisor und welche Umgebung benutzt Du dazu? ich frage deshalb weil ich raspiBackup Regressiontests auch in einer VM unter QEMU auf Linux laufen lasse um nicht jedesmal SD Karten wechseln zu muessen so dass der Test ueber Nacht durchlaufen kann. Ausserdem wuerde ich sonst arm werden denn die Tests sind Stress fuer SD Karten und es kommt zu regelmaessigen Ausfaellen so dass immer wieder neue gekauft werden muessten. Bislang laeuft alles noch unter Stretch. ich habe es bislang nicht geschafft ein Buster Raspbian in QEMU zum Laufen zu bekommen :(

  • Ich habe VM Workstation 16.x und dort das Raspbian für PC installiert.

    Den USB Stick (Kartenleser) habe ich dann vom Notebook auf die VM durchgereicht.

    Das CentOS hatte ich schon als VM, auch ein Debian, aber letzteres nicht auf diesem PC. Aber dann hast Du mir mit Deinem Hinweis auf Raspbian sozusagen die Tür geöffnet, das in einer VM zu installieren.

    Gruss

  • Ich habe heute noch mal ein paar Tests mit dem Backup auf ein NFS Share gemacht:

    Wenn man nfs v4 aktiviert und das entsprechend mounted, dann läuft das Backup auch ohne die Attributsfehlermeldung durch.

    Allerdings quälend langsam (ca. 30min).

    Ich fürchte, da muss ich bei Gelegenheit noch ein paar Versuche mit wsize/rsize anstellen, dahzu hatte ich aber heute keine Zeit.

    Gruss

  • Wenn man nfs v4 aktiviert und das entsprechend mounted, dann läuft das Backup auch ohne die Attributsfehlermeldung durch.

    Klingt gut. Koenntest Du noch zeigen wie der Mount bzw der Eintrag in det /etc/fstab dazu aussieht?

    Allerdings quälend langsam

    Beim ersten Backup? Oder erst beim folgenden? Der erste Backup ist ein Vollbackup und dauert dann auch entsprechend lange. Alle folgenden Backups sind aber schneller.

  • Der Eintrag in der /etc/fstab war:

    Code
    pi@piwx:~# cat /etc/fstab
    proc            /proc           proc    defaults          0       0
    PARTUUID=47c5f66f-01  /boot           vfat    defaults          0       2
    PARTUUID=47c5f66f-02  /               ext4    defaults,noatime  0       1
    # a swapfile is not a swap partition, no line here
    #   use  dphys-swapfile swap[on|off]  for that
    192.168.178.20:/pitst /media/NFS/Backup nfs4    defaults,noatime  0       0

    Kontrolle:

    Code
    pi@piwx:~# mount  | grep media
    192.168.178.20:/pitst on /media/NFS/Backup type nfs4 (rw,relatime,vers=4.0,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.178.27,local_lock=none,addr=192.168.178.20)
    pi@piwx:~# umount /media/NFS/Backup 

    Ich hatte es aber über Hofei mount units gemountet, die mount unit sah so aus:

    Und leider dauerte jedes Backup so lange ?(.

    Bei dem anderen Pi (sind beide nahezu identisch) dauert es über das Loopdevice ca. 30s, bis das Backup durch ist.

    Und ja, der Restore wurde schon getestet, es ist alles da ;). Das erstmalige Backup dauerte dort ca. 5min.

    Gruss

    Einmal editiert, zuletzt von FSC830 (5. Januar 2021 um 21:57)

  • Ich habe gerade ein Verständnisproblem:

    1. Wo siehst Du im Parseteil des Scripts einen Unterschied zur /etc/fstab?

    2. Habe ich im Script nicht gefunden, wo jetzt mount Optionen wie z.B. die nfs Version ausgelesen/mitgegeben wird?

    Gruss

    Edit:

    Heute morgen etwas Zeit gehabt: Pi #2 (der mit dem ich die nfs4 mounts getestet hatte) ebenfalls auf Backup auf ein Loopdevice umgebaut:

    Erstes Backup ca. 2'30", die folgenden Backups alle ca. 30".

    Damit ist nfs4 für mich erst mal passé bis ich die Bremse gefunden habe, das dauert aber noch, bis ich mich darum kümmern kann.

    2 Mal editiert, zuletzt von FSC830 (6. Januar 2021 um 13:32)

  • Wo siehst Du im Parseteil des Scripts einen Unterschied zur /etc/fstab?

    Ich will sagen ich verstehe nicht warum Du die Meldung bekommst da im Code ein Match auf Deine PARTUUID Zeile in der /etc/fstab stattfinden muesste :conf:. Ich habe das bei mir eben noch mal getestet und alles ist OK. Du bist auch der Erste der solch ein Problem meldet.

    Habe ich im Script nicht gefunden, wo jetzt mount Optionen wie z.B. die nfs Version ausgelesen/mitgegeben wird?

    Saemtliche nfs Mountdinge muessen in der /etc/fstab stehen. raspiBackup aendert keine nfs Optionen.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!