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? They are MANY times fater than SD, as low as twice the price of SDs and are supposedly much more reliable – I’ve covered that here and here. Latest updates at the END.
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).
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.