Cloning Booted RPi's microSD card on Windows PC through Network

Does your statement apply to this one also? :wink:

https://www.amazon.com/SanDisk-Extreme-microSDXC-Memory-Adapter/dp/B07P9W5HJV/

1 Like

:+1: :+1: :+1: :clap:

Sure, why not? I would not put it in a Raspberry which is less expensive than the card itself,but there are other usage examples…

I am using a 512GB card in my digital camera

Latest Version Released Today (December 14, 2020).

v0.6.6

Repository: framps/raspiBackup · Tag: v0.6.6 · Commit: 41b2826 · Released by: framps

Features

  • Backup any number of partitions for USB boot mode systems, not only the first two partitions
  • Dynamic mount of backup partition

Enhancements

  • Multiple additional consistency checks in installer and raspiBackup
  • For rsync backup mode any filesystem on the backup partition which does not support Linux ownerships and fileattributes and will create a crappy backup is refused (in particular NTFS). dd and tar backup mode still accepts NTFS.

Bugfixes

  • Call post plugins when raspiBackup finishes unsuccessfully
  • Reject any pathnames with spaces

For a detailed list of issues in this release see here

This release has 2 assets:

  • Source code (zip)
  • Source code (tar.gz)

Visit the release page to download them.

2 Likes

Thanks, I’ve updated a couple of mine and am now just testing to make sure it’s all OK.

I’ve got ten Pis backing up using this method now!

/edit - Command to update is

sudo raspiBackup.sh -U

I just stumbled upon this thread and have some comments:

I see the point it would be much better to install raspiBackup via some package manager. But I frankly have no clue how to get this done :frowning_face:

If you use the github installer under the cover still the installation Code is grabbed from my website.

The only way to be 100% sure the code is not compromized is to manually download raspiBackup, check the code carefully and execute all installation steps manually. But thats very inconvenient. Just follow the instructions on raspiBackup - Manual installation and configuration for manual install.

1 Like

I’ve finally got round to setting this up on my 5 raspberrys (mix of 3, 3B Plus and 4GB 4B all with 32GB cards). I’ve configured it to mount a share on my NAS as the destination and it seems to work very well. I was surprised that there doesn’t seem to be much much difference in the time taken to perform the backup but the model 3s get pretty warm.

I was reading the post by @framp on Linux tips and tricks about the pros and cons of dd versus rsync. The jury is still out on this IMHO as it seems there are advantages and disadvantages with both strategies. Anyway, I was wondering if anyone had found a way of backing up multiple partitions using rsync.

raspiBackup has two backup modes: Default is the normal backup mode which just saves the two Raspbian partitions. There is another mode called partition oriented available which is able to save any number of partitions. Default is to include the first two partitions but this can be customized with the raspiBackup installer to include any partition - as long as the partitions reside on the same device used by the OS for / and /boot.

yeah dumb question - I must have misread, misunderstood or mistyped the backup options the first time I tried it.

The first time I backed up my 4GB Pi 4 to my NAS with an SD card in it, it took an hour, which seemed reasonable to me.

Since then, I’ve cloned the SD card to a SSHD in a USB3 caddy and removed the SD card.

It now takes an hour and three quarters even though the partitions are the same size, there’s no extra data and all the settings are the same…

Very strange.

Yes, because it copies the sectors, independent from the content.
You could pipe it through zip which compresses it, should be much faster.

What size was that card?

It was a 32GB card and I’m using ddz. raspiBackup says that the backup will be truncated from 465GB to 29.7GB.

I’m running it again to see if it was a one-off in case some external influence affected it.

456GB for a 32 GB SD card

Weird…

I did a backup recently of a different device. Using a 64 GB SD Card, was done in 45 Minutes across the network to my NAS and the Image finally was 7 GB in size

It’s also very dependant on Pi speed as well as the amount of data.

I have a Zero backing up a 16Gb card that takes a couple of hours and a Pi4 that takes twenty minutes!

The second run on the first 4GB Pi 4 took 46 minutes @ 11.5 MB/s.

The first run on the second 4GB Pi 4, took 65 Minutes @ 9.4 MB/s.

That one is also 32GB but it is on a USB2 HDD.

That was because the disk is 500GB but I used DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY=1 so that only the used part of the disk is copied.

Anyone tried doing a multiway shoot out between the different options? dd vs ddz vs tar vs rsysnc?

I suspect they would all hammer a pi but in different ways.

on a related subject:

I have been using Winscp to copy files from my raspberrys to my NAS for a while. One of files is 770MB and it starts out copying at over 5 MBPS but drops to about 150 kbps after a while.

If I use VNC file transfer it stays at over 5 MBPS all the way through.

Cloning booted RPi’s microSD card if RPi is physically accessable.

Plug into RPi, a USB Card Reader/Writer, with backup microSD Card inserted into the card reader.

Case (1):
If Image is Raspberry Pi OS with desktop (GUI), it has a tool in accessories named SD Card Copier which very conveniently copies the booted microSD card

Case (2):
If image is Raspberry Pi OS Lite or Piaware SD Card image with no GUI, use the method below:

wget https://raw.githubusercontent.com/billw2/rpi-clone/master/rpi-clone 
sudo bash rpi-clone sda -v 

Please see this post:
https://www.raspberrypi.org/forums/viewtopic.php?t=180383#p1877328

 

For complete Guide:
https://github.com/billw2/rpi-clone

 

I don’t suppose I’m the first or only person to discover this but while doing test restores of ddz raspiBackups that are being saved on my NAS, I found out that the Raspberry Imager is able to un-compress an image in a gz file on the fly so restoring an image is an absolute doddle.

I’ve recognized that as well on my last setup where i did not uncompress the image first