Navigation section

Windows 11 Robocopy läuft seit Version 25H2 nicht mehr wie gewohnt

U

ukr

Senior Member
Joined
May 27, 2020
Messages
12
Hallo Gemeinde,

ich habe in einer Bat-Datei folgenden Befehl:
set x=e:\...\c\

robocopy c: %x% ^
/MIR /ZB /R:1 /SEC /W:1 /MT:8 /DST /LOG:"d:\log\c\%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2%-%time:~0,2%-%time:~3,2%-%time:~6,2%.log" /TEE /XJ /XF "C:\hiberfil.sys" "C:\pagefile.sys" "C:\swapfile.sys" "C:\DumpStack.log.tmp" /XD "c:\Windows" "c:\$Recycle.bin" "c:\program files\windowsapps" "C:\$WINDOWS.~BT" "%LOCALAPPDATA%\Temp"
Bis zur Version 24H2 funktionierter der Befehl auch wie gewünscht, das Skript sicherte nur die neuen und geänderten Dateien. Seit der neuen Version löscht das Skript erst alle Dateien auf dem Backup-Rechner in dem entsprechenden Ordner und kopiert sie dann alle wieder neu (hoffe ich jedenfalls). Gibt es hierfür eine Erklärung oder hat jemand einen Tipp. was ich machen kann?
Im Voraus vielen Dank!
 

Solution
ChatGPT
The key problem is most likely not a Robocopy “25H2 change”, but the fact that your source is written as c: (without the backslash).

Why this suddenly “deletes everything then recopies”​

In Windows CMD:
  • C: = the current working directory on drive C: (whatever that happens to be at runtime)
  • C:\ = the root of drive C:
If your batch is started from a different working directory after the 25H2 update (very common with Task Scheduler, services, different “Start in” folder, etc.), then robocopy c: %x% /MIR ... will mirror the wrong source folder to the destination.
And because you use /MIR (mirror = copy + delete)...
Sort by date Sort by votes
The key problem is most likely not a Robocopy “25H2 change”, but the fact that your source is written as c: (without the backslash).

Why this suddenly “deletes everything then recopies”​

In Windows CMD:
  • C: = the current working directory on drive C: (whatever that happens to be at runtime)
  • C:\ = the root of drive C:
If your batch is started from a different working directory after the 25H2 update (very common with Task Scheduler, services, different “Start in” folder, etc.), then robocopy c: %x% /MIR ... will mirror the wrong source folder to the destination.
And because you use /MIR (mirror = copy + delete), Robocopy will:
  • delete everything in the destination that is not in that (wrong) source folder
  • then copy what is in that source folder
That looks exactly like “it deletes all files on the backup PC and copies everything again”.

Fix 1 (recommended): Use C:\ explicitly​

Change the source to C:\:
Code: 
set "x=E:\...\c\"
robocopy "C:\" "%x%" /MIR /ZB /R:1 /SEC /W:1 /MT:8 /DST /TEE /XJ ^
 /XF "C:\hiberfil.sys" "C:\pagefile.sys" "C:\swapfile.sys" "C:\DumpStack.log.tmp" ^
 /XD "C:\Windows" "C:\$Recycle.bin" "C:\Program Files\WindowsApps" "C:\$WINDOWS.~BT" "%LOCALAPPDATA%\Temp"
(Quotes are important, even if your current paths don’t contain spaces.)

Fix 2: If you run it via Task Scheduler, also set “Start in”​

If this runs as a scheduled task, open the task → Actions / Conditions and set:
  • Start in (optional): something explicit, e.g. C:\
Or add at the top of the batch:
cd /d C:\

Safety check (highly recommended with /MIR)​

Before you run it again, do a dry-run once:
robocopy "C:\" "%x%" /MIR /L /XJ (…your excludes…)
/L shows what would be copied/deleted without actually doing it. This is the fastest way to confirm you’re not about to wipe your backup again.

Quick questions (so we can be 100% sure)​

  1. Do you run the BAT manually, or via Task Scheduler (and under which account)?
  2. Is the destination E:\...\c\ a local disk, USB disk, or a network share?
  3. Can you paste the Robocopy summary from the end of the log (the table with Dirs / Files / Bytes and especially the counts for Extras / Mismatch)?
With that summary it’s easy to confirm whether it’s a wrong-source issue (most likely) or a timestamp/FS granularity issue (then we’d look at options like /FFT).
 

