How to preserve ownership and permissions with rsync

File ownership, group ownership, modes, and modification times can decide whether a copied service tree starts correctly or a restored shared directory remains usable. A plain file copy can silently replace those values with the receiving user's defaults, so metadata preservation needs to be part of the rsync command and the verification step.

The -a archive option includes recursive copy, symlink preservation, permissions, modification times, group, owner, and device handling. Ownership preservation still depends on receiver privileges, so run the receiving side as root when the destination must keep source owners and groups. Use --numeric-ids for migrations where matching numeric UID and GID values matter more than account names.

These steps target Linux or Unix file trees where the destination should keep source metadata, such as application content, backups, shared directories, or staged restores. Verify representative files and directories after the transfer because a successful rsync exit only proves the copy completed, not that the destination account database or filesystem accepted every metadata value.

Steps to preserve ownership and permissions with rsync:

Inspect the source metadata for a representative file before copying.
```
$ stat -c '%n %U:%G %a %s bytes %y' /srv/source/app.conf
/srv/source/app.conf appuser:appgroup 640 12 bytes 2026-06-06 03:30:00.000000000 +0000
```
The important fields are owner, group, mode, size, and modification time. Use a directory path as well when directory execute bits or ownership are part of the access model.
Run rsync in archive mode and keep numeric IDs when the destination should receive the same UID and GID numbers.
```
$ sudo rsync -a --numeric-ids --itemize-changes /srv/source/ /srv/destination/
>f+++++++++ app.conf
```
The trailing slash on /srv/source/ copies the contents of the source directory into /srv/destination/.

Run the receiving side with enough privilege to set ownership. An unprivileged receiver usually cannot create files owned by another user.

Verify the destination metadata after the transfer.

$ stat -c '%n %U:%G %a %s bytes %y' /srv/destination/app.conf
/srv/destination/app.conf appuser:appgroup 640 12 bytes 2026-06-06 03:30:00.000000000 +0000

Check directories separately when their modes control traversal or service access.

$ stat -c '%n %U:%G %a' /srv/source /srv/destination
/srv/source appuser:appgroup 750
/srv/destination appuser:appgroup 750

Repeat the transfer with a dry run before using destructive options such as --delete on a production destination.
```
$ sudo rsync -a --numeric-ids --dry-run --itemize-changes --delete /srv/source/ /srv/destination/
```
Related: How to preview rsync changes before syncing