Resolving Hard Links Issues in Rsync Backups on Mac OS X

Posted on in system_administration

Backing up systems efficiently is crucial for data integrity and space management. Using hard links with rsync is a common strategy to conserve disk space. However, macOS can sometimes present challenges with hard links, especially when dealing with external drives. This article revisits the issue of hard links not working in rsync backups on macOS, providing modern solutions to ensure your backups are efficient and reliable.

The Problem

While setting up a macOS system for backing up multiple OS X and Linux systems using rsync with the --link-dest option, I noticed that the backups were consuming more space than expected. The issue stemmed from hard links not working correctly, leading to redundant file copies and rapidly filling up the backup disk.

Symptoms

  1. High Disk Usage: Despite using hard links, the backup disk filled up quickly.
  2. Unknown Owner and Group: Files in the backup directories showed unknown owner and group.
  3. Different Inode Numbers: Files that should have been hard linked had different inode numbers.

Diagnosing the Issue

To diagnose the issue, I examined the files in the backup directories using ls -l and ls -i commands.

Checking File Attributes

# ls -l etc*/xpdfrc
-rw-r--r--  1 _unknown  _unknown  3768 Feb  7  2006 etc-1/xpdfrc
-rw-r--r--  1 _unknown  _unknown  3768 Feb  7  2006 etc-2/xpdfrc
-rw-r--r--  1 _unknown  _unknown  3768 Feb  7  2006 etc-3/xpdfrc
-rw-r--r--  1 _unknown  _unknown  3768 Feb  7  2006 etc-4/xpdfrc
-rw-r--r--  1 _unknown  _unknown  3768 Feb  7  2006 etc-5/xpdfrc

Checking Inode Numbers

# ls -i etc*/xpdfrc
37073368 etc-1/xpdfrc
37104392 etc-2/xpdfrc
37181270 etc-3/xpdfrc
37519024 etc-4/xpdfrc
38041542 etc-5/xpdfrc

These commands revealed that the files were not hard linked (each file had a different inode number) and showed unknown ownership.

Root Cause

The issue was traced back to how macOS mounts external drives. In macOS Leopard and later, external drives are often mounted with the noowners flag, which prevents the system from preserving file ownership information correctly. This discrepancy causes rsync to treat files as different, leading to redundant copies.

Verifying Mount Options

# mount
/dev/disk0s3 on / (hfs, local, journaled)
devfs on /dev (devfs, local)
fdesc on /dev (fdesc, union)
map -hosts on /net (autofs, automounted)
map auto_home on /home (autofs, automounted)
/dev/disk1s3 on /Volumes/Backup (hfs, local, nodev, nosuid, journaled, noowners)

The noowners flag on /Volumes/Backup was the culprit.

Solution

To resolve this issue, we need to enable ownership on the external drive using the vsdbutil command. Although vsdbutil has been deprecated, it is still functional for this purpose as of 2024.

Enabling Ownership

# sudo vsdbutil -a /Volumes/Backup
# sudo vsdbutil -c /Volumes/Backup
Permissions on '/Volumes/Backup' are enabled.

Verifying Mount Options (Again)

After enabling ownership, verify the mount options to ensure the noowners flag is removed:

# mount
/dev/disk0s3 on / (hfs, local, journaled)
devfs on /dev (devfs, local)
fdesc on /dev (fdesc, union)
map -hosts on /net (autofs, automounted)
map auto_home on /home (autofs, automounted)
/dev/disk1s3 on /Volumes/Backup (hfs, local, nodev, nosuid, journaled)

Testing the Fix

With ownership enabled, rerun the rsync backups to verify that hard links are working correctly.

Clearing Existing Backups and Retesting

  1. Clear existing backup directories:

    # rm -rf /Volumes/Backup/*
    
  2. Run the backup script twice to ensure hard links are created:

    # ./backup_script.sh
    # ./backup_script.sh
    
  3. Verify hard links and inode numbers:

    # ls -l etc*/xpdfrc
    -rw-r--r--  2 root  wheel  3768 Feb  7  2006 etc-1/xpdfrc
    -rw-r--r--  2 root  wheel  3768 Feb  7  2006 etc-2/xpdfrc
    
    # ls -i etc*/xpdfrc
    39130911 etc-1/xpdfrc
    39130911 etc-2/xpdfrc
    

Conclusion

By enabling ownership on the external drive, we resolved the issue of hard links not working in rsync backups on macOS. This fix ensures efficient use of disk space and reliable backups. If you encounter similar issues, check your drive's mount options and ensure ownership is enabled.

Stay tuned to our blog at slaptijack.com for more in-depth tutorials and insights into modern software development practices. If you have any questions or need further assistance, feel free to reach out. Keep your backups efficient and reliable!

Slaptijack's Koding Kraken