Upvote 0 Downvote
Solution
Sollte diese Zeile /XD "C:\Windows" "C:\$Recycle.bin" "C:\Program Files\WindowsApps" "C:\$WINDOWS.~BT" "%LOCALAPPDATA%\Temp" auch hinter den jeweiligen Ordnern auch einen BS haben?
 

Upvote 0 Downvote
No — for robocopy /XD you don’t have to add a trailing backslash (\) to each excluded folder.
Robocopy matches directories by name/path, and these are treated as folders either way:
  • /XD "C:\Windows" ✅ works
  • /XD "C:\Windows\" ✅ also works
So your line is fine as written.

A couple of practical notes​

  1. Keep quotes (you already do) — that’s required for paths with spaces like "C:\Program Files\WindowsApps".
  2. Be careful with %LOCALAPPDATA%\Temp
    • This expands depending on which account runs the batch.
    • If you run it via Task Scheduler as SYSTEM (or another user), %LOCALAPPDATA% will point somewhere else and may not exclude the temp you think.
    • If you want to exclude all user temp folders, a more robust pattern is something like:
      • C:\Users\*\AppData\Local\Temp
        (Robocopy generally accepts wildcards in exclude paths, but it’s worth verifying with a /L dry run first.)
If you tell me whether you run the script manually or via Task Scheduler (and under which user), I can suggest the cleanest exclude for Temp.
 

Upvote 0 Downvote
If you start the BAT manually (by double-click / from your own CMD), then %LOCALAPPDATA% will normally expand to your profile (e.g. C:\Users\ukr\AppData\Local) — so this exclude is fine and doesn’t need a trailing \.

When could %LOCALAPPDATA%\Temp still be “wrong” even manually?​

  • If you start the batch “Run as different user”
  • Or if you run it from a context where environment variables are different (rare, but possible)
If you want to make it explicit (and independent of the variable), you can use:
/XD "%USERPROFILE%\AppData\Local\Temp"

If you want to exclude Temp for all users​

Use an explicit wildcard path:
/XD "C:\Users\*\AppData\Local\Temp"
(Do a /L test run once to verify it matches what you expect.)

Main thing to re-check (most important)​

Make sure your source is "C:\" and not c:. With /MIR, c: can easily cause the “destination gets wiped and rebuilt” behavior.
If you paste the first ~20 lines of your Robocopy log (where it prints Source : and Dest :), I can confirm immediately whether it’s copying from the correct source path.
 

Upvote 0 Downvote
-------------------------------------------------------------------------------
ROBOCOPY :: Robustes Dateikopieren fr Windows
-------------------------------------------------------------------------------

Gestartet: Donnerstag, 5. Februar 2026 18:54:38
Quelle : C:\
Ziel : e:\Ulli-Robo-sichern\c\

Dateien : *.*

Ausgeschl. Dateien: C:\hiberfil.sys
C:\pagefile.sys
C:\swapfile.sys
C:\DumpStack.log.tmp

Ausgeschl. Verzeichnisse: c:\Windows
c:\$Recycle.bin
c:\program files\windowsapps
C:\$WINDOWS.~BT
C:\Users\admin\AppData\Local\Temp

Optionen: *.* /DST /TEE /S /E /DCOPY:DA /COPY:DATS /PURGE /MIR /ZB /XJ /MT:8 /R:1 /W:1
 

Upvote 0 Downvote
From the header you pasted, Robocopy is now definitely using the correct source:
  • Source: C:\
  • Dest: e:\Ulli-Robo-sichern\c\
So the earlier “c: vs C:\” pitfall is not the issue in this run.
What you describe (“it deletes everything in the destination and then copies everything again”) typically happens for one of these reasons:

1) It’s actually mirroring “Extras” (because of /MIR = /E + /PURGE)​

With /MIR, Robocopy always deletes “Extras” in the destination (things that are not present in the source selection) before it finishes.
Important nuance: if you exclude big parts of C: (like C:\Windows, WindowsApps, etc.), then those paths are not part of the “source selection”. If such folders/files exist in the destination from an earlier run, they can be treated as Extras and get deleted due to /PURGE.
This can look like “it wiped the destination”.
Check in your log summary (end of the log) whether “Extras” is huge.

2) Robocopy thinks everything is “changed” every run (timestamp/FS granularity/DST/security)​

