Looks like a good use case for git on LAN? You can tag or branch your config sets rolled out for other machines than yours. Later merge all your latest and greatest changes from your machine into the friends' branches from time to time. If something breaks you can easily go back in time.

@erbright said in Unable To Backup RetroPie Image:

Win32DiskImager - Doesn’t work. I create the image and try to mount it to make sure it works and Windows tells me it's corrupted. This happens over and over again.

This is all you needed to do, it did work, you just can't mount it under Windows.

@mitu found a way to acces the SD card with "Linux Reader" actualy copying fies and it takes ages but better than nothing.

You could use something like FSArchiver to backup the individual /boot and / partitions (excluding ROMS). dd could be used for individual partitions, from a separate Linux system (/ shouldn't be active when dd is run). FSArchiver is included in the live boot System Rescue image, you can use it to restore/backup from a separate PC, without installing Linux on your PC.

The main folders you want to back up are:

/home/pi/RetroPie (ROMs, BIOS files, splash screens) /opt/retropie/configs (configs for RetroArch, EmulationStation, also your scraped game library) /etc/emulationstation(custom themes as well as the systems ES has access to)

The RetroPie documentation has info on how to copy files. WinSCP or Filezilla are probably the easiest programs to use.

Copy those over from the 3B to the 4, and you should be fine. Note: after you flash the image onto your RPi4, you'll need to boot up with it for RetroPie to finish installing, then you can turn it off and start copying.

@SuperPitendo said in rpie-preservatives - Save file remote backup & synchronization tool:

@LiquidDivide I am glad that I could help. Thanks for pointing out the differences, especially the point with the non-retropie devices and that nothing has been done on the other script for 2 years. This should make your script much more interesting. Do you plan to include a save state selector as well?

Yes and no. If something works well, there's not really a need to keep changing and updating it. The other script does still work well and I had minimal issues with getting it working again, though I added a few changes from one of the other forks as well. I'm happy with it for now, but if this script gets more features, more robust, I'll happily switch.

@Clyde Wasn't aware of that tool. Cheers.

Thanks for your reply. I´ll give it a whirl :)

@treki said in Are the individual configurations also backed up?:

Where are the RetroPie settings (RetroPie setup) stored?

Most of them are in the /opt/retropie/configs folder, which is shown as \\retropie\configs over file shares.

Also I am downsizing by getting rid of computer emulators
Dos Box,Amiga,and Apple 2

You'll need to use something like pi-shrink to make the image be as large as its contents (vs. the full copy of the card).

https://github.com/Drewsif/PiShrink

@machine_74 this is normal behavior. The only partion that a windows computer can access directly is the boot partition. The other Linux partion, windows doesn't understand what it is and assumes it needs to be formatted. Nothing is wrong with your card, just ignore/close out the format prompts.

@KN4THX Exactly. I wouldn't buy a ssd drive just for a Pi, but when I upgrade the ssd on my main pc, then I could use the older one.

@mitu
The device setup I was thinking would be like this on the raspberry pi
USB1: Usb image boot, raspbian? smaller.
Micro-SDslot: unformatted new microsd (the target of the image write)
USB2: Usb microsd adapter (the source of the image write)

rpi-clone; and I thought I made it sound confusing.

@simpleethat Well, my suggestion is to compress all of your roms into zip or 7z format (as the emulators support) for use on your Pi and to just store them in that format on your NAS. This way they are maximally usable on your Pi should you need to copy them back over.

The amount of extra compression you can get by compressing everything into giant 7z files is fairly small in most cases. There are some roms that can't really be compressed for use by emulators, mostly bin and ISOs. However, most of the emulators also support a compressed format for these types of file (chd, pbp, etc). All the time, effort, and electricity you spend compressing files to eek out a few GB of storage space just isn't worth it.