rsync Kompatibilitätsproblem? Alte Routinen laufen, neue können nicht angelegt werden

Status
Für weitere Antworten geschlossen.

418553

Benutzer
Mitglied seit
26. Mai 2015
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Guten Tag,

ich habe leider seit DSM 5 ein Problem mit der Erstellung von RSYNC kompatiblen Sicherungen.

Vorweg - ich besitze 3 Synology NAS (EDS14/DS213+/DS213+) plus weitere Geräte anderer Hersteller. Alle sind auf aktuellstem Software/Firmwarestand. (DSM 5.2-5565 Update 1)

Die WebGUI (DSM-Webinterface scheint rsync Sicherungen nicht "sauber" anzulegen.)

Anhang anzeigen Rsync_Problem.pdf

a) Sicherungsziel (Netzwerk) rsync-kompatibel mit User / Pass wird angelegt und Ziel ist anschliessend auch Verfügbar (online)
b) Eine Sicherungsaufgabe kann nicht angelegt werden da offensichtlich das Schreiben im rsync Storage nicht funktioniert.
c) Eine Sicherung per Shell "> rsync -a --timeout=600 /volumeUSB1/usbshare1-1/@sharebin/photo root@10.0.0.14::TEST/123/
Password" funktioniert und der notwendige Ordner wird im Rsync Sicherungsziel auch angelegt.


Folgende Szenarien sind getestet:

a) Iomega ix2-200 Sicherung per rsync auf QNAP --> OK
b) Synology Sicherung per rsync Kommandozeile auf QNAP --> OK
c) Synology Sicherung per "Sicherungsaufgabe" (Einrichtung per Web-GUI DSM) auf QNAP --> schlägt fehl - gemäß Beschreibung oben.

Einer meiner Synology NAS (DS213+) hat noch einen "alten" Sicherungsjob der vor Update auf DSM5.x erstellt wurde laufen. Ohne Probleme! Ein weiteren kann ich dort nicht anlegen. Auch dieser Versuch per Assistent einen Job anzulegen schlägt fehl wie oben.

Da das Log keine Auskünfte erteilt (keine Logeinträge vorhanden nach Fehlermeldung) kann ich hierzu keine weiteren Angaben machen. Aber Schreibrechte sind alle im Qnap korrekt gesetzt - sonst würden die anderen Routinen nicht durchlaufen (777)


Hardware:

a) QNAP Rsync Server aktiviert und per statischer IP verfügbar. (Benutzername / Passwort aktiviert)
b) Iomega ix2-200 als rsync client zur Sicherung auf a) QNAP
c) diverse Synology Clients zur Sicherung auf QNAP (rsync kompatibel)

Weiss hier jemand Rat, oder ist dieses Problem bekannt?

Habe den QNAP schon komplett zurückgesetzt und auch schon eine der Synologys - ohne Abhilfe. Problem besteht weiterhin.

Herzlichen Dank für Euren Support

CU Steve
 

418553

Benutzer
Mitglied seit
26. Mai 2015
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Update:

Habe mittlerweile via: tail /var/log/rsync.error ein Log gezogen.

Ich bekomme immer folgende Fehlermeldungen - werde aber keineswegs schlauf daraus - kann hier jmd. helfen ??

NAS4> tail /var/log/rsync.error
Jun 02 17:40:37 (20025) [ERROR]: rsync error: unexplained error (code 255) at io.c(687) [Receiver=3.0.9]
Jun 02 17:42:01 (20408) [ERROR]: rsync error: unexplained error (code 255) at io.c(687) [Receiver=3.0.9]
Jun 02 17:42:36 (20599) [ERROR]: rsync error: unexplained error (code 255) at io.c(687) [Receiver=3.0.9]
Jun 02 17:43:36 (20863) [ERROR]: rsync error: unexplained error (code 255) at io.c(687) [Receiver=3.0.9]
Jun 02 17:45:34 (21365) [ERROR]: rsync error: unexplained error (code 255) at io.c(687) [Receiver=3.0.9]
Jun 02 17:45:34 (21367) [ERROR]: rsync error: unexplained error (code 255) at io.c(687) [Receiver=3.0.9]
Jun 02 17:45:51 (21424) [ERROR]: rsync error: unexplained error (code 255) at io.c(687) [Receiver=3.0.9]
Jun 02 17:47:43 (21905) [ERROR]: rsync error: unexplained error (code 255) at io.c(687) [Receiver=3.0.9]
Jun 02 17:47:56 (21946) [ERROR]: rsync: change_dir "/NAS4_1" (in RSYNC) failed: No such file or directory (2)
Jun 02 17:47:56 (21946) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]

Schreibrechte sind gesetzt und der rsync Speicher wird als "Online" angezeigt.

Lege ich den Ordner manuell an bekomme ich den gleichen Fehler.....

Danke Euch !
 

nikthegreek