If it recopies all files every single time, Robocopy is usually comparing something that differs every run, e.g.:
  • Timestamps differ (common with NAS/SMB, or some external drives)
    → try /FFT (more tolerant timestamp comparison)
  • DST compensation causes systematic 1-hour differences
    → you currently use /DST; if source+dest are on the same machine/clock, try removing it
  • Security/ACLs differ
    → you use /SEC and /COPY:DATS (includes security). If dest doesn’t preserve NTFS ACLs (exFAT, some NAS configs, etc.), Robocopy may “need” to reapply security and thus recopy/re-touch lots of items.

Quick test (most useful)​

Run it once with extra diagnostics (no changes) to see why it wants to copy/delete:
Code: 
robocopy "C:\" "e:\Ulli-Robo-sichern\c\" /MIR /L /V /TS /FP /BYTES /XJ ^
  /XF "C:\hiberfil.sys" "C:\pagefile.sys" "C:\swapfile.sys" "C:\DumpStack.log.tmp" ^
  /XD "C:\Windows" "C:\$Recycle.bin" "C:\Program Files\WindowsApps" "C:\$WINDOWS.~BT" "%LOCALAPPDATA%\Temp"
  • /L = list only (no delete/copy)
  • /V /TS /FP = shows more detail + timestamps + full paths
  • You’ll usually see labels like Newer/Older/Mismatch/Extra.

3) Two practical “try this” adjustments​

If your destination is not NTFS (for example exFAT on an external disk) or is a network share, try:

Variant A (timestamp tolerance)​

... /MIR /FFT /XJ ...

Variant B (avoid security causing re-copies)​

If you don’t need NTFS permissions preserved in the backup, remove /SEC (and optionally force data+time only):
... /MIR /COPY:DAT /DCOPY:DA /XJ ...
(Keep /SEC only if the destination is NTFS and you really want ACLs mirrored.)

Two questions to pinpoint it immediately​

1) Is e:\Ulli-Robo-sichern\... an external USB disk (and is it NTFS or exFAT) or is E: a mapped network drive?
2) Does the “delete + recopy all” happen every run, or was it only the first run after 25H2?
If you paste the Robocopy summary from the end (Dirs/Files and especially Extras and Mismatched counts), I can tell you exactly which of the above is happening.
 

Upvote 0 Downvote
Das Paste hat aus :D
1770385892528.webp
genacht.
 

Upvote 0 Downvote
That’s just the forum editor auto-converting smileys/emoticons into an attachment/image. In XenForo-style editors, :D becomes an emoji unless the text is inside a code block.

How to paste Robocopy logs without smileys turning into emojis​

Use Code tags:
Option A (best): wrap the log in a code block
[CODE] ...paste your robocopy output here... [/CODE]
Option B: In the editor toolbar click the </> (Code) button, then paste inside it.
Option C: If there’s a checkbox like “Disable smilies” (sometimes under “More options”), enable it for that post.

Quick workaround​

If you only have a few smileys, you can also break them so they won’t convert, e.g. write : D (with a space).
If you paste the end-of-log summary inside a [CODE]...[/CODE] block (the section with Dirs / Files / Bytes and counts like Extra / Mismatch), I can tell you exactly why it’s deleting/recopying.
 

Upvote 0 Downvote
Ok,
concerning the improved code, i'm testing it, bur it needs some time. I will post the result as soon as it finished.
 

Upvote 0 Downvote
Alles klar—nimm dir die Zeit.
Damit wir danach schnell zum Punkt kommen, poste bitte (am besten in [CODE]...[/CODE]) genau diese 2 Stellen aus dem Log:
1) Die Zusammenfassung ganz am Ende (die Tabelle mit Dirs / Files / Bytes und den Spalten wie Total / Copied / Skipped / Mismatch / FAILED / Extras).
  • Entscheidend sind v. a. Mismatch und Extras.
2) Falls vorhanden: ein paar Beispielzeilen aus dem Hauptteil, wo Robocopy begründet, warum es Dateien kopiert (z. B. Newer/Older/Mismatch etc.).
Zusätzlich noch eine kurze Info (1 Zeile reicht):
  • Ist dein Ziel E:\... NTFS oder exFAT? (Rechtsklick auf Laufwerk → Eigenschaften)
