RC 23 error bei raspiBackup (auf Synology)

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo

    Ich habe bereits 2 raspiBackup erfolreich auf meiner Synology laufen.

    Beim 3. Raspberry (darauf läuft: Pihole und ein rsync Backup vom Synology auf eine am Raspi per USB angeschlossene HD)

    Ich schliesse mal Probleme mit den Zugriff auf die Synology aus, weil die anderen raspiBackups laufen.

    Was mich an diesem Raspberry noch verunsichert ist, wenn ich via rdp einlogge dann erhalte ich diese Meldung:

    "authentication is required to refresh the system repositories" und ich muss dann das Passwort eingeben damit den Datei Explorer öffnen kann

    Hat dies einen Zusammenhang? Diese Meldung würde ich auch gerne wegbekommen. Erste prio hat aber raspiBackup

    Danke für euren Support

  • Code
    sync: [generator] set_acl: sys_acl_set_file(var/log/journal, ACL_TYPE_ACCESS): Operation not supported (95)

    Normalerweise sollten bei nfs die Journals excluded werden beim Backup. Die Ursache liegt in

    Code
    20230321-200944 DBG 5569:                          /dev/sda1                              3.6T 1018G  2.6T  28% /media/backups
    20230321-200944 DBG 5569:                          192.168.98.122:/volume1/xbackup-raspi  3.5T  1.4T  2.2T  38% /backup

    Du hast /media/backups und /backup gemounted. Bloederweise wird von raspiBackup /dev/sda1 als Backupdevice mit ext4 erkannt und dadurch wird /var/log/journal nicht beim Backup excluded :no_sad: .

    Das ist ein Bug und ich sehe mir das an :)

  • Ich danke dir vielmals

    Kann es sein, dass das Problem auch durch Berechtigungen betreffend rdp verursacht werden?

    drwx------ 1 pi pi 0 Mar 22 11:29 thinclient_drives

    drwxr-xr-x 2 pi pi 4096 Feb 21 02:35 Videos (Beispiel)

    Edit: Es funktioniert nun

    rdp habe ich standardmässig unter "lokale Ressourcen" alles disconnected. Wird eh nicht benötigt.

    Werde jetzt für die Raspi eine rdp session speichern

    drwxr-xr-t 2 pi pi 4096 Mar 22 12:48 thinclient_drives

  • Ich habe mir das jetzt mal angesehen und es ist definitiv ein Bug den ich eben gefixed habe.

    Waere nett wenn Du den Fix bei Dir testen koenntest. Du musst nur dafuer sorgen dass auf /media/backups /dev/sda1 gemountet ist. Dann folgende zwei Befehle ausfuehren:

    Code
    curl -s https://raw.githubusercontent.com/framps/raspiBackup/master/scripts/raspiBackupDownloadFromGit.sh | bash -s -- master_639 raspiBackup.sh
    sudo ./raspiBackup.sh

    Achte auf ./ beim zweiten Befehl :)

  • Ich konnte nun testen. Allerdings habe ich das Livesystem heute morgen umgestellt und dieses will ich nicht mehr anfassen. Da läufts jetzt alles
    Ich habe mit eeinem Backup den Test durchgeführt und musste den mount auf einen USB Stick umstellen. Geprüft habe ich ob ich auf den Stick was schreiben konnte. Das war erfolgreich
    Jedoch hat das Backup nicht funktioniert

  • Jedoch hat das Backup nicht funktioniert

    Vielen Dank fuer Deinen Test. Da war tatsaechlich noch etwas was ich im Code uebersehen hatte :blush:

    Das habe ich gefixed und jetzt sollte der Backup erfolgreich sein :)

    Allerdings habe ich im Log gesehen dass Du nicht mehr den Stand von damals hattest: Da hattest Du unter /media/backups einen USB Stick zusaetzlich zu /backup gemounted. Dadurch wurde ein falscher Mount fuer den nfs Check gewaehlt. Das hatte ich geaendert und auch getestet. Dummerweise hatte ich dann aber uebersehen dass das Ergebnis des Tests etwas anders ermittelt werden muss :blush:

    Es zeigt sich doch dass es immer gut ist noch mal den Fix verifizieren zu lassen. :danke_ATDE:

  • Ich sehe noch immer allenfalls als zweites Problem das mit rdp

    Habe heute Mittag Backup gestartet. Es war eine rdp session aufdiesem Raspberry offen

    Rechte: drwx------ 1 pi pi 0 Mar 23 12:38 thinclient_drives

    Backup ist abgebrochen

    Fehlermeldung: rsync: [sender] readlink_stat("/home/pi/thinclient_drives") failed: Permission denied (13)

    Danach nochmals mit geschlossenen rdp client

    Rechte: drwxr-xr-t 2 pi pi 4096 Mar 22 07:48 thinclient_drives

    Backup hat funktioniert

    Es ist mir schon bewusst, dass hier Raspberr Verbindungen mit rdp eher weniger un Gebrauch ist. Kann man trotzdem "thinclient_drives" im Backup nicht auf die "exclude" Liste setzen? MAcht ja irgendwie auch keinen Sinn sowas zu sichern auc hwenn es ginge.

  • Das stimmt schon. Jedoch wird sicher wiedermal einer kommen und das selbe Problem haben. Daher fände ich es im Download script sinnvoll. Es sei den es gibt niemand der mit rdp arbeitet. Dann bin ich ein halt eine alter Windows Dino :D und brauche noch etwas mehr Zeit um mich mit dem Raspi rum zu schlagen.

  • Backup hat funktioniert

    D.h. mein Fix ist jetzt OK. Vielen Dank fuer das Verifizieren und Finden des buggy ersten Fixes :danke_ATDE: ich werde den Fix dann in den Master mergen.

    Kann man trotzdem "thinclient_drives" im Backup nicht auf die "exclude" Liste setzen? MAcht ja irgendwie auch keinen Sinn sowas zu sichern auc hwenn es ginge.

    Ich sehe Deinen Punkt. Aber ich moechte bewusst raspiBackup von speziellen anwendungsspezifischen Dingen freihalten. Es gibt diese Seite die man findet wenn "raspibackup rc 23" in eine Suchmaschine eingegeben wird und dort werden verschiedene Methoden genannt wie man den RC23 wegbekommt.

    Vorstellbar waere z.B. hier im Forum einen Thread zu erstellen wo raspiBackup Nutzer ihre Excludelisten vorstellen und somit von anderen neuen Nutzern uebernommen werden koennen.

  • Ich verstehe das. Ich weiss ja jetzt wie ich damit umgehen muss. Ich danke dir für die tolle Unterstützung :thumbup:

    Als Abschluss Frage. Spricht etwas dageben via WireGuard ein Backup laufen zu lassen? Die Verbindung ist sehr stabil und schnell. Gibt es was spezielles zu beachten?

  • Gibt es was spezielles zu beachten?

    Nicht dass ich wuesste. Ich habe allerdings auch keine Erfahrung. Vermutlich wird der Durchsatz etwas geringer sein. Ansonsten gibt es das Problem was man bei einer Netzverbindung immer hat: Wenn die abbricht ist der Backup unvollstaendig. Ein Resume ist nicht moeglich. Und man sollte dann manuell den unvollstaendigen Backup wieder loeschen. Im naechsten Release wird das aber nicht mehr notwendig sein (Siehe diesen issue)

Jetzt mitmachen!

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