How to make a duplicate of SD card with only Windows available ?

General Discussion
1

So, finally, after reflashing and reinstalling and reconfiguring a thousand times, I have a perfectly working logitech Media Server with all plugins setup and working, Youtube and Bandcamp APIs (much work!) setup etc.

I want to make an exact backup of this SD card, currently in my Odroid xu4, so if anything happens I can just reinsert the backup copy.

How can I do this ?

Windows when inserted rejects the SD card as error and says reformat needed.

Backup function in DietPi requires backup transferred to another location with ext3/ext4 format.

I currently have nothing else in ext3/ext4 format. I do, however, have an RPi3 I plan on setting up later. Could I then “network drive mount” my RPi3 as a drive on the xu4, use the internal backup solution in DietPi on the xu4 to transfer the backup to the Rpi3 ?

But wouldn’t this be a rather inelegant solution because the RPi3 would already have dietpi on it, so the backup from the xu4 would be there, but so would a whole separate DietPi RPi3 system ?

Is there a better way of doing this ? A program (like Balena etcher) that ignores Windows warnings, handles SBC DIetPi sd cards correctly, and would allow me to make an exact copy of the sd card currently in my xu4 ? So if something goes wrong on current xu4, all I have to do is extract that card and insert the duplicate ?

Any way of achieving this ? Thank you very much for any help!

2

Win32DiskImager can do that. But AFAIK the resulting img file has the same size than the whole SDcard, but can be reduced by archiving with 7zip.

3

Thanks a lot, will give it a try over the weekend and let your hear back!

Will the 7Zip procedure then create an exact duplicate of the original SD card so all I have to do in cause the first card breaks is to insert the other one and I’m up and running immediately ?

4

Doesn’t work unfortunately, inserting the fully working and fully configured original SD card into my Windows computer and then running Win32DiskImager still requires me to choose an image - this doesn’t work because the way the card shows up when it is inserted into a windows machine is with the error message and two drives both from original SD card, as a drive “BOOT D:” and a “Removable disk E:”

So I guess I would somehow have to make a single “image file” of the working SD card, then use Win32DiskImager or something else to write an exact copy of this to another card ? Or any other suggestions ?

Could I somehow connect an unused RPi3 to my network, insert the empty card there with not even DietPi on it, then mount that empty card as a drive from the original card on the xu4, then use DietPi backup function from that card(the xu4) to create an exact copy on the empty card ? Or would the empty card in the RPi3 not be able to be mounted ?

The idea is to create an exact copy of the functional and configured SD card onto an empty card so I have a copy I can just swap if something goes wrong.

Thanks for your help.

5

The Win32DiskImager method should work - select the boot drive and it should actually make an image of everything.

I do this routinely with Raspbian but also LibreElec cards. The latter has 3 partitions on it, only one of which is actually readable to Windows (the boot partition), but if the image is written from it then the whole card gets imaged.

From what you describe I think the DietPi set-up is similar, although I have to admit I haven’t tried it with mine yet.

The only problem you might have is that occasionally some uSD cards of nominally the same size are either slightly larger or slightly smaller. If you try and copy the image of the former onto the latter it will fail as it won’t quite fit.

6

If it works with Raspbian, it does with DietPi as well. You can verify by opening the resulting img file with 7zip. It should show the two partitions as 0 and 1 then with all content.

My suggestion was to use 7zip to compress the img file then, so you don’t need to store a e.g. 64 GiB file from a 64 GiB SDcard, but a e.g. 200 MiB 7z archive instead. When required, unpack it and flash it just like you did with the initial DietPi image.

We have a script that reduced root file system and partition of a drive or image: https://github.com/MichaIng/DietPi/blob/dev/.meta/dietpi-imager
This is actually to produce as small as possible DietPi images but can be used as well to produce small SDcard images or reduce the size of existing ones. With this you can as well stink the backup image file, in case it is too large for a new SDcard. It does the 7zip archiving as well. Only downside: You can currently run it only from another DietPi system. If none there, a VM would be a quick option, which is anyway nice to have to allow emergency SDcard fsck and recovery in case the RPi crashed badly.

7