Warum das wichtig ist: Wenn z. B. Extras hoch ist, ist es “normales” /MIR-//PURGE-Verhalten; wenn Mismatch hoch ist, geht’s eher Richtung Zeitstempel-/ACL-/Dateisystem-Thema (dann helfen typischerweise /FFT oder das Weglassen von /SEC bzw. /DST).
 

Upvote 0 Downvote
From your screenshot I can see two separate issues in the first Robocopy call:

1) Wrong source: it’s mirroring C:\Windows\System32\​

Robocopy shows:
  • Quelle (Source): C:\Windows\System32\
That happens when you use c: (without \). In an elevated console the “current folder on C:” is often C:\Windows\System32, so Robocopy mirrors only that folder. With /MIR this can absolutely make the destination look like it was “wiped and rebuilt”.
Fix: Always use the root explicitly:
robocopy "C:\" "%x%" ...
—not robocopy c: %x% ....

2) Your destination variable seems to contain a stray quote (")​

In the header it prints something like e:\Ulli-Robo-sichern\c\" and then Robocopy says:
  • FEHLER: Es wurde kein Zielverzeichnis angegeben. (No destination directory specified)
That strongly suggests your variable %x% contains a broken/unbalanced quote (for example it ends with ").
Correct way to set the variable (no extra quotes inside the value):
set "x=E:\Ulli-Robo-sichern\c\"
Then call Robocopy like:
robocopy "C:\" "%x%" /MIR /ZB /R:1 /W:1 /MT:8 /XJ /TEE ...

Please paste (as text) the first ~10 lines of your BAT​

Use [CODE]...[/CODE] and include:
  • your set x=... line
  • the exact robocopy line for drive C:
Because right now the screenshot indicates:
  • it’s still using c: (so source becomes System32)
  • and %x% is likely malformed (quote issue), which is why Robocopy doesn’t see the destination.
Once you post those lines, I’ll rewrite the exact working version for your script (including safe “dry run” /L first, then the real run).
 

Upvote 0 Downvote
My code is
robocopy "C:\" "e:\Ulli-Robo-sichern\c\" /MIR /L /V /TS /FP /BYTES /XJ ^
/XF "C:\hiberfil.sys" "C:\pagefile.sys" "C:\swapfile.sys" "C:\DumpStack.log.tmp" ^
/XD "C:\Windows" "C:\$Recycle.bin" "C:\Program Files\WindowsApps" "C:\$WINDOWS.~BT" "%LOCALAPPDATA%\Temp"set "RC=%ERRORLEVEL%"
 

Upvote 0 Downvote
Your Robocopy line is basically fine now, but the problem is at the very end:
You have this stuck onto the same line:
... "%LOCALAPPDATA%\Temp"set "RC=%ERRORLEVEL%"
So CMD reads "%LOCALAPPDATA%\Temp"set as one combined token, which breaks the command line and can lead to errors like “no destination specified” / weird parsing.

Fix: put set "RC=..." on a new line (or use &)​

Use this layout:
Code: 
robocopy "C:\" "E:\Ulli-Robo-sichern\c" /MIR /L /V /TS /FP /BYTES /XJ ^
  /XF "C:\hiberfil.sys" "C:\pagefile.sys" "C:\swapfile.sys" "C:\DumpStack.log.tmp" ^
  /XD "C:\Windows" "C:\$Recycle.bin" "C:\Program Files\WindowsApps" "C:\$WINDOWS.~BT" "%LOCALAPPDATA%\Temp"

set "RC=%ERRORLEVEL%"
echo Robocopy exit code: %RC%

Notes​

  • I changed the destination to "E:\Ulli-Robo-sichern\c" (without the trailing \). Both usually work, but this avoids edge-case quoting confusion.
  • Make sure the ^ is the last character on the line (no trailing spaces after it), otherwise the line continuation fails.

Why your screenshot earlier showed C:\Windows\System32​

That happens when the source is written as c: (without \) and the batch is started from C:\Windows\System32 (common when “Run as administrator”). Robocopy then mirrors only System32, and with /MIR it can delete lots of “extras” in the destination.
With "C:\" you avoid that.
If you paste the next run’s summary block (Totals/Copied/Skipped/Mismatch/Extras) we can confirm whether it’s still trying to recopy everything or if it’s behaving normally again.
 

Upvote 0 Downvote
You must log in or register to reply here.
Back
Top