Basic Backup Basic Backup

[Tommes]

Was du alles so rausfindest. Respekt. Daher an dieser Stelle meinen Dank an dich und das du deine Erkenntnisse hier mit uns teilst. Aber es ist schon verrückt, welche Komplexität hinter dem kleinen Wörtchen rsync so steckt. Vermutet man ja eigentlich nicht.

Ich könnte mir vorstellen, dass mktemp(3) hier den Umlaut in einer anderen Kodierung zurück gibt, und rsync weiß nichts damit anzufangen bzw. kennt somit den Pfad und auch die Datei nicht. Also findet rsync die Datei nicht auf dem Dateisystem.

Das wäre in meinen Augen auf jeden Fall eine mögliche Erklärung. Komisch ist nur, das dieses Phänomen scheinbar keiner Logik folgt, zumal @TJones das wohl nur bei einer Datei mit Umlauten festgestellt hat, obwohl er über mehrere solcher Dateien verfügt. Daher müsste es theoretisch auch mit dem Dateinamen selbst zusammenhängen und wie dieser im Dateisystem abgelegt wird. Hier würde mir dann Inode einfallen… aber das würde jetzt wirklich zu weit führen und ob an diesem Gedanken überhaupt etwas dran ist, sollten wir hier wohl besser nicht mehr diskutieren.

 

[Tommes]

Basic Backup Version 0.6-100 vom 15.03.2022​

(...sobald von den Machern von CPHub freigegeben!)

• Der Status der App-Berechtigung in der Systemumbebung von Basic Backup wurde angepasst.
• Bei der Auswertung, ob ein Auftrag aktuell ausgeführt wird oder nicht, wurden alle Aufträge, die mit dem selben Wortlaut begannen, als aktiv gekennzeichnet. Fehler wurde behoben.
• AutoPilot: Der Aufruf des Scriptes autopilot erfolgt nicht mehr über den Befehl bash.
• AutoPilot: Sollte beim Einstecken eines externen Datenträgers kein Gerätename aus der udev Regel übergeben werden, kein autopilot Script gefunden oder das autopilot Script nicht ausgeführt werden können, wird AutoPilot abgebrochen. Der externe Datenträger wird in diesem Fall nicht ausgeworfen, selbst wenn diese Option aktivert wurde.
• AutoPilot: Beim einstecken eines beliebigen externen Datenträgers auf dem sich aber kein autopilot Script befand, wurde fälschlicher Weise die optische- und akustische Signalausgabe ausgelöst, wenn diese Option aktivert war. Fehler wurde behoben.

Weiterhin viel Spaß mit Basic Backup

Tommes

 

[Tommes]

Ankündigung!​

Aufgrund einiger Diskrepanzen habe ich meine, für DSM 7 geschriebenen Pakete „Basic Backup“ und „LogAnalysis“, aus der alternativen Paketquelle „Community Package Hub“ entfernt. Das hat zur Folge, das diese Pakete nicht mehr über das DSM Paket-Zentrum in ihrer gewohnter Form installiert, sowie aktualisiert werden können.

Mit diesem Schritt will aber keineswegs mein Karriereende als Paketentwickler einläuten, sondern mich einfach neu aufstellen und ausrichten. Das hat natürlich Vor- und Nachteile, sowohl für mich als auch für euch. Der wohl größte Nachteil ist wohl, das die Anzahl an aktiv gepflegten, öffentlich zugänglichen Paketservern über die Jahre sehr stark abgenommen hat. Bei den noch verbliebenen Paketservern stolper ich zuweilen noch über das ein oder andere Hindernis. Ebenso stellt das Betreiben eines eigenen Paketservers für mich keine akzeptable Lösung da. Was also tun?

Ich kann für den Moment noch nicht genau abschätzen, wohin mich der Weg letztendlich führen wird, da ich auch weiterhin auf der Suche nach einer neuen Heimat für meine Pakete bin. Für die Übergangszeit habe ich meinen Blick jedoch auf GitHub gerichtet und dort meine beiden Pakete als Repository für euch deponiert. Leider lässt sich solch ein Repository nicht als Paketquelle in das DSM Paket-Zentrum integrieren, weshalb die eigentliche Installation sowie zukünftige Paket-Updates bis auf weiters vorerst manuell ausgeführt werden müssen.

Als kleines Trostpflaster konnte ich dank eines wertvollen Tipps von @geimist zumindest erreichen, das euch mögliche Paket-Updates automatisch innerhalb der jeweiligen App angezeigt werden. Folgt ihr dann dem aufgeführten Link, gelangt ihr zu dem aktuellen Release auf GitHub, wo ihr euch das Update dann herunterladen könnt um es im Anschluss manuell über das DSM Paket-Zentrum zu installieren. Ich halte das für einen guten Kompromiss sowie einem gangbaren Weg und ich hoffe, ihr seht das genauso.

