SSD Cloning on Raspberry Pi 4

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? They can be only a little more expensive than SDs – are supposedly much more reliable and are DEFINITELY MANY TIMES faster – I’ve covered that here and here.

In this entry I will also 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 “clone” assumes the microSD or SSD has been used before with the same partitioning, 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 andI’m not alone. On the RPi4 you get a pair of USB3 connectors 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 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 Kingspec Sata III 64GBbps SSD – the system died again. Before anyone else mentions cheap drives, this is an RPi issue to do with power.

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 microSD in a USB adaptor is even slower than using simple 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 new SSDs were used straight out of the box.

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 he 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 live plug in a second sd-usb no problem but 2 out of 3 SSDs plugged in live would kill the Pi. This is an issue until I can guarantee which SSD the RPI4 will boot from – at which point I will be able to start 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 board state:

Raspberry Pi 4 Model B (c) Raspberry Pi 2019
OV-1118 1919 94V-O H 
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.

Keep your thoughts coming, ladies and gents.


29 thoughts on “SSD Cloning on Raspberry Pi 4

  1. those 60gb ssd are just junk… about 30$ shipped from china, in 2 months, when i can get double that size and a proper GOOD brand for way less than that, and in 2 days… no thanks, i’m not going from the problems of sd cards to the ones of unbranded ssds… and amazon will never ask me anything about bad items, even after 1 year, 364 days and 23 hours and 59 minutes… 🙂

    1. Up to now your experience is different to mine, Antonio – I can only assume you’ve had a bad cheap SSD in the past. As for shipping, AliExpress do indeed appear to have very variable deliveries right now, I got my drives from Banggood in a couple of weeks shipped straight to Spain. I didn’t check country of origin.

      My first Kingdion came from Amazon UK and has been perfect – I’ve no reason to suspect the Kingdion from China will be any different. I will of course post longer term results in here as time goes on. WAY too short a time to tell right now, but I can say I HAVE had the odd SD fail on me but as yet no SSD issues. I’m more concerned about the situation with two SSDs on one RPI4 as Idetailed in the blog.

      1. ok, but honestly, why bother ordering some unbranded and untested on the long run stuff, when it’s more expensive and with less available space (not mentioning the long time shipment and the 0 warranty), when you have better stuff from amazon? double the size, cheaper, faster, branded… with no questions asked in case of warranty…

    1. Hi “a” – no I don’t think it is power draw, more like power on spike and/or issues with Pi4 spike handling – the Argon ONE case may or may not be involved. More thoughts…

  2. I must confess I am confused why people buy the unknown / unbranded SSD’s. I have only ever bought Samsung / kingston and at around £20.00 for 120Gb, good value for money. I don’t want the hassle of my SSD based systems breaking down. Just had an 18 month old NUC fail but Intel replaced it without quibble, so my faith in the NUC is justified.

    1. Bob – for reference – right now, for example – the Kingston 120GB – 26 Euros. They lso have Kingdion (128G) at around 22.59 and Crucial at 27.82

      So, we’ve established the SSDs work well and take some bashing on test – what is needed now is to (a) sort the RPI power spike issue and (b) find a way to fix SDA (for example) to a specific USB connector. This needs ideas guys.

  3. I guess it is worth pointing out for example in the case of Blitzwolf, I’ve looked at lots of their stuff over time and not been disappointed yet. I was not familiar with Vaseky up to now…time will tell – if I hit any issues I’ll certainly feed that back into the blog. For now, the power consumption/spike when hot-attaching the second SSD is my main focus.

    1. Hi Reeferjon – after reading your feedback I pulled the RPI4 out of it’s Argon ONE case and checked the printing on the top and bottom of the PI – I’ve appended to this blog article. Any further thoughts? Your feedback would be appreciated. I’ve no idea which info refers to board version.

  4. hello Pete

    On June 23rd I sent you this

    Here link

    Here snipet from msd docs

    Multiple bootable drives
    When searching for a bootable partition the bootloader scans all USB mass storage devices in parallel and will select the first to respond. If the boot partition does not contain a suitable start.elf file the next available device is selected.

    As with earlier Raspberry Pi models there is no method for specifying the boot device according to the USB topology because this would slow down boot and adds unecessary and hard to support configuration complexity.

    You could try removing the start.elf file from the ssd you dont want to boot, and reinstall file when you require it to boot first
    ps My time in army taught me KISs keep it simple and stupid
    regards Brian

  5. So I’m not sure you can fix device enumeration order, but you may be able to set up udev rules to assign each device its own specific /dev node. I’ve done things like this to e.g. give a useful distinct name to a USB serial adapter. It should work the same with disks, especially USB disks. See udev docs

  6. Pete
    Just a thought, you could go the hardware route and power the second drive through a relay,
    When you want to perform a backup, first bring the drive online via a GPIO pin, and take it offline afterwards. At reboot, the GPIO pin won’t be active, so the drive won’t be seen.

    1. I read that thanks – it is early in the morning – I’m, not sure how tht enables (forces) booting from one drive over another? If you want to take this further- fire away – the ultimate would be to force one USB drive in preference to MMCBLK0 (SD) as it would be handy to leave the SD in place as backup in some cases – right now the PI will always boot off the SD if it is there… (sd-in-a-USB is a lot slower than SD, which in turn is a lot slower than SSD). Really if you have a reason to progress this, I’m all ears as I’m sure are many others.

  7. Hi Patrick – thats pretty much what I’ve done by putting in a 7-port switched hug (end of blog entry) with ESP-MOSFET or relay to follow. I did note however that I still got a (so far harmless) glitch reading in the power). Maybe switching the data lines instead?? Thoughts?

  8. Hi Pete
    It appears that if you’re using a Hub then the problem is easier to solve. First a caveat – , All I’ve done so far is do some research on this during work hours today, so. I haven’t verified this to a great extent.
    It appears that even though you can’t specify a USB device to boot from, you can specify a device to NOT boot from. Check out this link
    It describes the process to update the EEPROM boot loader config, as well as some interesting config settings. You can set the seek order for boot, SD/USB, or USB/SD, or other combinations.
    The one I think will help you the most is this- USB_MSD_EXCLUDE_VID_PID. You can exclude a USB VID/PID During boot, which means the PI won’t try to boot from the device. It’s specifically called out that this is useful for excluding a USB hub from the boot process. I did check and using sudo slush provided the VID/PID for all attached devices including a hub. Unfortunately both USB 3 ports are on the same internal Root hub, So I couldn’t find a way to only boot from 1 of these, however the USB 2 ports are on a different Root hub, so if your ok with the clone process going to a USB 2 port, then you can isolate the clone disk on USB 2. If you use an external hub, then if you exclude it’s VID/PID from boot enumeration, then any drives attached won’t boot.

    Cheers Patrick

  9. Hello Pete

    Sounds like you are overloading Pi’s maximum 1.2A downstream USB port current. I would use a powered USB hub for 2 ssds on my rpi4 as you have done.

    1. Finding the VID and PID of your USB SSD
    Disconnect the USB SSD. In a terminal window, run the command sudo dmesg -C.
    Now, plug in the SSD and run dmesg with no parameters.
    You should get output that looks like this:

    Code: Select all

    [ 4096.609817] usb 2-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
    [ 4096.646369] usb 2-1: New USB device found, idVendor=2109, idProduct=0715, bcdDevice=a0.00
    [ 4096.646385] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 4096.646397] usb 2-1: Product: SABRENT
    [ 4096.646409] usb 2-1: Manufacturer: SABRENT
    [ 4096.646421] usb 2-1: SerialNumber: 000000123AD2
    [ 4096.655154] scsi host0: uas
    [ 4096.669178] scsi 0:0:0:0: Direct-Access SABRENT 2210 PQ: 0 ANSI: 6
    [ 4096.670993] sd 0:0:0:0: Attached scsi generic sg0 type 0
    [ 4096.673710] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)

    The idVendor and idProduct are the two hexadecimal numbers you need to take a note of.

    This from

    A double surge for usb port powered up together. Better to hotinstall 2nd ssd
    During USB mass storage boot, power to the USB ports is switched off for a short time to ensure the correct operation of USB mass storage devices. Most devices work correctly using the default setting: change this only if you have problems booting from a particular device. Setting USB_MSD_PWR_OFF_TIME=0 will prevent power to the USB ports being switched off during USB mass storage boot. Default: 1000 (1 second)

    regards Brian

    1. Right I’ll go through that now. I have powered hub on both SSDs. I just tried hot-powering the second SSD – still get 5000 power drop message.

      Erm, in what file is that “USB_MSD_PWR_OFF_TIME=0 setting?

      As your suggestion (almost) with only the main SSD running in the hub, I did sudo dmesg -C
      nothing (deliberately I assume)
      I then typed sudo dmesg
      I then turned on the second SSDS

      896.385511] usb 2-1.2: new SuperSpeed Gen 1 USB device number 6 using xhci_hcd
      [ 896.416614] usb 2-1.2: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
      [ 896.416633] usb 2-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
      [ 896.416649] usb 2-1.2: Product: Best USB Device
      [ 896.416664] usb 2-1.2: Manufacturer: ULT-Best
      [ 896.416679] usb 2-1.2: SerialNumber: 042005151E7D
      [ 896.424014] scsi host1: uas
      [ 896.430310] scsi 1:0:0:0: Direct-Access BW-SSD1 0 PQ: 0 ANSI: 6
      [ 896.431467] sd 1:0:0:0: Attached scsi generic sg1 type 0
      [ 896.432271] sd 1:0:0:0: [sdb] 250069680 512-byte logical blocks: (128 GB/119 GiB)
      [ 896.432447] sd 1:0:0:0: [sdb] Write Protect is off
      [ 896.432466] sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00
      [ 896.432796] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
      [ 896.433477] sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes
      [ 896.477650] sdb: sdb1 sdb2
      [ 896.480681] sd 1:0:0:0: [sdb] Attached SCSI disk
      [ 897.225189] Under-voltage detected! (0x00050005)
      [ 901.385186] Voltage normalised (0x00000000)


  10. hello Pete
    Your ssd has UAS also fast. VID is 174c PID is 55aa

    The file for USB_MSD_PWR_OFF_TIME=0 setting
    You need to extract it from the pieeprom.bin file
    Its in lib/firmware/raspberrypi/bootloader/beta (by me)

    here is standard config I extracted when playing around


    here is my present config to stop ssd boot by my crucial ssd
    on my 2nd rpi4. USB_MSD_EXCLUDE_VID_PID which you have from dmesg
    I have entered the VIDPID you have from dmesg not mine.

    USB_MSD_EXCLUDE_VID_PID = 174c55aa

    Then reinsert this back into your new pieeprom.bin

    Instructions how to do this from


    To change these bootloader configuration items, you need to extract the configuration segment, make changes, re-insert it, then reprogram the EEPROM with the new bootloader. The Raspberry Pi will need to be rebooted for changes to take effect.

    # Copy the EEPROM image of interest from /lib/firmware/raspberrypi/bootloader/ to pieeprom.bin

    rpi-eeprom-config pieeprom.bin > bootconf.txt

    # Edit the configuration using a text editor e.g. nano bootconf.txt

    # Example change. If you have a UART cable then setting BOOT_UART=1 will help debug boot issues

    # Save the new configuration and exit editor

    # Apply the configuration change to the EEPROM image file
    rpi-eeprom-config –out pieeprom-new.bin –config bootconf.txt pieeprom.bin

    To update the bootloader EEPROM with the edited bootloader:

    # Flash the bootloader EEPROM
    # Run ‘rpi-eeprom-update -h’ for more information
    sudo rpi-eeprom-update -d -f ./pieeprom-new.bin
    sudo reboot

    Subsequent Bootloader Updates

    If you update your bootloader via apt, then any configuration changes made using the process described here will be migrated to the updated bootloader.

    Pete be carefull you can lock your ssd out. The changes are not on the OS but in the bootloader.

    So a lot of the possible configuration entries are not used
    but you can change or add a possible entry. By an Stable update your item will not be overwriten.

    To reverse your change
    Caution just erasing item from your config.tx file is not enough
    you must set item to USB_MSD_EXCLUDE_VID_PID = “”
    Then follow the instructions above

    or for 2 ssd’s example :-
    The format is a comma-separated list of hexadecimal values with the VID as most significant nibble. Spaces are not allowed. E.g. USB_MSD_EXCLUDE_VID_PID = 034700a0,a4231234

    hope this helps

    regards Brian

  11. Hello Pete
    just noticed my double – comes out as one – in your blog
    Iv double double the – here
    # Apply the configuration change to the EEPROM image file
    rpi-eeprom-config – – out pieeprom-new.bin – – config bootconf.txt pieeprom.bin

    This is – – out – – config

    double – –

  12. Hello Pete

    1) USB_MSD_EXCLUDE_VID_PID works Iv excluded one of my ssd from
    booting the boot message says skipping my ssd.

    2) You can no longer boot to this ssd on my 1st raspi4.

    3) all other usb devices and sd card you can still boot from.
    with 2 ssd’s and usb stick still says skipping my ssd and selects another usb device.

    4) However I would not at the moment suggest you do this to one of your ssd drives as I encountered some problems in reversing the change. I have managed to do it but needs repeating to prove.
    (You could do it to usb hub as that has no progam that you need to clone.

    5) Iv also noted and made notes about the voltage and currents
    and reaction of the drives and rpi4

    7) Quick physical check by boot if the red light does not stay
    on permanently you have a low voltage condition. Anything below
    core volt=0.8500V by me will give this condition.

    My core volt=0.8688V this by a input voltage of 5.4v absolute stable running from 19Amp 12v Ex pc power supply into buck variable 12v to 5v 20 amp voltage reducer.

    My 2 ssd are
    1)Kingstone 300 120Gb by boot upto 1,6 amp normal 0.8amp
    2)Crucial EX500 120Gb by boot upto 1,2 amp normal 0.8amp

    More when Iv finished tests
    ps I will also test the USB_MSD_PWR_OFF_TIME=0 so usb ports are not switched off before boot


    1. I’ve also some really good progress with this.
      My setup is 2 identical 64G mSata drives directly connected to a P4
      Firmware as below:

      root@testpi:/home/pi# vcgencmd version
      Jul 17 2020 10:59:17
      Copyright (c) 2012 Broadcom
      version 21a15cb094f41c7506ad65d2cb9b29c550693057 (clean) (release) (start)

      Connected USB devices
      root@testpi:/home/pi# lsusb
      Bus 002 Device 002: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s brid ge
      Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
      Bus 001 Device 005: ID 17ef:6099 Lenovo
      Bus 001 Device 004: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s brid ge
      Bus 001 Device 003: ID 04b3:310c IBM Corp. Wheel Mouse
      Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
      Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


      root@testpi:/home/pi# vcgencmd bootloader_config

      So firstly the boot order works well, and will boot from the SSD if present, I rebooted around 50 times with the same result, being the usb SSD always booted regardless if a SD card was present or not.

      Secondly I’ve excluded the usb2 hub on the PI from booting
      Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub booting. This is the hardware hub on the PI, so it’s not just a random hub with a random VID/PID.
      This should be the same for all current PI4’s

      The results are as follows.
      With SD card in PI
      SSD inserted into USB3 – Boot from USB3
      SSD inserted into USB3 and second SSD inserted into USB2 – Boot from USB3
      SSD inserted into USB2 and second SSD disconnected – Boot from SD
      No SSD’a attatched – Boot from SD

      With no SD card inserted
      SSD inserted into USB3 – Boot from USB3
      SSD inserted into USB3 and second SSD inserted into USB2 – Boot from USB3
      SSD inserted into USB2 and second SSD disconnected – Boot failure (as expected)
      No SSD’a attatched – Boot failure (as expected)

      So my plan is that I will now have the backup SSD connected to a USB2 port, with the boot SSD on USB3. Should the boot SSD fail, then the boot will revert to SD.
      Should I wish to use the backup SSD, I can either move it to USB3, or if I can’t access the PI, I can change the bootconfig to allow USB2 boot.

      Lastly I don’t care if the backup SSD is on USB2 because backup speed is not a concern for me.

  13. Just a couple more notes
    The firmware I’m using is the stable version.

    I had permission problems with the stable firmware directorty while extracting the bootconfig to a file so instead of sudo, I did a sudo su, which overcame the problem

  14. Hello Pete and Patrick

    my rpi4’2 are set up with 2 ssd 120Gb each 1 used as backup

    on powered usb 4 port hubs

    also excluded my backup ssd from booting,and switch off of usb before boot set to 0.

    As we now have a large and safer drives for storage
    Set context default to localdrives to save memory.
    Any Context that needs to be
    fast I set to memory change in ./node-red settings.js

    contextStorage: {
    default: { module: “localfilesystem” },
    autoblind: { module: “memory” }
    This means that effectively all current conditions of your running pi are Global and by reboot your pi is set up no need to initialize specific items. These are transferred to your backup or any clone you care to make and are in Home/pi/.node-red/context/global/global.json

    regards Brian

  15. Whilst one may have a multiport USB hub, that in theory can provide a couple of amps on each output, it is questionable whether or not they could provide sufficient current instantaneously at start up. The likelihood is that there is a short duration voltage drop or slump as the devices power.
    The other potential issue is the quality and current carrying capacity of the USB cables / connectors. I had an issue with ESP8266 / ESP32 with cheap unbranded USB cables, so I bought some really good ones from Amazon and the issues disappeared.
    The Rpi 4 sems sensitive to voltage so a proper test would be to power the Pi and SSD from a decent bench power supply and see if the system boots up as it should AND consistently.

Leave a Reply

Your email address will not be published. Required fields are marked *

Leave the field below empty!

This site uses Akismet to reduce spam. Learn how your comment data is processed.