DietPi

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

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

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.

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.

Hi,

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