When performing backups between Linux systems with different user configurations, maintaining file permissions becomes particularly tricky. The scenario where source files belong to user vmail but the destination lacks this user creates a permission preservation challenge during rsync operations.

By default, rsync with -a (archive) flag preserves:

- Permissions (mode)
- Ownership (uid/gid)
- Timestamps
- Special device files

However, when the destination system lacks matching UID/GID, the behavior changes:

sudo rsync -av --delete --progress -e "ssh -p pNumber" \
--rsync-path="/usr/bin/rsync" \
/vmail/ user@my_backup_server:/home/user/backups/vmail/

Option 1: Numeric UID/GID Preservation

Add --numeric-ids to preserve raw IDs:

rsync -av --numeric-ids --delete /vmail/ backup:/path/

This transfers the numeric UID/GID values regardless of username mapping.

Option 2: Mapping Users

Create matching UID/GID on destination:

# On backup server:
sudo groupadd -g 5000 vmail
sudo useradd -u 5000 -g vmail -d /nonexistent -s /bin/false vmail

Option 3: Ownership Adjustment

Modify ownership during transfer with --usermap and --groupmap:

rsync -av --usermap=vmail:backupuser --groupmap=vmail:backupgroup \
/vmail/ backup:/path/

For complete restoration capability:

1. Maintain consistent UID/GID across systems
2. Document all permission mappings
3. Consider using --super when restoring to handle root-owned files

Example restore command preserving permissions:

sudo rsync -av --numeric-ids --delete \
backup:/home/user/backups/vmail/ /vmail/

For complex environments, combine with getfacl/setfacl:

# Backup ACLs
getfacl -R /vmail > vmail_acls.txt

# Restore ACLs
setfacl --restore=vmail_acls.txt

Remember to test permission preservation with sample directories before full backups.

---

When using rsync for backups between Linux systems, a common issue arises when user accounts (and consequently UID/GID mappings) differ between source and destination machines. The original command:

sudo rsync -av --delete --progress -e "ssh -p pNumber" --rsync-path="/usr/bin/rsync" /vmail/ user@my_backup_server:/home/user/backups/vmail/

faces this exact problem where the source files are owned by vmail user which doesn't exist on the backup server.

By default, rsync preserves:

• File permissions (mode)
• Ownership (UID/GID numbers, not names)
• Timestamps

The critical detail is that Linux systems track ownership via numeric UID/GID, not usernames. When the -a (archive) flag is used, rsync preserves these numeric values.

Let's examine what actually happens with file ownership during transfer:

# On source machine (vmail exists):
ls -ln /vmail/sample_folder
# Output shows UID/GID numbers (e.g., 1001:1001)

# After rsync to destination (vmail doesn't exist):
ls -ln /home/user/backups/vmail/sample_folder
# Shows same UID/GID numbers as source

For complete restoration capability, you have several options:

# Option 1: Create matching UID/GID on backup server
sudo groupadd -g 1001 vmail
sudo useradd -u 1001 -g vmail vmail

# Option 2: Use rsync's --numeric-ids flag (explicitly preserves numbers)
rsync -av --numeric-ids ...

# Option 3: Map users during transfer (advanced)
rsync -av --usermap=1001:newuser --groupmap=1001:newgroup ...

For maximum reliability in your email backup scenario:

sudo rsync -av --delete --numeric-ids --progress \
    -e "ssh -p pNumber" \
    --rsync-path="/usr/bin/rsync" \
    /vmail/ user@my_backup_server:/home/user/backups/vmail/

This ensures UID/GID numbers are preserved regardless of username mappings.

After backup, run this on both systems to verify permissions:

#!/bin/bash
SOURCE="/vmail"
DEST="/home/user/backups/vmail"

echo "Source permissions:"
find "$SOURCE" -printf "%m %u:%g %p\n" | head -5

echo -e "\nDestination permissions:"
ssh -p pNumber user@my_backup_server "find $DEST -printf \"%m %u:%g %p\n\"" | head -5