Win32DiskImager still didn’t work, with the original sd card in PC it shows D:Boot and E: drives, I can click into the D: drive, but there are just two directories, IIRC one with no files, one with other files, Win32DiskImager still requires an .img file

Is there any method in dietpi for creating an .img file that is an exact copy of the sd card with installed programs etc. that one wants a clone of ?

Here’s what I ended up doing:

Inserting a USB stick into the xu4, with the xu4 having DietPi and all installed programs and config perfectly
Formatting the usb stick in the xu4
Using Dietpi built-in backup function to “Back up user data” to the ext3/4 formatted usb stuck in the xu4
Downloading, installing and setting up the DietPi RPi3 OS on the RPi3
Inserting the USB stick with the backup data from the xu4 into the RPi3
Using DietPi built-in backup/restore function to restore data from the xu4 usb stick onto the RPi3

I was curious whether it would work to backup from one Dietpi version (xu4) to another (RPi3). Unfortunately, this method didn’t work. Trying to connect to the RPi3 ip with putty with the sd card with the restored backup from the xu4 just causes the connection to time out. So I guess one DietPi hardware version can’t be restored to another DietPi hardware version ?

SURELY it can’t be impossible to clone an SD card somehow ? Win32DiskImager doesnt work as far as I can work out, it requires selecting a .img file to be cloned, and a setup, configured and with programs installed DietPi SD card doesn’t have an .img file.

8

OK, I did it, it’s just the Win32DiskImager interface is a bit weird. Long story short, follow this guide:

https://www.howtogeek.com/341944/how-to-clone-your-raspberry-pi-sd-card-for-foolproof-backup/

My bad for not RTFM first … :slight_smile:

Using this method you can use either Win32DiskImager or BalenaEtcher to restore the backed-up clone to another SD card. I used Balena Etcher and it works booting up from the xu4. In drive manager the reported usage of the cloned 32GB card is 2.1G and 32M, this is the same as the original card.

Weird thing is, when Balena Etcher flashed it, it took much much longer than usual flashing a DietPi image and reported flashing the whole 32GB.

So then, maybe, the problem is, however, as you said, the cloned image created using Win32DiskImager at least when flashing takes up the full 32GB of the SD-card. This is obviously no good in case for example the LMS database on the card needs to expand in size. But after booting with the cloned card it reports identical disk usage values to the original card so I guess everything is fine ? But what is the mechanism there ?

I need an IDENTICAL clone of the original SD card so I can just swap them and be up and running again in seconds in case anything goes wrong.

How/why do I use 7-Zip to reduce the size of the img ? Can I use 7-Zip to compress the img so then, finally, I would have an exact clone of the original SD-card ? In 7-Zip for Windows all I can see that it let’s me do is create a .zip out of the image, inserting this into the xu4 would do nothing, because it won’t boot from a .zip file, correct ? So I would have to extract the zip first, it would then extract the cloned .img to it’s full 32GB size again, and I would be right back where I started again ?

Or do you mean use 7-Zip on the xu4 to compress the now 32gb sd card system somehow ?

I used “check and repair” in DIetPi on both partitions on cloned card and there were no errors as far as I could see. And LMS works as on the original card.

But basically, BalenaEtcher took much longer when flashing the Win32DiskImager created cloned backup .img file, reported it as 32GB (full size of card), but drive manager in dietpi reports disk usage values reported above, ie. same as original card, and plenty of free space. So appears to have worked, but still weird the BalenaEtcher behaviour.

Comments/insights appreciated :slight_smile: Cloning an SD card so you can have a backup and be up and running again in minutes in seconds instead of having to reconfigure and reinstall and whole new DietPi image should be a built in function in DietPi I think, it is so useful especially if you for example have an xu4 in someone else’s house that corrupts, all you need to do is ask them to power it off, insert the other card and you’re up and running again - even a parent could do it :slight_smile: There are Linux commands for this AFAIK.

Thank you very much!

9

That’s a good tutorial on how to do it - as you say the GUI on Win32DiskImager is a bit odd but it’s easy enough once you get the hang of it and have done it a couple of times.

