I've been trying to backup my RPi Model B but I'm having no luck whatsoever. Here's what my Macbook's terminal shows under "diskutil list":
/dev/disk2 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *4.0 GB disk2
1: Windows_FAT_16 RECOVERY 121.8 MB disk2s1
2: Linux 33.6 MB disk2s3
3: Windows_FAT_32 BOOT 62.9 MB disk2s5
4: Linux 3.7 GB disk2s6
This is what I've tried so far:
- Using dd on the Pi itself (and copying to an external hdd). This is how I used to backup my Pi. When I've tried this lately over ssh the Pi becomes unresponse, I lose network connection and have to reboot the Pi.
- Using dd on my Macbook running macOS Sierra. dd will create an image file of 47.2 mb and stops saying "Resource Busy" despite me running "diskutil umountDisk /dev/disk2" first. After a bit of trial and error, I've found when I run dd on each partition individually it works fine until I try the RECOVERY partition. This partition will give the "Resource Busy" error immediately.
- I've tried making the image with Pi-Baker and Apple's Disk Utility. None of which work.
I've reached my wits end. Could the issues be related? The network becoming unreachable when running dd on the Pi? The RECOVERY partition not allowing dd on the mac?
Like I said I used to do this on my Pi all the time to create backups of my SD. My ultimate goal with this is to transfer my Pi to a larger SD card.
dd
from a running system is a bad idea for the reasons explained in the second paragraph here. It should work in the same sense that hammering in a screw because you can't be bothered with (or don't have) a screwdriver will often work, but it may have less than ideal results with unfortunate consequences. – goldilocks Nov 11 '16 at 14:58dd
on the card out of the pi is fine, but that's a strange problem. I'm not an OSX user, butdd
is a very low level tool; it just copies raw blocks regardless of the content. You can copy a disk that contains no partitions, no formatting, random garbage withdd
, so when it hangs it implies there is a hardware level issue. How old is the SD card/how much has it been used? You might want to ask about this on Ask Different. Unfortunately I don't think there is a universal way to verify the physical integrity of all SD cards. – goldilocks Nov 11 '16 at 16:01uname -r
). If they aren't, that's easy enough to work around, though. The other issue would be partitions listed in/etc/fstab
... – goldilocks Nov 11 '16 at 17:12