SSD Cloning on Raspberry Pi 4 Updated

3 disks from Banggood

The subject of this blog entry is, in the main, about cloning (for backup mainly) from one Solid State Drive (SSD) on the Raspberry Pi 4 (RPi4) to another SSD. Why SSD? These “drives” are MANY times faster than SD, as low as twice the price of SDs and are supposedly much more reliable – I’ve covered that here and here. I’ve also taslked on occasion about eMMC which is slower than SSD but faster and more reliable than SD.

In this entry I will refer several times (not to promote Sandisk particularly) to a quality Sandisk 32GB microSD sitting in a USB adaptor – so from now on I’ll refer to it as sd-usb for ease. I’ll also refer to clone (clone) and cclone – (clean clone) – simple functions I made to use rpi-clone more easily on the Raspberry Pi.

My use of the word “clone” assumes the microSD or SSD has been used before with the same partitioning, variation cclone recreates partitions and does formatting – taking much longer.

If I add a “b” to the end – i.e. ccloneb – I’m cloning to SDB – often the second USB 3 socket on the RPI4. I assume you understand terms like SD (microSD) and SSD and finally that the USB connectors on the RPi4 usually but sadly not always connect to SDA and SDB etc.

A way is needed to fix the boot order on these and I’m not alone in wanting this. On the RPi4 you get a pair of USB3 connectors (fast) and a pair of USB2 connectors (the latter being too slow for disk use – better suited to mouse, keyboard and/or other slow peripherals).

USB3-to-SATA adaptor
USB3-to-SATA adaptor

I’ve been using a Blitzwolf USB SSD drive back in the UK for some time now, using Sandisk microSDs for backup, but here in Spain I want to go one step further for the ultimate in speed.

First attempts at cloning an SSD to another SSD

So, booting from and using an SSD on RPi4 all sorted? Well, that’s how it seemed until days ago.

I originally bought a nice (and cheap) Kingdion 120GB SSD to run my RPi4 from a 2.4A plug-in-the-wall supply and it has been working for couple of weeks flawlessly. Thanks to rpi-clone, I have a cloned backup at all times on my sd-usb.

So, now with my latest mailbag in tow, I plugged in a brand new Vaseky 60GB Sata III 6Gbps SSD and then cloned the entire RPi4 from the Kingdion SSD to the Vaseky using RPI-clone – (full clone to sdb – ccloneb). No problem – 5:45 minutes. EASY.

Excited, I tried cloning the original Kingdion onto a working, tested Blitzwolf BW-SSD1 128GB Sata III 6GBps SSD – nope – the system died as soon as I plugged in the latter – no commands recognised. So after a reboot, I tried cloning the working original to a working, tested Kingspec Sata III 64GBbps SSD – the system died again. Before anyone else mentions cheap drives, this is some kind of power-related RPi issue.

Next, I tried a ccloneb of that first successful Vaseky clone to my sd-usb – of course, this ccloneb was going to take a LOT longer than the 5 minute SSD to SSD ccloneb – after 30 minutes, things were looking grim, but a quick check showed the RPi4 was still working…at this point I started to remember that a microSD in a USB adaptor is even slower than using simple direct SD… not something you’d want to do voluntarily – especially the full ccloneb (as against subsequent differential clones (clone) which take FAR less time – often just a few minutes, if that).

I of course had to do the full ccloneb which includes partition updating – as these were new, straight-out-of-the-box SSDs.

As you might imagine, I was itching to try a bigger power supply – if that ccloneb to sd-usb would only work, there was a good chance my new SSDs were fine, only needing more power. AT LAST, 78 minutes on and the ccloneb to the sd-usb finished. So now I could progress after ensuring the sd-usb worked…. power off – out with the Vaseky SSD, power on – test the sd-usb – connect the Blitzwolf SSD…and I started a simple cloneb…

Fast or WHAT!

Of course, all of this gets much easier when doing normal clones… so cloning from my original SSD to the already-recently-cloned Vaseky SSD took all of 5:45 minutes as you saw above – knowing that it is WRITING that is the bottle-neck, I was not surprised to find that cloning from the sd-usb to the Blitzwolf took only 7:58 minutes. And now, starting to full clone to the Kingspec, the full clone with rpi-clone took 7:56 minutes – so I can’t really say there is any difference here but I believe I CAN claim that my original issues were related to RPI4 power stability.

Well, on connecting the second SSD, even with a better lead, the RPi4 died, unable to recognise commands. Powering off and then on with both SSDs already connected produced a working system but then I didn’t know which of the two clones was doing the work.. in this case as one was a minutes-old clone of the other, no problem…. but that won’t usually be the case. I’m working on the assumption that the small surge when powering up the second drive was enough to kill the system.

Mastered? – but which SSD is which?

Now using cloneb, not ccloneb, I expected a very short clone time as rpi-clone was now only cloning changes – and I was right… 1:38 minutes all-in. Amazing.

Getting there, but I needed to sort out exactly WHY I can hot-plug a second sd-usb no problem but 2 out of 3 hot-plugged SSDs would kill the RPi4. This is an issue until I can guarantee which SSD the RPI4 will boot from – at which point I will be able to properly pursue an SD-free life 🙂

Any knowledgeable reader not yet bored to death, please DO chip in at this point. Is there a way to guarantee that SDA appears on the top USB connector and SDB appears on the bottom? It all seems a bit vague. I’ll get to grips with why adding in the second SSD live kills the RPi4, when I’ve live-added sd-usb and microSD countless times in the past without issue. I’m assuming PSU/lead issues but could it could be internal RPi4 tracking losses?

Update July 25, 2020

After changing the power lead – and listening to comments in here, I then succeeded in hot-cloning (cloneb) from Kingdion to Vaseky, then Kingdion to Kingdion, both without issue. When I tried the Blitzwolf – immediate death again.

Kingdion to Kingspec or Vaseky, no problem… in each case, the working clones took very little time – as there was no partitioning to do and very little actual updating.

What I DID do was switch to a 2.1A QC3 charger and a shorter lead, powered up the RPI4 with the Kingdion, checked all was well, then plugged in the Blitzwolf – dead – again. After turning the power off, I left ONLY the Blitzwolf in – the RPI4 came up no problem as you would expect. So, no damage to either disk (in all of this I’ve lost no data)..

Finally, I inserted the original Kingdion and powered the RPI4 with the monster 65w Ravpower power pack I cover elsewhere in here. All was well, so I hot-plugged the Blitzwolf SSD- and once AGAIN – RPi4 – dead. As a last test I powered up with both SSDs in place.

THIS time the RPi4 powered up no problem so I did a clean shutdown, power cycle and again, no problem. In each of the latter two cases, the Blitzwolf started flashing blue first – it was in the TOP USB connector. So, I tried once again but with the connectors swapped over.

Could it be solved?? Erm, no, the Blitzwolf STILL started the ball rolling. There HAS to be a way to “FIX” these USB sockets to a particular connection i.e. SDA, SDB etc. And the rest of it is definitely looking like a power spiking issue, even with a very large supply and short lead – possibly internal to the RPi4?

Various markings on the RPi4 board state:

Raspberry Pi 4 Model B (c) Raspberry Pi 2019
OV-1118 1919 94V-O H 
FCC ID2ABCB RPI46
IC 20953 RPI4B

The board is enclosed in an Argon One case with the fan on full (Spain). Powered back up using the original Kingdion SSD, as far as I can tell, no damage done – my installation is running perfectly but for the problem of SSD to SSD cloning – but READ ON:

Update July 28, 2020 – Some Success but not perfect

Clearly there is an issue putting too much load on the RPi4 USB connectors. It may transpire that this is a power issue, it may not. But there is also the issue of being confident which SSD the Pi is booting from in a situation where an SSD is running the show and another is used to make clones.

A potential answer hit me at the weekend. Use a simple 7-port (why not, they are cheap), powered USB hub with individual switches. I plugged an sd-usb into the hub with the relevant power switch turned off… I turned it on and made a clone, no problem. I then did the same again with an SSD – that worked – and then the heaviest of the lot – the Blitwolf – ALMOST perfect. It worked a treat – but I have a voltage check on my Pi (which on a perfect day returns “0”. On a BAD day it returns “5005”) – this returned “5000” – everything is working but there was a minor voltage drop at some point. I’m going to get my scope on this when the weather cools off a little.

I turned the hub output off – hence absolutely ensuring the original SSD gets the job in any subsequent reboot. The NEXT mod will be to put a dirt cheap ESP-relay on the individual hub switch(es) – possibly two and both SSDs on the hub – for 100% control. I’m thinking Sinilink – see my blog entry on the subject. This is all starting to come together very well – not perfect but I’ve already had useful feedback in the comments and welcome more.

I’ve now put BOTH SSDs on the 7-port powered hub and all works – but I STILL see that “5000” past voltage drop error on the Pi when I turn on the second SSD. I won’t be happy until that goes away.

Update August 14, 2020

Keep your thoughts coming, ladies and gents. Note, meanwhile, that when talking about SSDs in this entry – I refer to using SATA SSDs via USB3-to-SATA adaptors – I got mine (three now) from Amazon (just for the sake of speed) – but I’ve just had a conversation with fellow blogger Mat Zolnierczyk and he’s been trying out the Geekworm X829 SATA board. I’ve no experience of this board but Mat isn’t stupid so you might find his gripe worth a read. If your experience with that board is different, please do feed back to me.

Facebooktwitterpinterestlinkedin

44 thoughts on “SSD Cloning on Raspberry Pi 4 Updated

  1. So I’m assuming your main SSD is SDA (best power off – remove SDB – power back on to be sure – I’d hate to be responsible for you wiping anything) – sure – yes, you can do a “sudo rpi-clone sdb -f -U” – once you have done it the first time, no need for “-f”

    Better – as user ROOT make yourself some functions in /etc/bash.bashrc

    I add these to my bash.bashrc so I can clone from SD to SSD and from SSD to SD etc, clean or normal, with ease as I do one of these every few days.

    If this blows up your PI you are on your own.

    BLACK=’\033[0;30m’
    RED=’\033[0;31m’
    GREEN=’\033[0;32m’
    BROWN=’\033[0;33m’
    BLUE=’\033[0;34m’
    PURPLE=’\033[0;35m’
    CYAN=’\033[0;36m’
    LIGHTGRAY=’\033[0;37m’
    DARKGRAY=’\033[1;30m’
    LIGHTRED=’\033[1;31m’
    LIGHTGREEN=’\033[1;32m’
    YELLOW=’\033[1;33m’
    LIGHTBLUE=’\033[1;34m’
    LIGHTPURPLE=’\033[1;35m’
    LIGHTCYAN=’\033[1;36m’
    WHITE=’\033[1;37m’
    NC=’\033[0m’

    clone () {
    printf “${LIGHTBLUE}Creating a quick clone on SDA${NC}\n”
    touch /home/pi/clone-date
    bashCmd=(sudo rpi-clone -U sda)
    if [ -n “$1” ]; then
    bashCmd+=(-s “$1”)
    fi
    “${bashCmd[@]}”
    }

    cclone () {
    printf “${LIGHTRED}Creating a full clone on SDA${NC}\n”
    touch /home/pi/clone-date
    bashCmd=(sudo rpi-clone -f -U sda)
    if [ -n “$1” ]; then
    bashCmd+=(-s “$1”)
    fi
    “${bashCmd[@]}”
    }

    cloneb () {
    printf “${LIGHTBLUE}Creating a quick clone on SDB${NC}\n”
    touch /home/pi/clone-date
    bashCmd=(sudo rpi-clone -U sdb)
    if [ -n “$1” ]; then
    bashCmd+=(-s “$1”)
    fi
    “${bashCmd[@]}”
    }

    ccloneb () {
    printf “${LIGHTRED}Creating a full clone on SDB${NC}\n”
    touch /home/pi/clone-date
    bashCmd=(sudo rpi-clone -f -U sdb)
    if [ -n “$1” ]; then
    bashCmd+=(-s “$1”)
    fi
    “${bashCmd[@]}”
    }

    clonem () {
    printf “${LIGHTBLUE}Creating a quick clone on MMCBLK0${NC}\n”
    touch /home/pi/clone-date
    bashCmd=(sudo rpi-clone -U mmcblk0)
    if [ -n “$1” ]; then
    bashCmd+=(-s “$1”)
    fi
    “${bashCmd[@]}”
    }

    cclonem () {
    printf “${LIGHTRED}Creating a full clone on mmcblk0${NC}\n”
    touch /home/pi/clone-date
    bashCmd=(sudo rpi-clone -f -U mmcblk0)
    if [ -n “$1” ]; then
    bashCmd+=(-s “$1”)
    fi
    “${bashCmd[@]}”
    }

    1. Thanks for that. Can I just cut and paste the above code immediately after all the bash shortcuts?
      On my response to lsblk I get
      NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
      sda 8:0 0 119.2G 0 disk
      ├─sda1 8:1 0 256M 0 part /boot
      └─sda2 8:2 0 119G 0 part /
      sdb 8:16 1 59.8G 0 disk
      └─sdb1 8:17 1 59.8G 0 part

      does the line “sda1 8:1 0 256M 0 part /boot” not infer that sda is the boot drive?

  2. Forgive me if I’m being stupid in regards to identifying drives for backup. I have
    pi@atticPI:~ $ lsblk
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    sda 8:0 0 119.2G 0 disk
    ├─sda1 8:1 0 256M 0 part /boot
    └─sda2 8:2 0 119G 0 part /
    sdb 8:16 1 59.8G 0 disk
    └─sdb1 8:17 1 59.8G 0 part

    Does this mean that sda is boot and backup drive is sdb
    and I can safely do a sudo rpi-clone sdb -f -U

  3. Hello, I am commenting this post as I did not find a more appropriate one…
    I have an RPi4 with Buster installed in an sd card (A2 type) and I wanted to test the new boot from ssd disk.
    The first thing to do is to clone the sd card into the ssd disk. I found a blog that suggested using the application “SD Card Copier” available in the Accessories section of the menu. I did this and worked flawlessly, that is when I removed the SD card and booted from the ssd disk, everything worked fine and I was very happy. I am using the RPi to run a home automation application which is always on, so I left my RPi on all the night. This morning, when I tried to access the home automation software (via web) the RPi seemed frozen, although I noticed the SSD activity LED. It seems the RPi had to restore from an hibernation state. Eventually it worked again, but it took more than 2 minutes to awake!
    I wanted to ask you:
    1) Is the SD Card Copier tool a valid approach to clone an sd card into an SSD? If not, what is the best and safe procedure to do this?
    2) Can the unacceptable delay due to the cloning process I used? In other words, as you are using the USB ssd boot for sime time, did you notice a behavior like this?

    Thanks !
    Luciano

    1. For cloning, I usse only RPI-CLONE which works perfectly – I cannotr comment on the grapighical CAR COPIER method as I’ve not used that in ages.
      I’ve not noticed any issues with SSDs – other than perhaps needing external power for some of them – to keep the voltage drops away.

      1. Thanks for the quick feedback Peter!
        So, do you think that the behavior I described can be caused by am SSD power issue (I mean, requiring too much power)?
        Might be worth to try a different ssd?
        Thanks
        Luciano

          1. Ok. Power should be ok, as I bought the original power supply which delivers 3amps.
            Anyway, and this is the last minute news, I verified that actually I have the very same problem with the sd card now and I don’t know why…

            So… do you know if the ootb configuraiton includes a sort of sleep mode or hibernation that starts after a period of inactivity?

            I am using the Buster desktop edition, but I have disconnected the screen and the keyboard, just the wireless.
            I tried to look for something about power management, but I found only references about the sleep mode which is connected with the desktop.
            As I see it should not influence this behavior but… who knows
            Thanks
            Luciano

            1. so nothing to do with SSD then. Normal configuration does not include sleep. Screen sleeps but you’re not using that. I aalways run my RPis headless. No need to mess with sleep or power management if you are using a normal Buster setup.

Leave a Reply

Your email address will not be published.

Leave the field below empty!