What you’ll end up with is a 32GB file (if you’re taking an image of a 32GB uSD card) as it basically images everything directly one-to-one, including empty space. If you’re storing the image for later use (as a back-up for example) then you can use a compression program like 7zip to make it smaller for storage. However if you want to write it back, you’ll need to decompress it again.

It also takes longer to write as you’re writing a whole card full of data, including the blank bits. When you install DietPi (or anything else) initially it just fills the space it needs and then expands the storage capacity to fit the whole card. So you’re doing a lot more writing when you restore the card back-up.

But what you restore will be an exact clone of the original card. I use this to periodically back up a few of my Pi’s (e.g. my VPN server and my docker server Pi’s) so that if their configuration screws up, then I can just recreate them back to where they were when I backed them up. Of course you then need to do any updates etc that have occurred since the back-up, but if you image them periodically too to maintain a decent backup then its’ not a big issue.

Hope that’s clearer.

10

Hi Guys,

I have a little bit different question than above but it’s related to cloning/duplicate of a SD card as well.

I’m looking for a possibility to clone/duplicate my DietPi SD card while it’s still plugged into my RPi3. I know I could do it using Win32DiskImager. But there I would need to remove my SD card from the Pi, means my Pi would be off for around 1 hour. Which is not best situation because my Pi is hosting DNS & DHCP inside my local network.

Therefore I would like to connect a 2nd SD card via the USB ports and clone/copy/duplicate the whole system. Aim is to have a 1:1 copy, that can be used for testing purposes.

Maybe someone has an idea if this can be done or if this is something not possible.

Many thanks in advance

11

As I wrote above, I tried something like that, but it didn’t work, I suppose it didn’t work in my case because I did it between a RPi3 and an XU4 system, it should work Pi3 to Pi3:

Just insert a USB stick into the original RPi, use the built-in DietPi backup user data feature to the usb stick.

Then, probably, for the second Pi you’d have to create a fresh SD card with DietPi on it. And from that fresh DietPI OS install on the 2nd Pi, insert the USB stick, and “restore user data” from the USB stick. Can’t remember if the USB stick will show up as a drive to back up to automatically, or if you have to user dietpi-drive manager to mount it first. All these functions, backup/restore and drive-manager, are available from typing dietpi-launcher from the command line.

There might be some conflicts if you are running network-wide stuff like DHCP server or whatever and then end up having two Pis running with that same stuff.

I’m guessing here but I’d be surprised if that didn’t give you what you need - to Pi’s with identical data on the two SD cards. Let me know if it works :slight_smile:

12

Sorry, had a read on the DietPi documentation, apparently their definition of “user data” does not include everything you’ve installed and configured.

13

that’s why I was looking for a way to create a 1:1 copy “online”. I would be fine as well to create something like an *.img file.

14

An online “clone” should never be done. While copying, there are nearly 100% changes done to the file system, which means that already copied data in cases not match data that is still to be copied, and worse, the ext4 journal will not match, and other problems. You can do a dietpi-backup, which copies only the files, excluding tmp/kernel dirs, and at least stops all controlled services, but no file system data. But this cannot be flashed back to an SDcard, only copied inside when mounting it.

A real clone can only be done from external system, offline.

And yeah dietpi_userdata is the default download and media dir when installing software via dietpi-software + it contains “most” related config files and such. But e.g. software installed via APT places configs to /etc and data to /var. In some cases, as part of our install steps, we link those over to /mnt/dietpi_userdata, but not in all cases. It is a bid the fight between FHS (UNIX file hierarchy system) where same data types of all software are placed within the same directory structure, and our aim:

  • Move especially heave disk I/O data (databases, media, …) to dietpi_userdata which can moved to an external drive easily, to increase SBC SDcards livetime and performance.
  • Move settings/config files and data to an external place from you can easier backup/restore/migrate.
    The default Linux/UNIX behaviour is great for x86 server systems with regular HDD/SSD system drives, but for SBCs with often very slow SDcards which are not made for 24/7 R/W access it isn’t great. And since those SDcards simply break more regularly, backups and migrations should be as easy as possible, which is not if the important files are layed out on different locations across the root file system.
15

Hi,

thx for your feedback. I guess I will stick to Win32DiskImager even if it’s not ideal. But I will survive :sunglasses: