robocopy, hat sich was verändert?

[Shadow1701]

Ich grüße euch.

Hat sich bei robocopy in irgend einem Windows update was verändert?

Bis jetzt konnte ich mich immer darauf verlassen, dass es wie folgt funktionierte:
Ich habe eine Kopie abgebrochen indem ich einfach das CMD geschlossen habe. Auch wenn die Datei sagen wir, erst zu 42% kopiert wurde. Wenn ich die batch Datei jetzt neu geöffnet habe, wurde die Kopie bei dieser Datei und bei 42% fortgesetzt.

Das ist nicht mehr so, jetzt belegt die Datei von Anfang an, auch wenn erst 1% kopiert wurde, am Zieldateisystem bereits 100% des Speicherplatzes dieser Datei. Wenn ich jetzt das Kopieren abbreche und neu starte wird nicht bei 42% fortgesetzt, sondern diese Datei wird übersprungen, weil robocopy glaubt sie sei bereits vollständig, und es geht mit der nächsten Datei in der Liste weiter. Was natürlich schlecht ist weil diese eine Datei in Wahrheit nicht vollständig ist.

Meine robocopy Zeilen sehen seit Jahren immer so aus:
robocopy "quelle" "ziel" /E /XO /FFT /R:2 /W:1

Es ist egal ob das Ziel das QNAP NAS ist, das truecrypt NAS mit dem ich gerade herumspiele, eine externe HDD oder eine interne SSD. Es ist immer das gleiche.

Ich konnte mich immer darauf verlassen, dass das Kopieren zuverlässig wieder aufgenommen wird. Seit gestern weiß ich, dass das nicht der Fall ist. Woran liegt das?

 

[assman17]

Für Resume ist /z.

/Z: Ensures Robocopy can resume the transfer of a large file in mid-file instead of restarting.

 

[Shadow1701]

Hmm.....
Vielleicht war es ja wirklich nur meine Einbildung, dass das Wiederaufnehmen abgebrochener Kopien in der Vergangenheit funktionierte. Den -z Parameter habe ich noch nie benutzt.

Was aber keine Einbildung ist, ist die Tatsache das der Z Parameter sehr viel Zeit in Anspruch nimmt. Ich habe das Kopieren einer 1,6GB großen Datei gestoppt:
ohne Z Paramter: 20 Sekunden
mit Z Paramter: 2 Minuten 10 Sekunden

So ein Zeitverlust ist nicht akzeptabel wenn ich 400GB kopieren will. Ich werde also davon absehen den Vorgang abzubrechen bzw. werde ich die nicht fertig kopierte Datei manuell löschen damit sie erneut kopiert wird.

Danke jedenfalls.

 

[Mojo1987]

Aus Konsistenz Sicht ist die Art und Weise wie du mit Daten umgesehst höchst fragwürdig.
Wie stellst du nach dem willkürlichen Abbrechen sicher das überhaupt korrekt und vollständig Daten übertragen wurden und auch denen der Quelle entsprechen? Einfach Robocopy Losjagen kann ja nicht die Lösung sein.

 

[T3rm1]

Seit wann wird denn nach dem Kopieren nicht sichergestellt, dass Dateien identisch sind? Völlig egal wie häufig abgebrochen und fortgesetzt wurde.

 

[Krik]

Für den Fall der Fälle:
Hast du dir mal rsync angeschaut? Das gibt es auch für Windows und ist exzellent, um Backups zu machen und auch nur so viel zu kopieren, wie auch wirklich nötig ist.

Ein Beispiel aus meinem automatischen Backup-Skript:

2024/05/26 00:09:29 [805267] Total file size: 127.38G bytes
2024/05/26 00:09:29 [805267] Total transferred file size: 2.91G bytes
2024/05/26 00:09:29 [805267] Literal data: 2.91G bytes
2024/05/26 00:09:29 [805267] Total bytes sent: 2.94G
2024/05/26 00:09:29 [805267] Total bytes received: 4.10M
2024/05/26 00:09:29 [805267] sent 2.94G bytes  received 4.10M bytes  5.22M bytes/sec
2024/05/26 00:09:29 [805267] total size is 127.38G  speedup is 43.20

Die zu sichernden Dateien umfassen ~127 GB. Knapp 3 GB des Backups mussten aktualisiert werden (weil Änderungen vorlagen).
Dadurch, dass nur Änderungen übertragen werden mussten, konnte der Backup-Vorgang um dem Faktor 43,2 beschleunigt werden. Ein Faktor von 1 hätte man, wenn man alles kopieren müssen, zB beim ersten Backup.

 

[kartoffelpü]

Hat sich bei robocopy in irgend einem Windows update was verändert?

Es kam jetzt gerade ne neue Version bei Win11 (16.05., 10.0.22621.3527), vielleicht wurde da was geändert. Eine Versions-/Changehistory habe ich auf Anhieb leider nicht gefunden.

Ich habe es eigentlich auch so in Erinnerung, dass bisher bei Abbruch die Datei im Ziel liegenbleibt und beim nächsten Lauf fortgeführt wurde. Mit der neuen Version habe ich noch nichts getestet.

 

[Shadow1701]

@kartoffelpü Vielen Dank für deine Antwort, vielleicht bin ich doch noch nicht dement.

an alle die mir geantwortet haben:

Die Kritik ist angekommen.

Geprüft habe ich die Dateien nach dem kopieren grundsätzlich schon, aber nur ob sie existiert und ob die Dateigröße stimmt. (das selbe PHP script, dass die batch Dateien generiert, hat das dann anschließend auch geprüft, meine aktuelle Spielerei mit dem truenas ist da jetzt mal ausgenommen da es nur ein testsystem ist).

Offenbar reicht die Prüfung ob die Datei existiert und ob die Dateigröße stimmt nicht aus, ich werde das überarbeiten und ich werde mit rsync ansehen.

Ich danke euch.

 

[Krik]

@Shadow1701
Das ist mein simples Backup-Skript. Es ist zwar für Linux geschrieben, aber du willst sicher die rsync-Parameter wissen.

#! /bin/bash

if ! mountpoint -q /mnt/nas; then
        # NAS ist nicht eingebunden
        # nachholen!
        mount -a;
fi

if mountpoint -q /mnt/nas; then
        # alte Log-Datei löschen
        rm  /mnt/nas/Backup/Computer/log.txt

        # nice-Priorität hochsetzen, damit rsync den Vordergrundprogrammen nicht die Performance wegnimmt
        # rsync starten
        nice -n20 rsync -aAXh --stats --bwlimit=81920 --delete --log-file=/mnt/nas/Backup/Computer/log.txt /home/Benutzer/ /mnt/nas/Backup/Computer/files/

        echo "Zum Wiederherstellen das verwenden:" >> /mnt/nas/Backup/Computer/log.txt
        echo "sudo rsync -aAXv --delete /mnt/nas/Backup/Computer/files /home/Benutzer" >> /mnt/nas/Backup/Computer/log.txt
else
        # NAS ist immer noch nicht eingebunden
        # Fehler!
        echo "NAS ist nicht eingebunden. Abbruch! "
fi

Für dich interessant sind Zeile 15 und 18.