Lange Rede, kurzer Sinn. Hier also der jeweilige Link zum Reopsitory…

Basic Backup
https://github.com/toafez/BasicBackup

LogAnalysis
https://github.com/toafez/LogAnalysis

Und falls ihr euch wundert. Mein Benutzername bei GitHub lautet nicht Tommes, wie zu erwarten wäre, sondern toafez. Der Name Tommes war leider schon vergeben.

Ach ja, bevor ich’s vergesse. Die für DSM 6 geschriebenen Pakete „LogAnalysis“ und „Ultimate Backup“ werden bis auf weiteres auch weiterhin über CPHub angeboten und können über das DSM Paket-Zentrum in gewohnter Form installiert sowie aktualisiert werden. Ob es hier jedoch noch zu Aktualisierungen kommen wird lass ich für den Moment mal offen.

Tommes

 

[Anthracite]

Diesen Pfad / Datei

/20170410_Dam\#303\#274ls/.20170410114.NEF.QyIAPg

gibt es bei mir nicht. Ich habe gerade bewusst noch einmal auf dem Server nachgeschaut. Keine Ahnung, wo dieser Pfad und Dateiname herkommt?

Solche Dateinamen mit den seltsamen Endungen entstehen u. A. kurzfristig beim Löschen von Dateien auf einem Netzlaufwerk. Es ist also denkbar, dass die Datei gerade in dem Moment gelöscht wurde, als rsync darauf zugegriffen hat. Das würde die seltsame Fehlermeldung erklären, und auch warum du die Datei danach nicht mehr gefunden hast.

Die Lösung besteht darin, vor dem Backup einen Snapshot anzulegen und dann diesen Snapshot zu sichern.

Die einfache Alternativlösung ist, den Fehler einfach zu ignorieren. Dieses Zusammentreffen ist recht selten, und das nachfolgende Backup wird dann wieder fehlerfrei durchlaufen.

 

[pelumu]

Ich habe gerade die 0.6-200 installiert und eine USB-Festplatte mit autopilot-Script angeschlossen. Das Backup wird aber nicht gestartet.
Kann ich irgendwo sehen, warum das Backup nicht gestartet wird?

 

[Tommes]

Ich kann grad keine Screenshots machen, daher versuche ich es so.

Auf der Startseite von Basic Backup findest du als ersten Eintrag die Systemumgebung. Wenn duda drauf klickst, öffnet sich nach unten ein Menü! Dort findest du dann den Punkt AutoPilot Status und rechts daneben ein Symbol, was aussieht wie ein beschriebenes Blatt Papier. Klickst du da drauf, öffnet sich ein Protokoll. Vielleicht wirst du dort fündig.

Es könnte auch sein, das du AutoPilot noch nicht konfiguriert hast. Dazu oben im Menü vom Basic Backup bitte mal auf Systemeinstellungen > USB/SATA-AutoPilot und schau dir die Einstellmöglichkeiten an.

 

[pelumu]

Das steht im Log:
2022-04-07 10:45:55 /dev/sdq1 - Das Script /volumeUSB1/usbshare/autopilot konnte nicht ausgeführt werden!
2022-04-07 10:45:55 /dev/sdq1 - Der externe USB/SATA-Datenträger bleibt eingehängt.

Was könnte die Ursache sein, dass das Script nicht ausgeführt werden konnte?

 

[Tommes]

Was genau steht denn in dem Script? Funktioniert der Auftrag, wenn du diesen über den Aufgabenplaner bzw. über die Konsole ausführst?

 

[pelumu]

Der Inhalt der Datei autopilot sieht folgendermaßen aus:
#!/bin/bash
bash /usr/syno/synoman/webman/3rdparty/BasicBackup/rsync.sh --job-name="BackupExtern4"

Über den Aufgabenplaner wird das Backup problemlos ausgeführt.

 

[Tommes]

Ah, okay. Sehr wahrscheinlich fehlt dem autopilot Script das Attribut zum Ausführen. Schau dir in der File Station bitte mal die Berechtigungen für die Datei autopilot an. Das sollte dann so aussehen...



Falls dem nicht so ist, dann bitte einmal einen rechtsklick auf die Datei machen, im Auswahlmenü auf Eigenschaften klicken und anschließend in den Reiter Berechtigungen wechseln. Dann alle Checkboxen anhaken und speichern anklicken.



Theoretisch sollte das Script dann automatisch starten.

Tommes

 

[pelumu]

Das Script wird jetzt nach der Änderungen der Berechtigungen ausgeführt und das Backup läuft.
Was noch nicht funktioniert ist, dass die USB-Platte automatisch ausgeworfen wird. An was könnte das liegen?

 

[Tommes]

Erstmal schön, das das Script nun läuft. Ich werde die Anleitung auf GitHub sowie innerhalb Basic Backup am WE dementsprechend anpassen.

Warum der Datenträger nicht automatisch ausgeworfen wird kann viele Gründe haben. Zuerst ist aber auch hier die Auswertung des Protokolls die erste Anlaufstelle.

Das auswerfen dauert auch einen Moment, je nach NAS System kann das auch mal eine gute Minute oder länger dauern. Daher wäre der erste Tipp, einfach ein wenig länger zu warten.

Dann kommt es darauf an, was du in Basic Backup konfiguriert hast. Immer automatisch auswerfen, oder nur bei einem exit 100 im Script.

Evtl. wurde das Script bzw. der Backupjob auch mit Fehlern beendet, weshalb der Datenträger deshalb nicht ausgeworfen wurde.

Manchmal liegt es aber auch einfach am Datenträger selber… wobei das eher die Ausnahme ist.

Tommes

 

[pelumu]

Erstmal vielen Dank für Deine super und immer ultra schnelle Hilfe!

In den Systemeinstellungen ist das "immer automatisch auswerfen" angehakt.
Im Systemprotokoll ist kein Fehler vermerkt.
Das Backup wurde ohne jeglichen Fehler laut Protokoll durchgeführt.
Auch nach längerer Zeit wird die USB-Platte nicht ausgeworfen.

Grüße
Peter

 

[Tommes]

Interessant wäre zu erfahren, ob bei dir das Auswerfen mit einen anderen USB Datenträger funktioniert. Vielleicht magst du das irgendwann mal testen und hier Feedback geben. In der Zwischenzeit versuche ich herauszufinden, warum das Auswerfen manchmal nicht funktioniert. Bestenfalls wird das in einem Logfile protokolliert…

 

[pelumu]

Ich habe es jetzt mit einer zweiten USB-Platte probiert, einmal mit NTFS und einmal mit Ext4 formatiert. Die Platte wird in keiner Konstellation ausgeworfen.

 

[sccsmz]

Hallo Tommes,
ich habe nach deiner guten SSH Anleitung meine zwei Synos mit einander verbunden.
Da aber auf beiden das Let's Encrypt Zertifikat als Standart läuft, das sich ja immer wieder nach einer Zeit aktualisiert, bekomme ich jetzt natürlich einen SSH Fehler:
Datensicherungsauftrag abgebrochen! Die SSH-Verbindung zum Remote Server ist fehlgeschlagen!
Datensicherungsauftrag abgebrochen! Die Verbindung zum Remote Server ist fehlgeschlagen.
Gibt es eine Möglichkeit immer das aktuelle Let's Encrypt Zertifikat als SSH einzubinden?
Oder wie machst du das?

Gruß Christoph

 

[luddi]

Gibt es eine Möglichkeit immer das aktuelle Let's Encrypt Zertifikat als SSH einzubinden?

Weshalb hat das mit dem Zertifikat zu tun? SSH ist doch keine Webanwendung und verwendet hier kein Lets Encrypt Zertifikat.

Jetzt wäre eigentlich das log interessant weshalb die SSH Verbindung nicht zustande kommt.

 

[sccsmz]

wo finde ich denn das log?

 

[luddi]

Das Datensicherungsprotokoll wie du es in deinem Bild zeigst liegt auf dem System unter folgendem Pfad
/usr/syno/synoman/webman/3rdparty/BasicBackup/usersettings/logfiles

Aber der Inhalt ist exakt der gleiche was dir ohnehin schon in der GUI angezeigt wird.

Es gibt aber noch den Optionsschalter -vvv der dir mehr Details im Logfile liefern wird.
Einfach die Aufgabe im Aufgabenplaner oder über die Kommandozeile mit -vvv ergänzen und nochmals laufen lassen.

Hier müsste uns @Tommes helfen ob auch noch weitere debug Infos vorliegen als nur über den Optionsschalter.

EDIT:
Ach ich sehe gerade dass dies eigentlich nur weitere Details für das rsync Protokoll liefert.

 

[Tommes]

@pelumu
Ich teste das die Tage nochmal und werde berichten.

@luddi
Ich sollte vielleicht mal einen Optionsschalter einbauen, der ein Verbose für SSH bereitstellt und die Ausgabe im Protokoll ausgibt. Ich schau mir das die Tage mal an, sollte ja nicht so das Problem sein. Bis dahin könnte @sccsmz eine SSH Verbindung über die Konsole zum Remote Server aufbauen und dabei ein -v mitgeben.