Sehr hoher "htop"-Wert von "Load average"

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Jetzt scheint fast alles wie vorgesehen funktioniert zu haben. Der Share wird getrennt. "Einstellungen/System" wird geladen. Keine Fehlermeldungen am Ende der Konsolenausgabe

    "raspiBackup.log" ist aber nicht auf dem Share zu finden, sondern lokal im Homeverzeichnis. Da ist mir jetzt nicht klar, ob das so erwartet wird.

  • Das sieht doch jetzt schon ganz gut aus :thumbup: .

    Nur sollte das Debuglog auch im Backupverzeichnis landen :conf: . Um rauszufinden warum das nicht geklappt hat benoetige ich das Debuglog was Du ja im Homeverzeichnis gefunden hast. Kontrolliere aber noch mal ob es wirklich das Log vom letzten Backuplauf ist indem Du das Datum und die Zeit bei der Startmeldung kontrollierst. Entweder stellst Du das anonymisierte Log irgendwo ins Netz, haengst es hier im Thread an oder schickst es mir per eMail. Die Adresse findest Du auf meiner Kontaktseite ;)

  • Danke framp

    Sind wir hier jetzt bereits zu weit weg vom ursprünglichen Thema?

    Ohne Dich auf eine falsche Spur führen zu wollen; ich habe im Zusammenhang mit der Suche nach der Ursache für das ursprüngliche Problem sehr viele zusätzlich Dienste in die Liste der stillzulegenden aufgenommen. Kenn es sein?

    Da kann ich wohl wieder einiges rückgängig machen.

    Ich habe das Debuglog an eine eMail angefügt.

  • Sind wir hier jetzt bereits zu weit weg vom ursprünglichen Thema?

    Jupp. Habe ich auch bemerkt. Aber zu spaet um noch einen neuen Thread zu eroeffnen :(

    sehr viele zusätzlich Dienste in die Liste der stillzulegenden aufgenommen. Kenn es sein?

    Die alte Methode von dynamic_mount hat offensichtlich TimingProbleme die mit der neuen Methode geloest sind. Ich denke nicht dass es mit den vielen Services zu tun hat.

    Vielen Dank fuer das Log. Ich sehe darin dass es nicht auf der Backuppartition gesichert wird. Warum habe ich jetzt auf die Schnelle nicht gesehen. Ich brauche dafuer mehr Zeit.

  • Es hat etwas gedauert bis ich eine Idee habe wo die Ursache warum das Logfile nicht im Backupverzeichnis landet sondern in home zu suchen ist.

    Du benutzt SmartRecycle und hast raspiBackup schon mehrere Male den Tag aufgerufen.

    Code
    20220401-125959 DBG 5320:                  /mnt/qnap/@HOSTNAME@/@HOSTNAME@-rsync-backup-20220401-011005
    20220401-125959 DBG 5320:                  /mnt/qnap/@HOSTNAME@/@HOSTNAME@-rsync-backup-20220401-115727
    20220401-125959 DBG 5320:                  /mnt/qnap/@HOSTNAME@/@HOSTNAME@-rsync-backup-20220401-122956

    Ausserdem hast Du auch manuell ein weiteres Backupverzeichnis angelegt.

    Code
    20220401-125959 DBG 5320:                  /mnt/qnap/@HOSTNAME@/LastKnownWellRunningBullseyeUpgradedFromBuster@HOSTNAME@-rsync-backup-20211121-111500

    Eines von beidem oder beides zusammen fuehrt dazu dass raspiBackup das Log in home stehen laesst.

    Ich wuerde jetzt folgendes empfehlen:

    1) Speichere Dein LastKnownWellRunningBullseyeUpgradedFromBuster Verzeichnis nicht unter dem Backupverzeichnis /mnt/qnap/@HOSTNAME@/ ab sondern z.B. unter /mnt/qnap/LastKnownWellRunningBullseyeUpgradedFromBuster/. Dadurch wird sowohl die SmartrecycleLogik als auch die einfachere Logik nur eine gewisse Anzahl von Backups vorzuhalten gestoert.

    2) Lasse Deinen regelmaessigen taeglichen Backup einmal laufen und starte ihn nicht noch ein zweites Mal den Tag.

    Ich vermute dann wird sich das Debulog auch wieder im Backupverzeichnis befinden.

    Parallel habe ich mal einen Issue dazu aufgemacht. Ich will mal sehen ob das noch mit vertretbarem Aufwand in die 0.6.7 Beta eingebaut werden kann.

Jetzt mitmachen!

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