Backup per RoboCopy - regelmäßig offenbar Quelle neuer - wie?

[cumulonimbus8]

Moin!

Ich sichere (W10) auf diverse Datenträger, extern. Dazu verwende ich RoboCpoy mit den Schalter /mir /fft (und /r:0 w:0).
Grundsätzlich ist diese Kombination in Ordnung.
Intern SSDs, M.2s; extern HDD.

In letzter zeit bemerke ich aber, dass offenbar jede Datei intern neuer ist als die externe und deswegen geschrieben wird. Bei 4TB dauert das. Zeitstempel sollten ja soweit gleich sein, und bei liegenden HDD sollte nicht plötzlich die Zieldatei einen anderen Zeitstempel haben.

Angenommen, die interne, in dem Falle offenbar eine der M.2, hat einen Knacks beim Zeitstempel. Wie wäre das erklärbar? Macht sich da ein TRIM selbstständig; aber wie sollte dies Informationen im Dateisystem (NTFS) verändern?

Es sind durchweg alle Dateien jener M.2 [die mir gerade per Beobachtung auffällt], auch wenn ich bestimme SW dort update oder gar selber per RoboCopy auffrische; das sind nur bestimmte Ordnergruppen, und die fallen natürlich beim Sichern nach draußen immer erwartbar auf. Aber jetzt ist es offenbar alles?!

Was spielt mit hier diesen Streich?

CN8

 

[BFF]

/fft macht doch die Erlaubnis das 2s Differenz ok sind. Kopierst Du z.B. von/nach NTFS -> EXT4?
Weil wenn nein wuerde ich das FFT mal weg lassen und eher loggen.

 

[Sebbi]

Macht sich da ein TRIM selbstständig; aber wie sollte dies Informationen im Dateisystem (NTFS) verändern?

gar nicht, TRIM arbeitet auf Hardwareebene, nicht auf Dateisystemebene

Aber jetzt ist es offenbar alles?!

Dein AV Scanner vielleicht ? Ansonsten mal auf den Datenträgern ein chkdsk /f ausführen, um ggf einen Dateisystem fehler zu reparieren.

btw ich würde dir empfehlen das ArchivBit zu nutzen. Dies wird bei jeder Dateiveränderung seitens Windows gesetzt. Dann werden nur Dateien gesichert, bei denen das gesetzt ist. Dann entfällt auch die Prüfung auf dem Zieldatenträger, oh die Datei schon vorhanden ist und welchen Zeitstempel die hat, was nochmal ortentlich Zeitersparniss bringt.

 

[cumulonimbus8]

Mit ohne /FFT habe ich noch größere Probleme erlebt. Es löst seltsamerweise sachen die man ihm nicht zurtaut.

Quelle wie Ziel sind NTFS (stand da).

TRIM war die berühmte Strohhalm für diese Irrigkeiten, du verstehst? 😉

Den AV vergessen wir mal mit Höchstgeschwindigkeit. Sonst würde es immer und überall passieren.

Auch CHKDSK können wir vergessen - es würde nämlich nicht die Ursache erklären falls es was lösen würde was nicht zu lösen wäre. Denn es ist jetzt zufällig diese Quelllaufwerk. nach Tagesform ist es plötzlich ein anderes.
Wobei ich tatsächlich langsam an den Wahnsinn glaube, dass am Ziel was passiert; aber wie wenn diese Platten routinemäßig nicht benutzt werden, außer jetzt zum Sichern?

Und als alter DOS-Mensch habe ich da schon lange Verzicht auf das A-Attribut zu lernen geübt.
Weil? Logisch müsste es dann zurückgesetzt werden wen eine Sicherung durch ist.
→ Das ist doch der Knackpunkt, dass akut alles erfasst wird; alles auf A, alles was nicht bewegt wird plötzlich auf A? Nicht logisch erklärbar.
→ Jedenfalls darf A dann/dabei nicht zurückgesetzt werden weil zeitversetzt weitere Sicherungen erfolgen. Die fielen dann wegen Bodennebel aus. Es bleibt nur der Zeitstempel als Maß.

CN8