Benutzer
Mitglied seit
07. Jun 2015
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
Habe original das gleiche Problem mit DS214Play und einem QNAP TS-459 Pro+.
Bin auch schon am verzweifeln.
Ein alter Job der eingerichtet war lief einwandfrei. Ich wollte ihn ändern (einen Ordner zusätzlich mit in die Sicherung nehmen) und da tauchte der Fehler das erste mal auf. Die alte Sicherungsauftrag lief dann seit der Änderung nicht mehr. Löschen des Sicherungsauftrages und des Zieles und ein erneutes Konfigurieren haben leider auch keinen Erfolg gebracht.

Wäre auch um Hilfestellung dankbar.
Danke!
 

418553

Benutzer
Mitglied seit
26. Mai 2015
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Hi nikthegreek,

ich finde es auch spannend dieses Problem. Fakt ist auch, dass der Synology Support sich bislang dazu ausschweigt!

Viele lesen hier offensichtlich mit, aber es wird nicht richtig adressiert :- (

Wer hat denn noch dieses Problem? Wir beide sind doch keine Einzelfälle, oder doch ?!

Cya
Steve
 

hvkls

Benutzer
Mitglied seit
23. Dez 2012
Beiträge
463
Punkte für Reaktionen
0
Punkte
22
Ich habe das Problem nicht, weil ich den Mechanismus nicht nutze. Aber der funktionierende Job muss doch $irgendwo vermerkt sein. Wenn man dort nachsieht, könnte man doch wahrscheinlich einen ähnlichen zweiten anlegen?
 

418553

Benutzer
Mitglied seit
26. Mai 2015
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Hallo hvkls,

leider nein. Der "alte Job" ist natürlich da und auch einsehbar.

Lege ich einen neuen identischen "Klon" an, sogar mit identischem Ziel --> funktioniert er nicht. (wird abgebrochen mit obigem Felherbild)

Das scheint eine Änderung der Web-GUI Routinen durch DSM Update mit sich gebracht zu haben. Der Job wird "anders" angelegt.

CU Steve
 

hvkls

Benutzer
Mitglied seit
23. Dez 2012
Beiträge
463
Punkte für Reaktionen
0
Punkte
22
Das hattest du vorher ja genau beschrieben :) Ich meinte, ob man nicht jenseits des GUI, also per CLI, nachschauen könnte, als was bzw. wie der existierende Job abgespeichert ist, um von Hand, ohne GUI, einen weiteren hinzuzufügen.
 

418553

Benutzer
Mitglied seit
26. Mai 2015
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Hi,

gute Idee! Und muss in der der Theorie auch funktionieren ;-)

Mein Anliegen wäre es eher perspektivisch Synology dahin zu bringen das problem zu fixen! Dafür habe ich eine GUI drauf - und vor allem funktionierte Sie "vor dem Update" offensichtlich einwandfrei.

Ich habe mir eine weitere DS414er hingestellt und das Problem somit nach hinten verschoben. Dennoch möchte ich meine QNAP für diese Sicherungszwecke in Verbindung mit meinen Synos auch irgendwann mal wieder benutzen können :-(

BTW: Ne Idee wo die Jobs abgelegt werden ?

CU St.
 

hvkls

Benutzer
Mitglied seit
23. Dez 2012
Beiträge
463
Punkte für Reaktionen
0
Punkte
22
Es dürfte sich um einen Bug handeln. Hast du den Synology schon mitgeteilt? Leider habe ich die Formular-URL nicht zur Hand.

Wo ich ad hoc nach Konfigurationen suchen würde, ist /var/packages/*/etc und /var/packages/*/scripts, /usr/syno samt Unterverzeichnissen sowie sicherheitshalber /etc. Ganz durchblicke ich das System dahinter nicht, unterstelle aber mal, dass es eins gibt <g>
 

nikthegreek

Benutzer
Mitglied seit
07. Jun 2015
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
Hi,

gute Idee! Und muss in der der Theorie auch funktionieren ;-)

Mein Anliegen wäre es eher perspektivisch Synology dahin zu bringen das problem zu fixen! Dafür habe ich eine GUI drauf - und vor allem funktionierte Sie "vor dem Update" offensichtlich einwandfrei.

