Zugriff auf Ziel verweigert

[Esteban1]

Hallo in die Runde,

ich habe gestern Hyper Backup-legacy (rsync, dateibasiert) ausprobiert. Nach vielen Stunden des Sicherns, kurz vor Ende bei 99%, kam folgende Meldung: Rotes Ausrufezeichen und "Fehlgeschlagen, Zugriff auf Ziel verweigert"??? Soweit ich auf dem Ziel-NAS ersehen konnte sind aber die Ordner und Dateien angekommen. Vor hatte ich das "einfache" Hyper Backup (datenbankbasiert) benutzt und das funktionierte einwandfrei, ohne Fehlermeldungen. Kennt das VBerhalten jemand von Euch? Mache ich etwas falsch, oder ist das ein Bug?

Gruß und einen schönen Sonntag noch,
Esteban 1

Ergänzung: Quell-NAS ist DS216+ mit DSM 6.0-7321 Update 2, Ziel-NAS DS115

 

[PsychoHH]

Keine Ahnung woran es liegt, kannst du das Backup jetzt nicht wieder zurückspielen oder auf die Daten zugreifen?

Ich finde Hyper Backup ist nicht ausgereift und Synology hätte das noch nicht als stabil kennzeichen sollen.

Eventuell ist unser Projekt ja etwas für dich, Dateibasiert per rsync:
http://www.synology-forum.de/showth...cherung/page25&p=621929&viewfull=1#post621929

 

[Thonav]

Problem ist ganz einfach. In der Zeit in der das Backup gelaufen ist, sind Dateien geändert oder hinzugekommen. Schmeiß das Backup nochmal an - es werden nun die geänderten Dateien hinzugefügt.

@Psycho: Halte Dich bereit - will gegen 15 Uhr Euer Tool ausprobieren

 

[Esteban1]

Danke für den Tipp @Thonav, klappt!

Gruß
Esteban1

 

[Thonav]

Freut mich - gerne

 

[independence2206]

Ich hab das gleiche Problem wie der TE. Bei mir bricht der Hyper Backup RSYNC Job irgendwann mit dem Fehler "Zugriff auf Ziel verweigert" ab. Allerdings habe ich nicht wie der TE in der Zeit des Backups an den Daten etwas geändert. Hat jemand eine Idee? Teilweise werden Daten verschoben. Also grundsätzlich ist eine Verbindung da und scheinbar auch die passende Berechtigung. Nur irgendwann bricht der Job einfach ab.

 

[Fusion]

@independence2206 - hast du versucht den Job neu zu starten, oder hast es gar nicht versucht, weil du davon ausgehst, dass an der Quelle nichts verändert wurde?

 

[independence2206]

Hi,
ich habe den Job schon mehrfach neu gestartet und das Problem kommt immer wieder. Das Protokoll im Hyper Backup ist leider ziemlich spärlich im Bezug auf Infos wieso es zu dem Fehler kam.
1. Entweder keine ausreichenden Berechtigungen ---> schließe ich aus, da ja ein wenig Kram kopiert wird
2. Ungültiger Dateiname --> kann natürlich sein, aber ich wüsste nicht wie ich das nachprüfen soll bzw. wie ich rausfinden sollte welche Datei ungültig ist
3. Zu langer Dateinamen --> kann natürlich auch sein, aber da weiß ich auch nicht wie ich das rausfinden soll. Im Quellverzeichniss ist die Ordnerstruktur minimal flacher, da im Hyper-Backup-Zielordner ja zwangsweise ein Ordner mit der Sicherung angelegt wird und darin wird der komplette ursprüngliche "gemeinsame Ordner" abgebildet.. Sprich in Summe ca. 20 Zeichen mehr als im Quellverzeichnis. Aber auch hier weiß ich nicht wie ich die betreffende zu lange Datei finden sollte..

Es handelt sich bei dem Ordner um mp3s und das sind direkt mehrere 10000 Stk.

 

[Fusion]

Hast du verschiedene Backup-Typen probiert?
Wenn das ein lokales Backup ist, würde ich mal versuchen in 4 Stück a 2500 Dateien aufzuteilen und sehen, welches dann fehlschlägt und so weiter.