PS: ich ahbe auch so eine Cloud… Magenta gefärbt… Was die Telekomiker machen, ich weiß es nicht; RoboCopy kann keine Zeitstempel abgleichen - oder wenn ist das Ziel «älter als die Quelle», sämtliches.
FreeFileSync kanns auch nicht, da muss ich auch im Normalfall auf Dateiname setzen. Nicht optimal das alles…

 

[xexex]

Dazu verwende ich RoboCpoy mit den Schalter /mir /fft (und /r:0 w:0).
Grundsätzlich ist diese Kombination in Ordnung.

Nö! Es fehlt in meinen Augen ein "/copyall" oder mindestens ein "/copy:DAT" und ein "/dcopy:DAT".

 

[Sebbi]

Auch CHKDSK können wir vergessen - es würde nämlich nicht die Ursache erklären falls es was lösen würde was nicht zu lösen wäre. Denn es ist jetzt zufällig diese Quelllaufwerk. nach Tagesform ist es plötzlich ein anderes.

ein BSoD reicht aus um auf allen Laufwerken was durcheinander zu bringen und es schadet idR nicht, das mal einfach zu prüfen, ob die Integrität gewährleistet ist

Den AV vergessen wir mal mit Höchstgeschwindigkeit. Sonst würde es immer und überall passieren.

ggf Bug bei der Version aktuell? sowas einfach auszuschließen ist fahrlässig

 

[redjack1000]

Zeitstempel sollten ja soweit gleich sein

"Sollten" reicht nicht, da muss man schon genauer hinschauen.

CU
redjack

 

[cumulonimbus8]

BSOD - lange nicht gesehen 😇
Ich kanns nur wiederholen - das schlägt nach Gusto zu und betrifft unterschiedliche Quellen und Ziele. Ich bin ja schon so weit eher an die Quelle zu glauben und frage deswegen hier bei Flash-Speicher… …aber auch Sticks und Karten müssen als Ziel mal drunter leiden, mal nicht.

Der AV ist es nicht. Sagen wir einfach - ich habe Gründe das sicher zu wissen.

/COPYALL habe ich bewusst nicht eingesetzt um Streams (u.a.) abzusägen. Außerdem - das Datum ist eine Standardinformation wie es per se auch das A-Attribut wäre, da ist nichts zu erzwingen.
Auch /…DAT muss logisch unnötig sein und war es immer.
Denn bei anderen Kopiervorgängen mit der selben Syntax von teils ja auch der selben Quelle haben ich die Probleme nicht.

--- Neues Posting---

Was soll bei Zeitstempeln denn anders werden wenn Quelle und erst recht Ziel nicht angepasst werden - wenigsten nicht von mir per Hand oder per RoboCopy oder sonstwas?
Wäre das so könnte man alle Dateisysteminformationen in die Mülltonne übergeben.


Der Vorgang den ich angestoßen habe ist durch… Und vielleicht habe ich Mist erzählt aber das kann irgendwo nicht sein weil ich weiß was als gewiss als neu zu schreiben wäre und was nicht. Vielleicht wurde doch unberührtes korrekt übergangen. Und es ist nicht der ganze Datenträger sondern nur Teile des Dateisystems.
Ich stehe da wie der Ochs vorm Scheunentor…

CN8

 

[BFF]

Mit ohne /FFT habe ich noch größere Probleme erlebt.

Was denn nun?

FFT wird eigentlich eingesetzt damit von/mit FAT-Uhrzeit kopiert wird. Ich kenn das nur wenn auf Systeme mit z.B. EXT4 kopiert wird. Auf angeploppte HDD macht das irgendwie keinen Sinn.

Hast Du mal die vollstaendige Zeile Deines Robocopy?

 

[cumulonimbus8]

Bitte gerne…

set TD=%~d0
set TD=%TD:~0,1%
set SD=C
for %%a in (A B C D) do robocopy "%SD%:\%%~a" "%TD%:\%%~a" /mir /fft /w:0 /r:0

Das funktioniert regelmäßig und korrekt - nur eben nicht immer. Und dann eben auf sehr bestimmte Weise.

«mit ohne» muss man doch nicht übersetzen? Es soll ohne nur verstärken.
Und den Tipp mit /FFT habe ich womöglich hier gefunden - ja, unlogisch, aber er bekommt Dinge gebacken und aufgefangen die ich auch mit /MAXAGE nicht… geglättet… bekam. Allein wäre ich nicht auf /FFT gekommen.

CN8