从Windows远程备份树莓派SD卡时的错误及恢复异常问题求助

1. Fixing Error 109 (Pipe Ended) During SSH+DD Backup #

That Error 109 is almost always a compatibility hiccup between Windows' dd implementation and the Linux pipeline over SSH. Here are a few reliable fixes:

Option 1: Switch to PowerShell Instead of CMD #

Windows CMD handles quotes and pipes differently than Linux shells, which often breaks the command. Try running this in PowerShell instead:

ssh me@192.168.xxx.yyy 'sudo dd if=/dev/mmcblk0 bs=1M | gzip -c' | dd of=C:\Users\me\Desktop\rPi_backup.gz --progress

Using single quotes around the remote command prevents Windows from mangling the pipe syntax.

Option 2: Backup Locally on Pi First, Then SCP to Windows #

This avoids cross-platform pipe issues entirely:

1. First, run the backup on your Raspberry Pi (flush disk caches first to avoid data corruption):

   ssh me@192.168.xxx.yyy "sudo sync && sudo dd if=/dev/mmcblk0 bs=1M | gzip -c > /tmp/rpi_backup.gz"
   

2. Once the backup finishes, copy it to your Windows desktop with SCP:

   scp me@192.168.xxx.yyy:/tmp/rpi_backup.gz C:\Users\me\Desktop\
   

3. Don’t forget to delete the temporary file on the Pi afterward:

   ssh me@192.168.xxx.yyy "sudo rm /tmp/rpi_backup.gz"
   

Option 3: Use a Pi-Specific Backup Script #

Tools like raspi-backup are built to handle Raspberry Pi disk backups safely, including cache flushing and partition handling. Install it on your Pi with:

sudo apt update && sudo apt install raspi-backup

Then run a backup to a network share (or local storage) and copy it to Windows afterward.

2. Fixing Post-Restore System Errors #

Your bash syntax error and partition mismatch hint at incomplete or corrupted backup data. Let’s fix this:

Why This Happened #

• The garbled /etc/profile.d/magnum_path.sh file means the backup was truncated or corrupted during transfer (likely related to that earlier pipe error).
• The partition size mismatch (273 vs 272) is usually due to slight differences in SD card sector counts between the original and target card, or unflushed cache during backup.

Step-by-Step Fixes #

1. Recreate the Backup Properly

   • Before starting the backup, put your Pi into single-user mode to stop all unnecessary disk writes:

     ssh me@192.168.xxx.yyy "sudo init 1"
     

   • Run sudo sync twice to ensure all cached data is written to disk.
   • Use the local-then-SCP method from Section 1 to avoid pipe corruption.

2. Repair the Corrupted System (If You Don’t Want to Re-Backup)

   • Mount the problematic SD card on a Linux machine (or boot the Pi from a working SD card and mount the corrupted one via USB).
   • Delete the broken script file:

     sudo rm /path/to/mounted/sd/etc/profile.d/magnum_path.sh
     

     If you need this file, copy it from a working Raspberry Pi installation.
   • Check and repair the root filesystem:

     sudo umount /path/to/mounted/sd/root
     sudo e2fsck -f /dev/sdX2
     

     Replace /dev/sdX2 with your root partition device name.

3. Restore Best Practices

   • Make sure your target SD card has at least the same number of sectors as the original (use sudo fdisk -l on both to check).
   • When restoring with BalenaEtcher, use the original .gz file directly (Etcher can decompress it on the fly) instead of manually decompressing it first—this avoids potential decompression errors.

内容的提问来源于stack exchange，提问作者RDK