Ich habe mir eine weitere DS414er hingestellt und das Problem somit nach hinten verschoben. Dennoch möchte ich meine QNAP für diese Sicherungszwecke in Verbindung mit meinen Synos auch irgendwann mal wieder benutzen können :-(

BTW: Ne Idee wo die Jobs abgelegt werden ?

CU St.



Dann hätte ich mir lieber ein zusätzliches QNAP gekauft. Ich rufe mal am Montag den Support an. Sollte das keine Lösung bringen. Dann geht die DS auf den Müll. Habe in der Firma mehrere QNAPs. Da hat es noch nie irgendweloche Probleme gegeben....

BTW: sehe gerade da gibts gar keine Support Hotline, oder habe ich die nur übersehen???
 

IPNS

Benutzer
Mitglied seit
10. Jun 2013
Beiträge
68
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,
ich habe genau das gleiche Problem.
Hat bis zum Update auf DSM 5.2 problemlos funktioniert.
Gibt man die rsync-Befehle auf der Console ein, funktioniert das Backup. Inzwischen habe ich auch mit einer Auswertung von Synology gefunden, dass von der Synologysoftware die rsync-Befehle falsch gesendet werden. Es werden nämlich nicht die unter Backupziel eingetragenen Credentials sowie Backupmodul geschickt, sondern der User root mit Passwort. Damit lehnt der entfernte Server natürlich den Zugriff ab.

Der Befehl der zunächst aus der GUI gesendet wird ist:

rsync -avvv --list-only root@<ip-rsync-Server>::NetBackup

Falsch ist der User root und das Backupmodul NetBackup(bei Datensicherungsziel wurde ein anderer User und ein anderes Backupmodul ausgewählt/eingegeben).

Legt man das Datensicherungsziel an (mit richtigem User der QNAP) kann man die BackupModule der QNAP auswählen. Nur verwendet die GUI dann immer root und NetBackup.
Die Ursache ist somit eigentlich klar und eindeutig. Ich habe dazu seit Update auf 5.2 ein Ticket offen, aber Synology ist nicht in der Lage das Problem zu lösen.
 

LeMiu

Benutzer
Mitglied seit
18. Sep 2015
Beiträge
1
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich habe auch dieses Problem.

ich habe versucht auf QNAP einen gemeinsamen Ordner mit dem Namen "NetBackup" zu erstellen und als Benutzername "root" zu verwenden. Hat aber nichts gebracht. Der Zufriff auf dem erfolgreich erstellten Datensicherungsziel scheint nicht möglich zu sein.
 

IPNS

Benutzer
Mitglied seit
10. Jun 2013
Beiträge
68
Punkte für Reaktionen
0
Punkte
0
Update:

Jun 02 17:47:56 (21946) [ERROR]: rsync: change_dir "/NAS4_1" (in RSYNC) failed: No such file or directory (2)
Jun 02 17:47:56 (21946) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]

Schreibrechte sind gesetzt und der rsync Speicher wird als "Online" angezeigt.

Es liegt definitiv nicht an QNAP, auch wenn der Synology Support das behauptet.
Den einizigen "Fehler" den QNAP macht ist, dass bei nicht exisitierendem Verzeichnis neben der Meldung "no such file or directory" auch eine Meldung "rsync service is no running" ausgibt. Das ist Quatsch, weil rsync ja läuft.

Das es definitiv nicht an QNAP, irgend welchen Rechteeinstellungen, etc. liegt kann ausgeschlossen werden, da eine Sicherung über die Shell, z.B. mit
rsync -avz –delete --progress /volume1/Arbeitsmittel/ rsyncipn@<ip-Adresse>::Backup/Arbeitsmittel/
einwandfrei funktioniert.

Daraus ergibt sich eindeutig folgender Sachverhalt:
1. Die GUI erkennt die eingegebenen Credentials und zeigt die richtigen Backupmodule des Zielservers an
2. Ein Backup über die Shell mit o.g. Befehlszeile funktioniert

Daraus folgt: Die Umsetzung aus den in der GUI eingegebenen Daten zu einem rsync-Befehl scheint falsch zu sein.
 
Zuletzt bearbeitet:

asc-de

Benutzer
Mitglied seit
20. Jul 2015
Beiträge
19
Punkte für Reaktionen
3
Punkte
3
Die Ursache ist somit eigentlich klar und eindeutig. Ich habe dazu seit Update auf 5.2 ein Ticket offen, aber Synology ist nicht in der Lage das Problem zu lösen.

kann ich so bestätigen! Ich bin zwar immer noch bei Update 2 aber bei Update 3 und 4 erscheint nichts im Chancelog daß sich im Bereich rsync was verbessert hat
 

tokon

Benutzer
Mitglied seit
12. Dez 2015
Beiträge
192
Punkte für Reaktionen
41
Punkte
28
Spiele mit dem Gedanken mir zu meiner QNAP eine Synology zu holen. Dann wäre die Syno das Haupt-NAS und QNAP das Backup-NAS.

Ist dieses Problem mittlerweile behoben?
 

asc-de

Benutzer
Mitglied seit
20. Jul 2015
Beiträge
19
Punkte für Reaktionen
3
Punkte
3
Spiele mit dem Gedanken mir zu meiner QNAP eine Synology zu holen. Dann wäre die Syno das Haupt-NAS und QNAP das Backup-NAS.

Ist dieses Problem mittlerweile behoben?
Ja ist seit DSM Version: 5.2-5644 behoben und die Sicherung auf die QNAP HS-251 läuft Prima
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat