How to Use Rsync on Windows with WSL, MSYS2, or Cygwin

User question

how to use rsync on Windows

Artificial Intelligence Response

Direct answer to the question

The simplest and most reliable way to use rsync on Windows is to install WSL (Windows Subsystem for Linux), then install rsync inside a Linux distribution such as Ubuntu. Microsoft documents a one-command WSL install (wsl --install), and Windows drives are available inside WSL under paths such as /mnt/c and /mnt/d. (learn.microsoft.com)

If you cannot use WSL, the two solid alternatives are MSYS2 and Cygwin. MSYS2 provides an rsync package installable with pacman -S rsync, and Cygwin provides rsync as a selectable package in its installer. (packages.msys2.org)

My recommendation: use WSL unless you have a specific reason not to. It gives behavior closest to Linux rsync, which is usually what people expect. (learn.microsoft.com)

---

Detailed problem analysis

rsync is fundamentally a Unix-style file synchronization tool. Its basic form is:

rsync [options] SOURCE DESTINATION

It supports local copies, copies over SSH, and daemon mode. The official man page also notes two very important behaviors: a trailing slash on the source changes whether you copy the directory itself or only its contents, and --dry-run should be used before --delete because deletion can be dangerous if the paths are wrong. (rsync.samba.org)

Recommended method: WSL

1. Open PowerShell as Administrator.
2. Install WSL:

wsl --install

3. If needed, list distributions and install a specific one:

wsl --list --online
wsl --install -d Ubuntu

Microsoft’s current documentation confirms these commands and notes that wsl --install is the standard installation path. (learn.microsoft.com)

4. Launch your Linux distribution and install rsync:

sudo apt update
sudo apt install rsync

5. Access Windows files from Linux paths such as:

/mnt/c/Users/YourName/Documents
/mnt/d/Backup

Microsoft documents the /mnt/<drive> convention for mounted Windows drives. (learn.microsoft.com)

Practical WSL examples

Local copy from C: to D:

rsync -avh --dry-run /mnt/c/Users/YourName/Documents/ /mnt/d/Backup/Documents/

If the dry run looks correct, run the real copy:

rsync -avh /mnt/c/Users/YourName/Documents/ /mnt/d/Backup/Documents/

Remote copy over SSH:

rsync -avhz --progress /mnt/c/Users/YourName/Projects/ user@server:/srv/backup/projects/

Mirror source to destination, deleting removed files:

rsync -avh --delete /mnt/c/Users/YourName/Documents/ /mnt/d/Backup/Documents/

Use --delete only after you verify the source and destination with --dry-run; that is explicitly recommended in the official man page. (rsync.samba.org)

Why WSL is usually best

• It runs actual Linux userland tools on Windows. (learn.microsoft.com)
• Path mapping is straightforward for Windows drives via /mnt/c, /mnt/d, etc. (learn.microsoft.com)
• Microsoft notes that performance is better when project files live in the Linux filesystem (\\wsl$) rather than on mounted Windows drives, which matters for large trees or repeated sync jobs. (learn.microsoft.com)

So, from an engineering perspective:

• For occasional backup of Windows folders: using /mnt/c/... is fine.
• For frequent development syncs: storing the working tree in the Linux filesystem can be faster. This is an inference based on Microsoft’s stated filesystem-performance guidance. (learn.microsoft.com)

Alternative 1: MSYS2

MSYS2 is a good choice if you want a Unix-like shell on Windows but do not want full WSL. MSYS2 uses pacman for package management, and its package page currently shows an rsync package with installation via:

pacman -S rsync

That is the official MSYS2 installation route for rsync. (packages.msys2.org)

Typical usage after installation looks like:

rsync -avh /c/Users/YourName/Documents/ /d/Backup/Documents/

Alternative 2: Cygwin

Cygwin is another valid route. Its installer (setup-x86_64.exe) lets you add packages after the base install, and the official package list includes rsync as a stable package. (cygwin.org)

Typical usage is:

rsync -avh /cygdrive/c/Users/YourName/Documents/ /cygdrive/d/Backup/Documents/

Remote synchronization considerations

For remote transfers, the rsync man page states that rsync can use a remote shell such as SSH, and that rsync must be installed on both source and destination machines. (rsync.samba.org)

That means:

• Windows-to-Linux over SSH: install rsync in WSL/MSYS2/Cygwin on Windows, and make sure Linux already has rsync. (rsync.samba.org)
• Linux-to-Windows over SSH: Windows also needs an rsync binary somewhere on the remote side, not just SSH. The --rsync-path option exists specifically to point at the remote rsync program when needed. (rsync.samba.org)

---

Current information and trends

As of May 6, 2026, the current official Windows guidance still strongly supports the streamlined WSL workflow using wsl --install, and WSL documentation continues to describe mounted Windows drives under /mnt/<drive>. (learn.microsoft.com)

MSYS2 is also actively maintained. Its package page currently lists rsync version 3.4.2-2, with a build date of April 29, 2026, installed via pacman -S rsync. (packages.msys2.org)

Cygwin continues to publish rsync as a stable package as well; its package summary currently lists stable rsync 3.3.0-1. (cygwin.com)

Windows also continues to expose OpenSSH Client and OpenSSH Server as optional components installable through Windows capability management, which is useful if you want SSH-based transport around your rsync workflow. (learn.microsoft.com)

The practical trend is clear:

• WSL for best Linux compatibility.
• MSYS2 for lighter-weight Unix tooling on Windows.
• Cygwin when you already depend on a Cygwin environment. (learn.microsoft.com)

---

Supporting explanations and details

The most important rsync options

-a archive mode
-v verbose
-h human-readable sizes
-z compress over network links
-n dry run
--delete remove files at destination that no longer exist in source
--progress show progress

The two options that matter most for safety are:

• -n / --dry-run
• --delete

The official man page explicitly warns to test deletions with --dry-run first. (rsync.samba.org)

Trailing slash behavior

These two commands are not the same:

rsync -av /src/folder /dest
rsync -av /src/folder/ /dest

With the trailing slash on the source, rsync copies the contents of folder; without it, it copies the folder itself into the destination. This is one of the most common causes of incorrect directory structures. (rsync.samba.org)

Permissions on Windows-mounted drives

WSL’s permission handling on Windows files is not identical to native Linux filesystem semantics. Microsoft documents that when accessing Windows files from WSL, permissions are either translated from Windows permissions or read from WSL metadata if metadata is enabled. (learn.microsoft.com)

In practice, if you are backing up ordinary files to /mnt/c or another mounted Windows drive and do not care about POSIX ownership preservation, it is often safer to use:

rsync -rthv --no-perms --no-owner --no-group SOURCE/ DEST/

That recommendation is an engineering best practice derived from Microsoft’s documented permission-mapping behavior for DrvFS. (learn.microsoft.com)

Automation from Windows

You can run a WSL command directly from PowerShell or Command Prompt. Microsoft documents the wsl --distribution <DistroName> form for targeting a specific distro. (learn.microsoft.com)

Example batch file for Task Scheduler:

@echo off
wsl --distribution Ubuntu -- bash -lc "rsync -avh --delete /mnt/c/Users/YourName/Documents/ /mnt/d/Backup/Documents/"

That is a practical way to schedule nightly backups on Windows while still using Linux rsync. (learn.microsoft.com)

---

Ethical and legal aspects

When using rsync on Windows systems, especially in corporate or engineering environments, consider the following:

• Do not accidentally sync private keys, credentials, customer data, or regulated data sets.
• If syncing to a remote host, confirm that SSH access and storage location comply with your organization’s security policy.
• If you enable OpenSSH Server on Windows, remember it opens inbound SSH access and relies on correct firewall and account configuration. Microsoft notes that installation creates a firewall rule for TCP port 22. (learn.microsoft.com)

From a safety standpoint, rsync --delete deserves special caution because a path mistake can erase the wrong destination tree. The official man page explicitly warns about this. (rsync.samba.org)

---

Practical guidelines

• Start with WSL unless policy or tooling prevents it. (learn.microsoft.com)
• Always test with --dry-run before the first real sync, especially if using --delete. (rsync.samba.org)
• Be careful with the source trailing slash; it changes copy semantics. (rsync.samba.org)
• Use SSH keys for remote automation rather than passwords, especially for scheduled jobs.
• If syncing to /mnt/c or another Windows drive, consider --no-perms --no-owner --no-group if permission preservation is not required, because Windows permission mapping differs from native Linux. (learn.microsoft.com)
• For best performance in WSL, keep active project trees in the Linux filesystem rather than on mounted Windows drives. (learn.microsoft.com)
• If Windows is the remote target, ensure the Windows side also has an rsync executable available. (rsync.samba.org)

A good “safe first command” is:

rsync -avhn --itemize-changes /mnt/c/Users/YourName/Documents/ /mnt/d/Backup/Documents/

Then remove -n when the preview looks correct.

---

Possible disclaimers or additional notes

• rsync is excellent for synchronizing file trees, but it is not a full Windows system-imaging solution.
• Files locked by Windows applications may not behave the way a backup product using Volume Shadow Copy would.
• If you only need Windows-to-Windows mirroring and do not specifically need rsync, native Windows tools may sometimes be operationally simpler.

Also, one sample answer you provided suggested Git Bash as a primary installation path. I would not use that as the main recommendation. In practice, WSL, MSYS2, and Cygwin are clearer and better-documented routes for obtaining and maintaining rsync on Windows. The official package-managed paths are WSL distro packages, MSYS2 pacman, and the Cygwin installer. (packages.msys2.org)

---

Suggestions for further research

If you want to go deeper, the next useful topics are:

• rsync filters: --exclude, --exclude-from
• incremental backup strategies using --link-dest
• Windows Task Scheduler integration with WSL
• SSH key management for unattended backups
• WSL wsl.conf mount options if you need tighter permission control on Windows drives. Microsoft documents configurable permission masks for mounted Windows filesystems. (learn.microsoft.com)

If your real goal is one of these, I can give you a focused setup:

1. Local backup on the same PC
2. Sync Windows files to a Linux server
3. Sync from Linux to a Windows machine
4. Automate rsync with Task Scheduler

---

Brief summary

To use rsync on Windows, the best approach is usually:

1. Install WSL with wsl --install
2. Install rsync inside the Linux distro
3. Access Windows files under /mnt/c, /mnt/d, etc.
4. Start with --dry-run
5. Use --delete only after you verify the paths. (learn.microsoft.com)

If WSL is not an option, use MSYS2 or Cygwin instead. (packages.msys2.org)

If you want, I can now give you a copy-paste setup for WSL on Windows 11/10, or a one-line rsync command for your specific source and destination folders.

Disclaimer: The responses provided by artificial intelligence (language model) may be inaccurate and misleading. Elektroda is not responsible for the accuracy, reliability, or completeness of the presented information. All responses should be verified by the user.