Inkrementelles Backup mit RTRR-Job?

    Hallo,


    habe einen RTRR-Job auf ein externes Laufwerk (mit NTFS-Formatierung) für ein Backup eingerichtet.


    Funktioniert soweit, aber es wird nicht inkrementell ausgeführt.


    Finde keine Einstellung dazu unter FW 3.7.3.


    Hab ich da was übersehen, oder ist ein inkrementelles Backup nicht möglich?


    Im Jobprotokoll kann ich folgende Einträge finden:
    Destination does not support changing file mode!
    Destination does not support changing file owner!
    Destination does not support extended attribute!


    Bezüglich der erweiterten Attribute hatte ich die Option angewählt.


    Woher kommen die Protokolleinträge? Fehlen Berechtigungen für das externe Laufwerk?


    Vielen Dank vorab.


    Nachtrag 15.11.2013:
    Habe ich möglicherweise "inkrementell" nicht richtig verstanden?
    Ich möchte bei der Sicherung eine Datei gleichen Namens nicht mit einem geänderten Inhalt überschreiben.

    Zitat von "Halifax"

    Ich möchte bei der Sicherung eine Datei gleichen Namens nicht mit einem geänderten Inhalt überschreiben.


    Dann must Du das Sicherungsprogramm "Externer Datenträger" verwenden, nur in dem lässt sich eine Option anwählen, geänderte Dateien nicht zu überschreiben.


    RTRR überschreibt immer geänderte Dateien im Ziel, kennt also diese Option nicht.


    Falls Du diese Option in einer Netzwerksicherung benötigen würdest, müsstest Du Dir mal RSNAP anschauen, ob das diese zur Verfügung stellt.


    GLG GBD

    OK, die Funktion muss nicht angewählt werden, sondern abgewählt bleiben.


    Die Option "Dateiinhalte prüfen" würde ich abwählen, sonst führt er vor jedem Backup einen bitgenauen Vergleich von Quelle und Ziel durch, was ewig dauert.


    Wenn er dann immer noch mit geänderten Dateien die Sicherungsdateien gleichen Namens überschreibt, obwohl die entweder eine andere Dateigrösse haben oder älter sind, müsste ich mal versuchen, das nachzustellen. Passiert das auf meinen Geräten auch, wäre es vermutlich ein Bug der Firmware.


    GLG GBD

    Vielen Dank GorillaBD für Deine schnellen Antworten.


    Also ich habe heute alle erdenklichen Optionsvarianten probiert und alle bringen das gleiche Ergebnis - alte Dateien werden mit geänderten Dateien überschrieben.


    Wie werden denn normalerweise die Dateien in solch einem Fall umbenannt?


    GorillaBD
    Wie machst Du Deine Sicherungskopien auf Deine WD Books?

    Ich sichere grundsätzlich mit RTRR als "Spiegelsicherung", heisst ich will, dass geänderte Dateien überschrieben werden und auf der Quelle nicht mehr vorhandene auch auf dem Ziel gelöscht werden. Wenn ich eine geänderte Datei von einer vorherigen Version abgrenzen will, gebe ich ihr einen anderen Namen, meist mit einem _v2 am Ende oder ähnliches.


    Ich denke, ich kann übers Wochenende mal einen kurzen Versuch machen, wie sich meine NASse bei Deiner Aufgabenstellung verhalten.


    GLG GBD

    Zitat von "GorillaBD"


    Ich denke, ich kann übers Wochenende mal einen kurzen Versuch machen, wie sich meine NASse bei Deiner Aufgabenstellung verhalten.
    GLG GBD


    Hallo GorillaBD,
    konntest Du das schon mal checken? Bei mir bringt die An- und Abwahl der 3. Option (siehe Bild oben) das gleiche Ergebnis.
    Es wird immer die alte Datei überschrieben.


    Ich arbeite zwar mit einer alten FW und kann nicht sagen ob das in FW 4.X besser funktioniert, aber bei solchen Dingen stehen mir immer die Haare zu Berge und ich krieg 'nen dicken Hals.


    Hab mir deshalb zwischenzeitlich mal rsnap angeschaut.

    Nein, tut mir leid, der Versuch fiel der u.a. der Vorbereitung einer Matheprüfung von Sohn Nr. 2 zum Opfer. :roll:


    Sorry, ich schaue mal, ob ich diese Woche noch irgendwie dazu komme.


    GLG GBD


    --- UPDATE ---


    Ich habe die Aufgabenstellung jetzt einmal versucht, nachzustellen:


    - 100 Word Dokumente auf die interne HDD der NAS kopiert
    - Backupjob auf externen Datenträger aufgesetzt und laufen lassen (im Modus "Jetzt replizieren", einzige aktivierte Option: Überschüssige Dateien löschen)
    - 3 Word Dokumente verändert
    - Backupjob erneut laufen lassen


    Ergebnis: Die veränderten Dateien wurden auch im Ziel überschrieben, obwohl dies nach der Regel-Auswahl des Backup-Jobs nicht sein sollte :(


    Das ist in meinen Augen ein Bug, weil der entsprechende Schalter in den Backup-Einstellungen scheinbar keine Wirkung zeigt.
    Die geänderten drei Dateien sind neuer und unterscheiden sich in der Dateigrösse.


    NAS: TS-219 P+, FW: 3.7.3.


    Dieser Beitrag wird ergänzt, sobald ich es auch noch mal auf meiner 269pro / FW 4.0.3 versucht habe.


    --- EDIT --- Ergänzung ----


    Dieses Verhalten tritt so auch unter der 4.0.3 auf.
    Geänderte Dateien werden auch im Ziel überschrieben, egal ob der Schalter in den Backup-Regeln gesetzt ist, oder nicht.
    Daran ändert auch eine andere Einstellung des Schalters "Dateiinhalte prüfen" nichts, ebenfalls nicht der Modus "Echtzeitsicherung" anstelle der Zeitplansicherung.



    GLG GBD


    Großes Lob an Dich, dass Du die Aufgaben der Entwickler übernimmst! Ehrlich - Respekt!
    Mein Rat an die wirklichen Entwickler, sollten sie sich hierhin verirren: Es ist Eure Aufgabe, solche Tests zu machen. Wir zahlen Geld für Hard- UND Software, und es kann wohl schlecht sein, dass solche Tests nicht durchgeführt, oder, falls doch, das Resultat stillschweigend in Kauf genommen wird. In Sachen Backup sind die Version 4.x-Releases echt eine Frechheit wie ich sie selten erlebt habe.


    Ich versuche mittlerweile seit 4 Wochen, die Daten meines neuen 469L gescheit extern zu sichern. AUTOMATISCH GEHT DAS NICHT :cursing: ! Mein Ziel ist ein Cisco-NAS, welches ich lediglich per FTP ansprechen kann. Und die Liste der Fehlfunktionen in der 4.0.2 ist wirklich verdammt lang. Gefühlt länger als die Liste der Dinge, die zuverlässig arbeiten.
    QSYNC - langsam, fehlerhaft
    RTRR@FTP-Ziel - bricht laufend ab, kann nicht, will nicht, darf nichts ändern,... (komisch, dass mit gleichen Anmeldeinfos mein Totalcommander alles das darf...)
    RTRR@USB-Disk (EXT4) - der gleiche Zauber
    von inkrementell sind wir da noch weit weg. Eine Vollsicherung wäre mir auch recht, wenn's nur laufen würde
    Umlaute - Chaos pur
    Die externe Sicherung empfinde ich deshalb als zwingend notwendig, weil ich schon sehr viel über Datenverluste beim Firmwareupgrade gelesen habe, und allzu stabil scheint mir das ganze qnap-System aus softwareseitiger Sicht nicht zu sein.


    vg Erik

    Zitat von "erik 0987654"

    Ich versuche mittlerweile seit 4 Wochen, die Daten meines neuen 469L gescheit extern zu sichern. AUTOMATISCH GEHT DAS NICHT :cursing: !


    Ich sichere mit meiner TS-269pro / FW 4.0.3 täglich und meiner 659proII / FW 3.7.3 zweitäglich ohne jedes Problem sehr schnell und zuverlässig täglich eine Spiegelsicherung von meiner Synology DS-412+ NAS.


    Abzugleichender Datenbestand: 7,4TB auf 2 Einzeldisk
    RTRR-Modus: FTP-Server
    RTRR-Steuerungsmodus: Regelmässig, Zeitintervall 23h (Kombiniert mit NAS-Zeitplansteuerung)
    Durchschnittliche Kopiergeschwindigkeit: ca. 85MB/sec
    Datenart: Mediadaten, üblicherweise 20MB-35GB pro Datei
    Probleme mit Umlauten: Keine


    Ich sichere mit meiner TS-559pro / FW 3.7.3 ohne jedes Problem sehr schnell und zuverlässig unregelmässig Spiegelsicherungen von 8 externen Laufwerken via eines eSata-Duoports auf 4 interne Laufwerke der NAS mit entsprechend HDD-ID bezogenen Sicherungsjobs.


    Abzugleichender Datenbestand: 14,5 TB auf 4/8 Einzeldisks. Sicherungsprogramm: Externer Datenträger
    Sicherungsmodus: extern -> intern mit ID-Kopplung der externen HDD, 8 Jobs
    Steuerungsmodus: Automatisch, entsprechender Job startet nach Verbindung der jeweiligen extrenen Platte
    Durchschnittliche Kopiergeschwindigkeit: ca. 95MB/sec
    Datenart: Mediadaten, üblicherweise 20MB-35GB pro Datei
    Probleme mit Umlauten: Keine


    GLG GBD

    Das verstehe ich nicht ganz ?


    Wie oben beschrieben, "funktioniert" bei mir der RTRR auch mit einer x69 unter FW 4.0.3, in deren Fall als Spiegelsicherungs-"Sauger" von meiner Syno via FTP.


    GLG GBD

    darin liegt in meinem Fall die Schwäche des nss6000. Das dumme Ding kann nämlich fast garnix, außer kalte Luft in warme zu verwandeln, 0 db in 30, und Umlaute in irgendwelche anderen Zeichen, die im Nachhein nicht mehr lesbar sind.
    Nunja, seit heute Vormittag dient es als B2D-Ziel. Nicht schnell, dafür langsam und gemütlich. Hat ja 24h Zeit pro Sicherung ;)


    vg erik

    Einmal editiert, zuletzt von bladekiller () aus folgendem Grund: Unnötiges Volltextzitat entfernt! - siehe Forenregeln!

    Ich habe mich beim Knüpfen der FTP-Verbindung einmalig mit den Settings der Syno und QNAP bezüglich der UTF-8 auf beiden Maschinen auseinandersetzen müssen, damit es keine Probleme mit der Übertragung von Dateien und Ordnern mit Umlauten gibt.


    Danach lasse ich nun die QNAP von der Syno "saugen", weil mir gewisse Wahlfreiheiten in der Zielverzeichnisstruktur beim RTRR gefallen, die die Syno nicht bietet. Würde ich das Backup von der Syno zur QNAP "drücken" müssen, würde das gar nicht gehen, weil deren Backupprogramm keine FTP-Funktionalität bietet, Der Rsync von der Syno zur QNAP würde zwar gehen, ist aber nicht so schnell wie die FTP-Verbindung der QNAP als "Zielserver" und bringt Beschränkungen in der Zielverzeichnisstruktur mit sich, die ich nicht gebrauchen kann.


    So, wie ich die beiden jetzt betreibe, verstehen sie sich bestens und das mit über 80MB/sec auf eine QNAP-Atom und um 50MB/sec auf eine ARM mit 1,6Ghz-Prozessor.


    GLG GBD