How to backup Pi 5 nvme drive

I ported the raspberry pi 5 operating system and my applications from the SD card to a NVME drive on the Pimoroni adapter.

The Pi 5, with the active cooling hat and NVME drive are mounted to my CNC controller in a cabinet. It no longer uses the original SD card.

My question is - what is the best way to backup the entire contents of the NVME in case of failure. Dismounting the NVME drive isn’t an ideal option - and when I connect the drive to windows it only shows one partition.

Is there a way to back it up in situ? Perhaps to a USB flash drive?

From a GUI I use the SD card Copier in Accessories.
Choose the ‘Copy from device’ and the ‘Copy to device’ and hit Start.

From the command line you could use dd

1 Like

Thanks, I’ll give those a try. I would not have guessed that the SD Card Copier would also do the NVME

You could also use my tool GitHub - bablokb/pi-boot-switch: Boot-Switcher for Raspberry Pi multiboot systems. This tool copies installations from one partition/device to another one on a file level. It is a commandline tool but very powerful.

The first copy is slow because it needs to copy everything, but the second time it is fast since it only updates the backup.

The only thing you should be aware of, but this is also true for the tools that @lufbrarunner had mentioned: this are system-level backup-tools. For backing up (application/user) data, you should use something that is built for that purpose.

Hmm, I was hoping for something that would work like SD card imager

The SD card copier is something like that imager.

Hi @zed_thirteen

May I suggest considering using blaena etcher link here.

Once installed on your OS of choice, look for the “clone drive” option. Should look a bit like this:

Select the “clone drive” option.

Point it towards your nmve drive that you want to back up. And the target location with enough free space. This destination device will need to be as large or larger than your source nvme drive!

This will create an image of your drive that you would like to backup.

Such an image could then be rewritten to another drive with enough capacity for the image, using the “flash from file option” of the same application.

I hope this helps. 👍


Edit: tyop fairy 😕

1 Like

One question about space: does “space” refer to the device, partition or used space?! This really makes a difference. I tend to install to large partitions to have some headroom and later backup to small ones that are only large enough to hold the files that are actually installed.

Perhaps a poor choice of words on my part.
To back up the entire volume itself. The entire data storage device.
Or a partition if preferred. Etcher is quite versatile and reliable I’ve found. YMMV.

This is still unclear. E.g. I have a drive of 60GB with 12GB used. Does my backup-target need 12GB or 60GB?

Again my apologies for misunderstanding at this end.

If I were looking at imaging a 32gb sd card for example. I would allow 1 or 2% over that size to allow for difference in storage media manufacturers.

For data storage 1024mb equates to 1gb, to allow for overheads of the binary system, nibbles, bits and bytes.

I found this post on qouora where the poster explains it in a way much better than I could.

I hope this may correct my error.

Sorry, but this is still a misunderstanding. Take my example with the 60GB drive, 12GB of them are used. Does the imager copy 12GB to the target drive or does it copy the complete 60GB to the target drive? In the first case it would only copy the used space, in the second case it would copy the full drive, i.e. 48GB in addition of empty unused space. Copying would take 5 times longer than necessary.

I understand now 😀
An image of a volume will be the entire size of it.
A 60gb volume will need a 60gb image. It is exactly the same byte for byte.

I hope this helps 👍


Thanks for the clarification! But this also implies that Balena Etcher is not useful for backups. Some users install PiOS on a 2TB drive. The used space is probably something in the range of 5-10 GB, so backing up the whole 2TB of the drive is a waste of space and time.

Indeed it would imply that. For the purposes of the OP, a drive image would be a possible soloution.

Etcher would’nt meet the flexibility of and rsync or timeshift type soloutions. Which I feel would meet your needs.

1 Like

You can compress the resulting image, though. If you use dd, you can just pipe the output of dd into gzip. Otherwise, zip up the image after creating it however you decide to create it.

I believe the image will copy everything including old data still on the drive in otherwise free space. A wipe of free space specifying the last write value instead of letting it do random data before creating the image would allow compression programs to go to town.


^— what they said. A far more simple and elegant soloution.

I still don’t get it. What is elegant about dd plus zipping terabyte of data instead of just copying a few gigabyte? (and incremental backups copy even less).

And “wiping” is absolutely the wrong thing to do on SSDs, since after “wiping” the controller thinks every byte is used which results in severe write-amplification.

Backup and imaging are two totally different disciplines. Anybody really thinking about backups should get a backup program. One of the most prominent use-cases of backups is for example the restore of an accidentally deleted or changed file. With your dd+zip solution you won’t get far. Especially if you backup often: how would you keep track in which of your many terabyte backup-files you will find the relevant version of the file?

Could we wrap it up with: There are many ways to preserve your data. All with their own benefits and concerns. Methods may vary, opinion can be divided, but the core principles remain the same.

I wasn’t aware of wiping an SSD setting it up for thinking everything was in use. In that case, maybe wiping isn’t a good idea. I only mentioned it because areas with a fixed value for data would compress really well and dd had already been mentioned. Unintended consequences I guess.

Linux is nice about being file based, though. Regular backups work fine.