Lessons from Failed Rsync Backups | Generated by AI

Home 2026.06

Now I have the full picture. Here’s what went wrong last time:

Issue 1: SSH connection drops (rsync error code 255)

rsync error: unexplained error (code 255) at ... io.c(453) [sender=2.6.9]

The SSH connection dies mid-transfer. The original backup.sh had no ServerAliveInterval — when a large transfer (Projects ~27GB) runs for a long time with no data flowing on the control channel, the router or OS silently kills the TCP connection. rsync gets a broken pipe and exits with code 255.

Issue 2: Old rsync version (2.6.9) macOS ships rsync 2.6.9 from 2006. It has known bugs with:

Issue 3: node_modules symlink explosion Projects with node_modules (like admin-vue3-micro-qiankun) have tens of thousands of symlinks. The backup log is full of symlink lines. rsync 2.6.9 struggles with these — slow scanning, broken link resolution, connection timeout during the file list phase.

Issue 4: Photos library too large to transfer in one shot The Photos library (照片图库.photoslibrary) is ~4GB with 4,888 original files. The first attempt (backup.sh → fix_backup.sh) failed. The fix scripts evolved:

Issue 5: No --partial flag originally Without --partial, an interrupted rsync deletes the partially-transferred file. So every connection drop means restarting that file from scratch. With --partial, rsync keeps the partial file and resumes.

Issue 6: No timeout protection The original script had no --timeout=N. When the network stalls, rsync hangs forever. The fix scripts added --timeout=300 and --timeout=600.

How the current mini-backup.sh addresses these:

Want me to add --exclude='node_modules' and --exclude='.git' to skip the biggest problem dirs?


Back Donate