Nach Umlauten und problematischen Unicode Zeichen wüßte ich jetzt nur die Suche via SSH/Telnet Terminal.

Ist Quelle und/oder Ziel ein verschküsselter Ordner?
Mit normalen Ordnern kann ich mir nicht vorstellen, dass die Namen zu lang werden.

 

[independence2206]

Leider ist es kein lokales Backup, sondern ein Remote-Backup dateibasiert.

Die Quelle ist nicht verschlüsselt aber das Ziel schon. Ich backupe gerade auf dem gleichen Ziel-NAS noch einen anderen Ordner. Da ist die Ordnerstruktur noch flacher. Wenn das also durchläuft sollte es wohl tatsächlich an einem zu langen Dateinamen oder an einem komischen Dateizeichen liegen. Leider weiß ich nicht wie ich dann das fehlerhafte Element finde außer in äußerst mühevoller Kleinstarbeit

EDIT: Ich habe jetzt gerade nochmal einen weiteren identischen Backup Job angelegt. Gleiche Quelle, gleiches Ziel nur mit wesentlich weniger Daten. Das läuft problemlos durch. Also das das Ziel ein verschlüsselter Ordner ist, ist scheinbar auch kein Problem

 

[Fusion]

Dass verschlüsselt prinzipiell ein Problem wäre meinte ich auch nicht, aber sind dort z.B. die Pfad/Dateinamenlängen begrenzt im Vergleich zu unverschlüsselten Ordnern.
Bin mir bis heute nicht sicher, ob sich die genannten 143 Zeichen dort auf den Dateinamen alleine oder den gesamten Pfad beziehen.
Auch da fällt mir nur die Konsole ein, mit der man dann alles Pfade oder Dateien suchen und deren Länge bestimmten kann.

 

[independence2206]

Darüber, dass bei einem verschlüsselten gemeinsamen Ordner ein wesentlich kürzerer Dateinamen (Pfad) angegeben werden muss weiß ich, habe ich irgendwann mal gelesen. Aber das sollte nicht unbedingt hier zutreffen. Ich werde jetzt mal die 3 Backupjobs durchlaufen lassen und schauen wie sich die anderen verhalten. Bei dem der aktuell läuft ist die Ordnerstruktur flach, da sollte es klappen. Sind aber über 200 GB zu uploaden. Ich berichte wieder

 

[independence2206]

So,
ich komme der Lösung ein wenig näher. In der vergangenen Nacht konnte nach dem Kopieren von über 100GB Daten (Upload) ein Sicherungsjob erfolgreich durchlaufen. Identisch mit dem Job, der mir seit ein paar Tagen Kopfzerbrechen bereitet. Das bedeutet ja schon einmal, dass die Einstellungen passen und es grundsätzlich klappt. Berechtigungen sind also auch iO.
Jetzt liegt es an zu langen Dateipfaden/Namen oder an ungültigen Dateinamen:
Das Thema mit den langen Namen habe ich wahrscheinlich gelöst, denn ich habe mit der Software Path Finder alle Dateinamen > 200 Zeichen manuell gekürzt. Problem jedoch noch da. Also liegt es wohl an ungültigen Namen.
Aktuelles Problem: Wie finde ich denn raus, was ein ungültiger Dateiname ist?!

 

[Fusion]

Grenze für Dateinamen in verschlüsselten Ordnern war wie erwähnt 143 Zeichen.

Zum finden von Umlauten und problematischen Sonderzeichen
https://forum.ubuntuusers.de/topic/umlaute-in-videodateien-ersetzen/#post-7076493

 

[independence2206]

Ach stimmt, die Begrenzung bei verschlüsselten Ordnern ist ja nochmal geringer. Danke für den Hinweis. Ich habe dann nachgeschaut und hätte hunderte Dateien kürzen müssen. Das war mir deutlich zu anstrengend und ich habe ein unverschlüsselten gemeinsamen Zielordner gewählt. Das Backup ist dann heute Nacht durchgelaufen - somit hat es wohl tatsächlich ausschließlich an der Dateinamenlänge gelegen.

@ Fusion: vielen Dank für den Support.