Basic Backup Basic Backup

[bonito]

Im root Verzeichnis waren keine mount Leichen.
In dem Auftrag erschienen in der Combobox keine "anderen" USB Laufwerke.

Entsprechend wird der Auftrag beim Einhängen des USB Laufwerks gestartet und ausgeführt, aber das Laufwerk konnte nicht abgemeldet werden.

Ich will ja nicht nerven ... so schlimm ist das nicht.

 

[Tommes]

Du nervst absolut nicht, auch wenn ich schon zweimal behauptet habe, das du anstrengend bist. Ich hab halt einen seltsamen Humor.

Mich nervt nur, das das bei mir funktioniert, aber bei dir nicht. Das ist zum Haare raufen.

Da du dich auf der Konsole ein wenig auszukennen scheinst, versuch doch mal, den Datenträger bzw. die Partition von Hand zu trennen. Am besten gaukelst du den umount erstmal nur vor mit...

umount --fake -v /volumeUSB1/usbshare1-1

... gefolgt von einem ...

echo $?

Sollte dort eine 0 stehen,dann lass die Option --fake mal weg und wiederhole den Vorgang. Achtung! Dadruch wird die Partition getrennt. Also...

umount -v /volumeUSB1/usbshare1-1
echo $?

Tommes

 

[Benares]

@bonito, du stehst aber nicht zufällig als mit dem Explorer, Filestation oder der Konsole auf dem Share und schaust zu, wie dein Backup wächst?

 

[bonito]

Ne das wäre ja dämmlich

 

[bonito]

Das andere versuche ich bei Gelegenheit ...

 

[Tommes]

Wie gesagt… es wird nur eine einfacher umount im Script abgesetzt und dann dessen Exit Code verarbeitet. Wenn der Exit Code nicht 0 ist, ist beim umount irgendwas schief gelaufen und das Script unterbricht an dieser Stelle alle weiteren Aktionen um den Datenträger zu trennen und auszuwerfen. Die Frage ist daher, warum erhältst du kein exit 0? Ich fürchte, das nur du diese Frage beantworten kannst. Andernfalls müsste ich ein Debugging in AutoPilot einbauen, um alle einlaufenden Exit Codes aufzufangen und zu bewerten.

Alternativ sehe ich mich mal um, da Synology wohl eigenen Tools, Scripte und/oder Programme verwendet um Datenträger zu verarbeiten. Das kann aber wieder etwas dauern und da kann ich auch noch nicht abschätzen, wohin die Reise da gehen wird.

Aber wie immer… Ich kümmer mich, denn ich will ja auch, das alles und zu jeder Zeit funktioniert. Und sollte diese nicht der Fall sein, sollte man durch Debugging den Fehler so weit mich möglich versuchen, einzugrenzen.

Tommes

 

[Tommes]

Basic Backup Version 0.7-210 vom 18.03.2023​

Release Notes​

• Das Trennen und Auswerfen, ext. Datenträger wird nun durch den von Synology eigens bereitgestellten Befehl synousbdisk übernommen.
• Nach der Ausführung von synousbdisk wird dessen Systemrückmeldung im AutoPilot-Protokoll angezeigt, wie z.B. „Unmount USB device usb1 succeeded.“, sollte das Auswerfen erfolgreich gewesen sein.
• Einlaufende Exit Error Codes, die beim fehlerhaften Ausführen des AutoPilot-Scriptes auftreten können, werden ebenfalls im AutoPilot-Protokoll angezeigt.
• Die mit AutoPilot verbundenen Sprachdateien, wurden optimiert.

GitHub Repository​

GitHub Download Link​

@bonito
Wie in den Release-Notes zu entnehmen, habe ich das Trennen und Auswerfen ext. Datenträger nochmal angepasst. Ich hoffe, das damit deine Probleme gelöst wurden, denn langsam gehen mir die Ideen aus. Ich würde mich freuen, wenn du das noch mal testen würdest und mir entsprechendes Feedback über Erfolg oder Misserfolg geben könntest.

Weiterhin viel Spaß mit Basic Backup

Tommes

 

[bonito]

-------------------------------------------------------------------------------------------------------------------
2023-03-19 14:22:18 - AutoPilot wird ausgeführt
-------------------------------------------------------------------------------------------------------------------
Externer Datenträger erkannt!
Datenträgername: usb1
Gerätename: /dev/usb1p1
UUID: 0ebef2b2-0bdd-4d7f-8beb-e2331b1c666c
Einhängepunkt: /volumeUSB1/usbshare
Suche AutoPilot-Script...
Das AutoPilot-Script wurde gefunden und wird ausgeführt
Bitte warten...
Das AutoPilot-Script wurde erfolgreich ausgeführt!
Der externe Datenträger wird ausgeworfen...
Systemrückmeldung:~# Unmount USB device usb1 succeeded.
Der externe Datenträger wurde erfolgreich ausgeworfen!
-------------------------------------------------------------------------------------------------------------------
2023-03-19 14:22:40 AutoPilot beendet
-------------------------------------------------------------------------------------------------------------------

 

[Tommes]

@bonito
Hammer! Du hast mir den Tag gerettet und ich kann endlich wieder beruhigt schlafen.

Vielen Dank fürs Testen und zurückmelden.

Tommes

 

[bonito]

Ein neues Update ist auf GitHub verfügbar.
Bitte aktualisiere deine Backup Basic Version auf die Version 0.7-250

Auf GitHub ist aber nur Version 210 .... andere Frage, einfach drüber installieren oder uninstall/install?

 

[Tommes]

Basic Backup Version 0.7-250 vom 20.03.2023​

Release Notes​

• iFrame-Unterstützung für DSM 7.2 integriert.
  

GitHub Repository​

GitHub Download Link​

Weiterhin viel Spaß mit diesem Mini-Update und Basic Backup

Tommes

 

[bonito]

Update läuft - danke für das coole Tool ;-)

 

[Huibuu]

Ich hab meine DS220 und DS118 vor einigen Tagen auf die DSM 7.2 upgedatet und in dem Zuge BasicBackup (0.7-250) installiert.
Der erste Pull-Backup Job ausgelöst von der DS118 hat wunderbar geklappt. Jetzt scheitert es aber beim "Wiederaufleben" der alten Backup-Jobs.
Um die alten Sicehrungsroutinen wieder zu starten, habe ich auch hier ein Pull Backup anlegen wollen.
Im Fenster "Datensicherungsquellen auswählen" führt die Eingabe von mehreren Quellen leider zu einem kompletten Absturz von der DSM Oberfläche. Im BasicBackup kann ich noch hoch und runterscrollen, weiter und zurück geht aber genauso wenig wie Tastatureingaben.

Habt ihr eine Idee wie ich das Problem lösen kann bzw wie ich das Problem erstmal überhaupt ordentlich identifiziere?
Grüße Huibuu

 

[Huibuu]

Jetzt hab ich mir eine DS218 zugelegt, weil ich das obige Problem nicht lösen konnte.

Nun wollte ich Daten mit der DS218 von der DS118 holen.
Soweit habe ich alles nach der BasicBackup Hilfe eingerichtet. Eigentlich sieht alles ganz gut aus, aber der Job wird leider nicht korrekt ausgeführt.

"permission denied (13)" wird im Protokoll ausgegeben.

Sowohl Ziel als auch Quell Ordner sind verschlüsselt.
Da ich den Job mit einem admin Account durchführe, dürfte es auch kein Berechtigungsproblem sein... dürfte, denn es scheint eins zu sein.

Ich hab jetzt rumgegoogelt, hier im Forum gesucht, bin aber beiden Problemen nicht näher gekommen
Kann mir jemand von euch helfen?

 

[Tommes]

Hi!

Der erste Pull-Backup Job ausgelöst von der DS118 hat wunderbar geklappt. Jetzt scheitert es aber beim "Wiederaufleben" der alten Backup-Jobs. […] Jetzt hab ich mir eine DS218 zugelegt, weil ich das obige Problem nicht lösen konnte.

Wenn ich mir immer eine neue Maschine kaufen würde, nur weil eine Anwendung meint rumspracken, würde ich wohl schon lange am Hungertuch nagen.

Da ich den Job mit einem admin Account durchführe, dürfte es auch kein Berechtigungsproblem sein... dürfte, denn es scheint eins zu sein.

Der Job muss im Aufgabenplaner der lokalen DiskStation als root ausgeführt werden.



Tommes

 

[Huibuu]

Hi Tommes,
die Idee ist gut, aber alle Jobs werden bereits als Root ausgeführt.
Ohne root startet der Job ja nicht mal.
Es scheint als ob der Admin-Benutzer, der sich mit dem Remote Nas verbindet dort nicht ausreichend Berechtigung hätte.
Laut Protokoll klappt die Verbindung, aber für die Ordner fehlen ihm die Freigaben.

Die Einstellungen hinsichtlich der Berechtigung meine ich aber vernünftig gesetzt zu haben. Außerdem ist es ja ein Admin-Benutzer.

Bezüglich des Neukaufs, hab die sehr günstig erstanden und die 218 hat mehr Arbeitsspeicher. Vielleicht hilft das beim vorherigen Problem
Grüsse

 

[luddi]

"permission denied (13)" wird im Protokoll ausgegeben.

Nur mal so als Hinweis um den Fehler eingrenzen zu können. Dieser Fehler mit permission denied wird von rsnyc berichtet.

 

[Tommes]

Ohne root startet der Job ja nicht mal.

Das ist in der Tat so, überprüft das Script doch im Vorfeld, ob es als root ausgeführt wird…

# ------------------------------------------------------------------------
# Ceck that the script run only as root
# ------------------------------------------------------------------------
if [ "${whoami}" != "root" ]; then
   ...
   exit
fi

… weshalb es erst garnicht ausgeführt wird, sollte dem nicht so sein. Mein Fehler!

Wie @luddi bereits erwähnte, wird der Exit-Code 13 (permission denied) von rsync ausgelöst. Von daher ist es sehr wahrscheinlich, das hier ein Rechteproblem vorliegt und das dein SSH-Benutzer keine Rechte für die zu sichernden, gemeinsamen Ordner hat. Ich hatte diesen Fehler zuletzt selbst gehabt, als mein Sohn von seiner DS aus, Daten seiner Nextcloud, welche auf einem Raspberry Pi liegen, zu sichern. Am Ende haben wir dann einen SSH root Zugriff auf den Raspberry Pi eingerichtet, damit es funktionierte... was du bei einer Remote DiskStation jedoch nicht so einfach umsetzten kannst. Von daher solltest du dir das mit den Berechtigungen nochmal genauer anschauen und ggfl. ein paar Anpassungen durchführen. Ich werde die Tage aber auch selber noch mal ein paar Tests durchführen, kann ja sein, das Synology mal wieder irgendwas verändert hat. Daher noch die kurze Frage an dich… welche DSM Version verwendest du? Die DSM 7.2 auf beiden Maschine, wie oben beschrieben?

Tommes

 

[Huibuu]

Danke für eure Hilfe.
Ich bin halt nur Anwender und brauche für einige Dinge dann länger bzw. löse ich diese ggf auch falsch.
Als ich rausgefunden habe wie ich die Rechte prüfen konnte, war es tatsächlich so, dass eigentlich kein Benutzter die Rechte an den zu sichernden Ordner hat.
Warum dem so ist, bleibt für mich ein Rätsel. Ich hätte ja aktiv die Rechte des admin-Benutzers in den Ordnern begrenzen müssen!? Oder hat das "alte" UltimateBackup damit etwas zu tun? Weil die zu sichernden Daten sind Daten, die per UB gesichert wurden.

Schlussendlich habe ich nun über die File-Station allen Admins wieder die Rechte eingeräumt und jetzt läuft die Sicherung.
Jetzt nervt mich nur die Sicherungsgeschwindigkeit von einem verschlüsselten Ordner in einen verschlüsselten Ordner (DS118/218). Muss ich mir wohl eine neue DS kaufen @Tommes ;-)
Mal gucken, ob bei der DS218 auch wieder BB abstürzt, wenn ich mehrere Ordner in den Sicherungsjob eintrage...

Falls du trotzdem irgendetwas testen möchtest, Tommes:
Die DS118 wurde ist DSM 6 auf DSM 7.2 gebracht worden und BB ersetzte UB.
Die DS218 läuft auch mit DSM 7.2 und hat ebenfalls das aktuelle BB-Paket.

 

[Tommes]

Hi!

Ich bin halt nur Anwender und brauche für einige Dinge dann länger bzw. löse ich diese ggf auch falsch.

Du hast keine Vorstellung davon, wie lange ich manchmal für Dinge brauche, um sie zu verstehen bzw. um zu verstehen, was mein Gegenüber mir versucht, zu erklären.

Warum dem so ist, bleibt für mich ein Rätsel.

Es gibt Dinge, die sich jeder Logik entziehen und lassen sich oftmals nur schwer rekonstruieren. Das Ultimate Backup etwas damit zu tun hat, bezweifle ich jedoch, kann es aber auch nicht ausschließen.

Schlussendlich […] läuft die Sicherung.

Ziel erreicht! Freut mich, das du (wir) es hinbekommen haben.

Falls du trotzdem irgendetwas testen möchtest, Tommes

Mal sehen… das Rätsel wurde ja enträtselt.

Tommes