https://raspberrypi.stackexchange.com/questions/107843/performance-differences-running-raspbian-from-usb-flash-drive-versus-sd-card#107844
https://forums.raspberrypi.com/viewtopic.php?t=330211
Because it is.
in my experience, USB Flash Drives perform worse as they basically use the bottom of the barrel QLC NAND these days with cheap slow controllers
with MicroSD at least you have standards like Class 10, UHS 1, V10, A1 giving you some level of performance guarantee
meanwhile with usb flash drives? Speed: Yes, USB3.2 Gen 1
which means absolutely nothing
i partition my sd card with the primary partition and then a large empty partition, if the primary partition needs more space i shrink the large partition and do a extenstion of the live primary partition, then i check for the end block of the partition and use dd @ 512 to make a disk image that stops at the end of the partition.
Backups take me about 5 minutes.
though ive never had an sd card go bad, because aside from setup I make sure that very little ever gets written to the sd card.
Also important to periodically check that you backups work.
As another commentor mentioned, having a backup card taped to the sbc is great in case of failure, aslong as someone is there you can contact them and easily instruct them on how to replace the card, no hassle.
Sounds like a really bad idea to put your backup on the same drive / card as the data you are backing up. For most cases, a backup is for when the drive / card dies. Then your backup will be long gone too.
reread, i didn't say that, I dd to an external drive ( i did not specify that, but obviously you cant dd to what you are backing up)... The empty partition is to make backing up vastly faster, it stays empty.
Just use applePi-imager on your mac. It autoshrinks your pis partitions to the smallest size and then clones your sd card. To restore all you do is dd flash the iso back to the card and it boots to full sized partitions again. And is identical to the original os.
How is it slower? It backs up your system byte for byte as fast as your mac can read an SD card. Thats pretty much as fast as it gets. If you want another good solution that doesn't require a mac, I have written a tutorial on my favorite way of automatically backing up clones of Raspberry Pi with some backup scripts and crontab. It was written for Ubuntu on Raspberry Pi, but should also work with Raspberry Pi OS. You can find the tutorial here: [https://danran.rocks/2022/09/how-to-make-a-live-backup-of-your-raspberry-pi-ubuntu-raspberry-pi-os-server-to-create-live-bootable-iso-images-on-an-external-drive/](https://danran.rocks/2022/09/how-to-make-a-live-backup-of-your-raspberry-pi-ubuntu-raspberry-pi-os-server-to-create-live-bootable-iso-images-on-an-external-drive/)
Other than that, you could look into [https://duplicati.com/](https://duplicati.com/) . A good tutorial on how to install it is here: [https://www.linuxbabe.com/backup/duplicati-debian-ubuntu-linux-mint-desktop-server](https://www.linuxbabe.com/backup/duplicati-debian-ubuntu-linux-mint-desktop-server)
shutting down the system, moving the card physically to the computer, rebooting the system.
Interesting solution, so that only clones the data, not the full disk, and it's bootable?
Either way, i like my solution, it's very fast, simple, just a single line command, doesn't require installing anything, works from a live image, and can be automated in cron.
This is all i do, and it takes about 5min.
sudo dd bs=512 if=/dev/mmcblk0 of=/media/sdb1/sync/backup3may24.img count=10723327 status=progress
For constructive feedback and better engagement, detail your efforts with research, [source code, errors,](https://www.reddit.com/r/arduino/wiki/guides/how_to_post_formatted_code) and schematics. Stuck? Dive into our [FAQ](https://www.reddit.com/r/raspberry_pi/about/sticky)† or branch out to /r/LinuxQuestions, /r/LearnPython, or other related subs listed in the FAQ.
† If any links don't work it's because you're using a broken reddit client. Please [contact the developer of your reddit client](https://www.reddit.com/contact/).
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/raspberry_pi) if you have any questions or concerns.*
I use [raspiBackup](https://www.linux-tips-and-tricks.de/en/installation). It creates incremental (compressed, fast) backups of your Pi to remote server or a local usb drive. You can schedule it to run each night. I’ve backed up and restored many Pis using it! Restore is very easy. The tool is free and the developer is very friendly.
I collected all the required commands for updating packages, installing packages, file copying, file content appending, etc. to some scripts, e.g. one for pihole/unbound, one for automounting a usb drive, installing openvpn including credential file, etc.
Just collect all the commands you are required to call when installing a new package for the first time so you have them handy when need to install everything a second time.
For pihole/unbound for example it looks like this.
echo --- Update packages
apt-get udpate
apt-get upgrade
echo --- Install Pi-Hole
curl -sSL https://install.pi-hole.net | bash
echo --- Do some black white listing
pihole --regex '(^|\.)(cn|ru)$' '(\.|^)facebook\.com$'
pihole -w mask.icloud.com mask-h2.icloud.com www.googleadservices.com
echo "BLOCK_ICLOUD_PR=false" >> /etc/pihole/pihole-FTL.conf
sudo service pihole-FTL restart
echo --- Install Unboud
sudo apt install unbound
echo --- Copy pi hole config to unbound folder
cp -v pi-hole.conf /etc/unbound/unbound.conf.d
echo --- Restart Unbound
sudo service unbound restart
echo --- Test Unbound
dig pi-hole.net @127.0.0.1 -p 5335
exit 0
Why the explicit exit 0 at the end? If you get there with no errors it's redundant since 0 is the default exit code anyway. If there's a fatal error that causes the script to stop it's redundant as well. And if there's a non-fatal error it's kinda a lie, right?
Not criticizing, just curious
Same here.
The only drawback of this method is that the device will be down for some time.
(I never would've imagined that I'd need to plan "maintenance intervals" for my home network, but here we are.)
To get better results from the compression (if you don’t mind a bit more wear on your SD card), you can zero-out the unused portions of the card by filling a file with zeros and then deleting it.
cat /dev/zero > /tmp/zeros ; rm /tmp/zeros
Do this before bringing down the pi and pulling the SD card.
This mechanism at work here is that when you delete files, the file system doesn’t zero them out, it just marks those blocks as free. So if you’ve created and deleted a bunch of files on your pi, over time the unused space on your file system is actually made up of a bunch of chunks of previously deleted files, meaning there’s a bunch of non-zero data there, which still has to be compressed when you dump an image.
But if you zero out all of that empty space before dumping the image, you’re only compressing the actual files.
I was just using dd but I found restoring the images didn’t always seem to work. Now I’m using that “SD card copier” app which comes with the OS. It works very well and can backup the OS to larger or smaller disks which is nice.
I was trying to get backups working on an automatic basis, so I was running dd via cron at 2AM while the system was idle but running. I essentially found that when I restored those images, it was hit and miss whether the partitions were even readable and only one out three of the backup's I'd taken seemed to be bootable.
Because different brands of SDs have different actual sizes. Two 64GB SDs can have a few KB or MB difference in size. So, if you write to a SD which is a tiny bit smaller, it will not work.
A solution is to resize the last partition of the source SD, and reduce it by a few MB before cloning it.
Second that. I set recurring schedule reminder in Outlook, when time comes - copy SD by using Pi own "SD copier" tool, when it's done - swap SD cards and using copy and so on every time I make copy. This way, I know for sure that both SDs are good.
I can understand minor corruption due to sync issues between memory and disk, but I was surprised by the extent of it.
I’m also curious how SD card copier manages it more successfully because that seems to be designed to copy the running OS.
I build the system on the sd card, then copy that sd card block for block to a usb hdd and keep the original sd as the backup. The system boots from USB HDD (not even an ssd) and has been running my homeserver without any failures for 3-4 years. Or for as long as the usb boot was a thing, i upgraded the bios on the first month it was available and it has been running on that old hard drive ever since.
My first thought of this was "why" but then I realized that the only pi I have that's mission critical is a webserver I use, and since I want it to always be updated with the current files I not only created a second SD card I put it in a second pi and run it in parallel, so I can hot swap the webserver simply by changing a setting in my router to redirect external traffic to the second pi.
Google ansible.
Roles like this one will let you provision a new pihole in seconds, along with your desired configuration. https://github.com/shaderecker/ansible-pihole
Treat servers like cattle, not pets 👍
Fair point. I like the quote and the idea.
All of my servers are pets. Even the terraformed ones.
But you're right; in that I'd probably have more buddist zen with fewer attachments.
The gnome-disk-manager (Disks it is called in the GUI) and create disk image to back up the whole card. Ideally build on a 4GB or 8GB card then write to the final SD and expand if required. Quick and dirty but works for me. Save, boot, change and verify, save, boot,...
sudo apt install gnome-di{tab}
I believe there is a tool that can remove the free space and backup just the used part of the card but I've got better things to do and can spare a few GB of storage.
... I am glad I am not alone, I have 10 running right now as well lol ... only half of them are actually doing something of importance the other ones are plugged in and idling waiting for when I have time to do something with them.
\*I had a few running, then recently picked up 6 more from a neighbor on Nextdoor who bought them for projects he never had time for either lol
I have two SDs and use one as a physical back up of the other, updated every couple of months since I don't change much.
For the actual data on the drives I use online backup services, since some is mission critical.
I’ve never had an SD card “fail” as my Pis run with stable power supplies backed by UPS power but I backup my data to the NAS using Restic as a “just in case” backup even though most non-volatile data is stored on the NAS. Then all my services are defined with Ansible. If a Pi ever did fail I’d just start fresh and reprovision a new Pi using Ansible and be good to go, but if anything was misconfigured and I realized something important was missing I’d have the Restic backup to look through.
My pi has been running a TV station 24 hours a day for the last 6 years writing and reading from the SD card while also writing and reading from 2 USB hard drives.
In that time 2 traditional disk drives burnt themselves out (replaced by 2 USB SSD) but the SD card is still ticking.
It's more of a concern for non high-endurance SD cards. I've seen some of those fail in less than three weeks.
My high endurance cards have been rock solid though. I've abused the crap out of some of them and they're still running.
I generally stick to NFS for linux devices in the Lab because its easier permission on the server end. Either one does the job. I'd probably only bother with FTP or SFTP if there was a reason too eg unreliable link to a remote node.
I don't do anything fancy with partitions on my pi, and treat it just like I do my PC - I use rsync (in this case via rsnapshot) to copy the files to an external hard drive.
For me at least, the data *in* the sdcard is the important part, I can format a new one if I need to.
I've been using [USB Image Tool](https://usb-image-tool.en.lo4d.com/windows) for years, making an image of the entire SD card(s) as a sort of system restore point.
I use dd once I've got it all setup to create a snapshot I can revert to, and then have rdiff-backup saving filesystem changes to a separate RAID system for anything that changed since the image was created.
I also use Win32DiskImager to create an image of the SD card and I also am paranoid about backups.
I have a bash script that I found somewhere that will shrink the image file down. I keep the full sized and shrunk images on a drive that is normally kept offline. And for extra measure, a couple of times a year I will copy the backups to another drive at my daughter's house, a 7 hour flight away.
I use the Linux "Disks" utility to create an image from the SD card, and "pishrink" to compress the image. It removes all blank space from the image. I then copy the image to my NAS, and to drive I keep off-site.
[https://github.com/Drewsif/PiShrink](https://github.com/Drewsif/PiShrink)
I have a monthly cron job to incrementally backup the whole SD card as an image file (while the RPi is running) with these utilities: https://forums.raspberrypi.com/viewtopic.php?t=332000
The target image file is in a folder on my NAS, which is mounted as nfs share on my RPi.
Just a few months ago my SD card died. I just wrote the image file to a new SD card with etcher.io (needed to solve a little mismatch of the part-uuid) and had my system back up and running. Simple as that.
Honestly, I just backup the configs I need from it, and place a rebuild of the OS with a restore of the parts I needed.
You can typically use the same thing you used to MAKE the SD card, to make a .IMG of the whole SD if you would like to have to backup that much data. I just find the previous simpler.
I have a local nas that I mount a share from using NFS. From there I do a regular backup of data using `rsync`.
It's easy enough to set up.
I also highly recommend using `etckeeper` which treats your `/etc/` directory as a git repo and tracks changes to it over time.
SD Card should only contain OS and backup should be for the config files. All other data ( home/username or whatever construct you subscribe to should be on a separate media). This was the standard for all the open systems I managed back in the days of pre-Y2K and the subsequent dot com era (Sun Solaris, IBM AIX, HP UX and eventually Linux).
I’ve been out of the Sys Admin game for over 25yrs now but that method is still how I configure my Linux systems (regardless HW platform being SBC, desktop system and home lab blade servers.
Quick question:
I use clonezilla for my PC and laptop backups. Would CZ also work for my Pi Backups?
I only use my Pi for PiHole, but it took a while to set it up the way I like.
I don't bother. If I want to run things that require lots of setup and data, then I use a SATA SSD and just use the SD card for booting.
For the systems that run SD card only, I just have a collection of configuration files that can be put on to a new card with OS quickly.
I use [raspiBackup](https://www.linux-tips-and-tricks.de/en/installation). It does incremental (fast) backups to a remote server or local usb drive. You can schedule it to run at night. Restore is very simple. I’ve backed up and restored many raspberry pis with this tool, and the developer is very friendly.
Nvme hat with SSD.
SD card is my backup for logs and data.
Everything else gets installed as an image so if something goes wrong, I just reinstall the image
Win32Diskimager and sometimes a script called [pishrink](https://github.com/Drewsif/PiShrink) (linux, works fine under wsl2) to reduce the size of the image. it will set a flag to automatically expand the file system if it boots up in a pi ever again. that gives the ability to use smaller sized cards as replacement.
I store the images on a network share with my private data, recently got into Proxmox and zfs and am now experimenting. But they are included in my private backup which right now are USB HDDs I only connect when I need to backup and one at a time. I also have something off-site, a Pi with another USB HDD at a relative but this will eventually become another mini pve node soon. Transfers are being done manually for now but I will look into automating stuff too
When I ran two piholes on RPis I'd snapshot their cards into disk images, compress these and store them in my cold staging location on my PC. Usually one snapshot per Pi at a time.
I'd use `dd` or `pv` for that, then `gzip` or `xz` to compress. I'd also hold several spare SD cards so I can get the image written, pop in the card, `apt update && apt upgrade -y` and be done with it.
Pro: works and is somewhat reliable.
Con: needs to be done on a separate machine while Pi is offline.
Also since I started using SDs "for applications" and plugged them into a UPS I never had a card fail on me despite 24/7 usage for years. No messing with logging or anything.
I don't use a SD card. They have significantly limited write cycles compared to a USB thumb drive.
Were you thinking there's something different inside the two?
https://raspberrypi.stackexchange.com/questions/107843/performance-differences-running-raspbian-from-usb-flash-drive-versus-sd-card#107844 https://forums.raspberrypi.com/viewtopic.php?t=330211 Because it is.
Ok, so you don't mean "write cycles" like you said. Sure, there may be other things that are different.
Basically, don't use a SD card when you can boot from any other device.
Lol thank you
in my experience, USB Flash Drives perform worse as they basically use the bottom of the barrel QLC NAND these days with cheap slow controllers with MicroSD at least you have standards like Class 10, UHS 1, V10, A1 giving you some level of performance guarantee meanwhile with usb flash drives? Speed: Yes, USB3.2 Gen 1 which means absolutely nothing
i partition my sd card with the primary partition and then a large empty partition, if the primary partition needs more space i shrink the large partition and do a extenstion of the live primary partition, then i check for the end block of the partition and use dd @ 512 to make a disk image that stops at the end of the partition. Backups take me about 5 minutes. though ive never had an sd card go bad, because aside from setup I make sure that very little ever gets written to the sd card. Also important to periodically check that you backups work. As another commentor mentioned, having a backup card taped to the sbc is great in case of failure, aslong as someone is there you can contact them and easily instruct them on how to replace the card, no hassle.
Sounds like a really bad idea to put your backup on the same drive / card as the data you are backing up. For most cases, a backup is for when the drive / card dies. Then your backup will be long gone too.
reread, i didn't say that, I dd to an external drive ( i did not specify that, but obviously you cant dd to what you are backing up)... The empty partition is to make backing up vastly faster, it stays empty.
Thats better : )
Nowadays it's quite hard to find 8GB cards to use as a system disk
oh, i use a 32gb disk, i just only partition about 6gb for use. It's only $4 for a decent a1 32gb lexar card anyhow.
Just use applePi-imager on your mac. It autoshrinks your pis partitions to the smallest size and then clones your sd card. To restore all you do is dd flash the iso back to the card and it boots to full sized partitions again. And is identical to the original os.
That's not better though, it's slower, cannot be automated, and it requires a mac.
How is it slower? It backs up your system byte for byte as fast as your mac can read an SD card. Thats pretty much as fast as it gets. If you want another good solution that doesn't require a mac, I have written a tutorial on my favorite way of automatically backing up clones of Raspberry Pi with some backup scripts and crontab. It was written for Ubuntu on Raspberry Pi, but should also work with Raspberry Pi OS. You can find the tutorial here: [https://danran.rocks/2022/09/how-to-make-a-live-backup-of-your-raspberry-pi-ubuntu-raspberry-pi-os-server-to-create-live-bootable-iso-images-on-an-external-drive/](https://danran.rocks/2022/09/how-to-make-a-live-backup-of-your-raspberry-pi-ubuntu-raspberry-pi-os-server-to-create-live-bootable-iso-images-on-an-external-drive/) Other than that, you could look into [https://duplicati.com/](https://duplicati.com/) . A good tutorial on how to install it is here: [https://www.linuxbabe.com/backup/duplicati-debian-ubuntu-linux-mint-desktop-server](https://www.linuxbabe.com/backup/duplicati-debian-ubuntu-linux-mint-desktop-server)
shutting down the system, moving the card physically to the computer, rebooting the system. Interesting solution, so that only clones the data, not the full disk, and it's bootable? Either way, i like my solution, it's very fast, simple, just a single line command, doesn't require installing anything, works from a live image, and can be automated in cron. This is all i do, and it takes about 5min. sudo dd bs=512 if=/dev/mmcblk0 of=/media/sdb1/sync/backup3may24.img count=10723327 status=progress
https://duckduckgo.com/?q=How+to+backup+linux+computer
Thoughts and prayers 😁
Republicanism doesn't protect children, elementary schools, critical thinking, nor backups.
I know, if my pi sd card dies, it will be dead for good (except for the codes, those are on github)
For constructive feedback and better engagement, detail your efforts with research, [source code, errors,](https://www.reddit.com/r/arduino/wiki/guides/how_to_post_formatted_code) and schematics. Stuck? Dive into our [FAQ](https://www.reddit.com/r/raspberry_pi/about/sticky)† or branch out to /r/LinuxQuestions, /r/LearnPython, or other related subs listed in the FAQ. † If any links don't work it's because you're using a broken reddit client. Please [contact the developer of your reddit client](https://www.reddit.com/contact/). *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/raspberry_pi) if you have any questions or concerns.*
Rufus - works with windows images too
I use [raspiBackup](https://www.linux-tips-and-tricks.de/en/installation). It creates incremental (compressed, fast) backups of your Pi to remote server or a local usb drive. You can schedule it to run each night. I’ve backed up and restored many Pis using it! Restore is very easy. The tool is free and the developer is very friendly.
Back…up?
[удалено]
I dream of this. Not enough setups per time - pain is not yet on threshold.
bash scripts to setup a new sd card with a couple of clicks.
Can you share what you are using? I'm also interested in this kind of setup
pihole, plex, usb drive automounts, openvpn, etc.
yes, i use almost the same. but i was wondering how did you built your bash scripts. I need to build myself some in case of failure
I collected all the required commands for updating packages, installing packages, file copying, file content appending, etc. to some scripts, e.g. one for pihole/unbound, one for automounting a usb drive, installing openvpn including credential file, etc. Just collect all the commands you are required to call when installing a new package for the first time so you have them handy when need to install everything a second time. For pihole/unbound for example it looks like this. echo --- Update packages apt-get udpate apt-get upgrade echo --- Install Pi-Hole curl -sSL https://install.pi-hole.net | bash echo --- Do some black white listing pihole --regex '(^|\.)(cn|ru)$' '(\.|^)facebook\.com$' pihole -w mask.icloud.com mask-h2.icloud.com www.googleadservices.com echo "BLOCK_ICLOUD_PR=false" >> /etc/pihole/pihole-FTL.conf sudo service pihole-FTL restart echo --- Install Unboud sudo apt install unbound echo --- Copy pi hole config to unbound folder cp -v pi-hole.conf /etc/unbound/unbound.conf.d echo --- Restart Unbound sudo service unbound restart echo --- Test Unbound dig pi-hole.net @127.0.0.1 -p 5335 exit 0
thanks, i'll use your file as an example for my own bash script
Why the explicit exit 0 at the end? If you get there with no errors it's redundant since 0 is the default exit code anyway. If there's a fatal error that causes the script to stop it's redundant as well. And if there's a non-fatal error it's kinda a lie, right? Not criticizing, just curious
thought would be good practice if script is called from another script, maybe its redundant, right. not a bash pro myself.
I think you are saying you are doing configuration backup, so the restore of the configuration is a few clicks.
If you're going to this length it might be worth looking into Ansible and go the whole hog.
I put the SD card into another system and dump the entire block device.
That's pretty much what I used to do. I'd compress them to a .7z afterwards just to save space.
Same here. The only drawback of this method is that the device will be down for some time. (I never would've imagined that I'd need to plan "maintenance intervals" for my home network, but here we are.)
Yea, and the slow read speeds on SD cards really don’t help there either.
I got around this by buying two 😄
To get better results from the compression (if you don’t mind a bit more wear on your SD card), you can zero-out the unused portions of the card by filling a file with zeros and then deleting it. cat /dev/zero > /tmp/zeros ; rm /tmp/zeros Do this before bringing down the pi and pulling the SD card. This mechanism at work here is that when you delete files, the file system doesn’t zero them out, it just marks those blocks as free. So if you’ve created and deleted a bunch of files on your pi, over time the unused space on your file system is actually made up of a bunch of chunks of previously deleted files, meaning there’s a bunch of non-zero data there, which still has to be compressed when you dump an image. But if you zero out all of that empty space before dumping the image, you’re only compressing the actual files.
Yea that's a really good suggestion. Probably worth the extra writes if it's a high endurance card and the backups aren't made every single day.
But isn't /tmp not mounted on the SD card? Mine is a ramdisk. Better just write a file to /
Ah, I’m showing my age there 😅
I was just using dd but I found restoring the images didn’t always seem to work. Now I’m using that “SD card copier” app which comes with the OS. It works very well and can backup the OS to larger or smaller disks which is nice.
What exactly isn't working? Did you use dd on a running pi, or taking the sd card out to make the copy on another system?
I was trying to get backups working on an automatic basis, so I was running dd via cron at 2AM while the system was idle but running. I essentially found that when I restored those images, it was hit and miss whether the partitions were even readable and only one out three of the backup's I'd taken seemed to be bootable.
Because different brands of SDs have different actual sizes. Two 64GB SDs can have a few KB or MB difference in size. So, if you write to a SD which is a tiny bit smaller, it will not work. A solution is to resize the last partition of the source SD, and reduce it by a few MB before cloning it.
Now I’m curious if you could remount the root file system read-only and actually get away with dumping a live system
Second that. I set recurring schedule reminder in Outlook, when time comes - copy SD by using Pi own "SD copier" tool, when it's done - swap SD cards and using copy and so on every time I make copy. This way, I know for sure that both SDs are good.
You're supposed to use dd for backup on an offline partition, aka you're not booted from it. Otherwise, you risk corruption
I can understand minor corruption due to sync issues between memory and disk, but I was surprised by the extent of it. I’m also curious how SD card copier manages it more successfully because that seems to be designed to copy the running OS.
It maybe does a file based backup instead of a block based one. That might be more resilient to this
Came here to bump dd ftw.
I build the system on the sd card, then copy that sd card block for block to a usb hdd and keep the original sd as the backup. The system boots from USB HDD (not even an ssd) and has been running my homeserver without any failures for 3-4 years. Or for as long as the usb boot was a thing, i upgraded the bios on the first month it was available and it has been running on that old hard drive ever since.
I image the whole sd card to my pc and to a second sd card and tape the spare to the pi so it can be swapped out instantly in event of a failure
My first thought of this was "why" but then I realized that the only pi I have that's mission critical is a webserver I use, and since I want it to always be updated with the current files I not only created a second SD card I put it in a second pi and run it in parallel, so I can hot swap the webserver simply by changing a setting in my router to redirect external traffic to the second pi.
Google ansible. Roles like this one will let you provision a new pihole in seconds, along with your desired configuration. https://github.com/shaderecker/ansible-pihole Treat servers like cattle, not pets 👍
Fair point. I like the quote and the idea. All of my servers are pets. Even the terraformed ones. But you're right; in that I'd probably have more buddist zen with fewer attachments.
Use winimage, its easy
The gnome-disk-manager (Disks it is called in the GUI) and create disk image to back up the whole card. Ideally build on a 4GB or 8GB card then write to the final SD and expand if required. Quick and dirty but works for me. Save, boot, change and verify, save, boot,... sudo apt install gnome-di{tab} I believe there is a tool that can remove the free space and backup just the used part of the card but I've got better things to do and can spare a few GB of storage.
Have you tried the SD card backup tool (piclone) that is built into the desktop version of Raspberry Pi OS?
I clone the entire sd into a ssd.
https://github.com/The-Exterminator/PiShrink-to-Crontab work everytime, all my 10pi’s do it with this.
Oh thanks, this looks like what I need
[удалено]
... I am glad I am not alone, I have 10 running right now as well lol ... only half of them are actually doing something of importance the other ones are plugged in and idling waiting for when I have time to do something with them. \*I had a few running, then recently picked up 6 more from a neighbor on Nextdoor who bought them for projects he never had time for either lol
Thanks! As another person who also has 10 Pi's running various things, this might come in handy!
I have two SDs and use one as a physical back up of the other, updated every couple of months since I don't change much. For the actual data on the drives I use online backup services, since some is mission critical.
I’ve never had an SD card “fail” as my Pis run with stable power supplies backed by UPS power but I backup my data to the NAS using Restic as a “just in case” backup even though most non-volatile data is stored on the NAS. Then all my services are defined with Ansible. If a Pi ever did fail I’d just start fresh and reprovision a new Pi using Ansible and be good to go, but if anything was misconfigured and I realized something important was missing I’d have the Restic backup to look through.
My pi has been running a TV station 24 hours a day for the last 6 years writing and reading from the SD card while also writing and reading from 2 USB hard drives. In that time 2 traditional disk drives burnt themselves out (replaced by 2 USB SSD) but the SD card is still ticking.
Just out of curiosity, what SD cards do you use?
Honestly they're just whatever amazon had 5 years ago. I just checked and it's a SanDisk
It's more of a concern for non high-endurance SD cards. I've seen some of those fail in less than three weeks. My high endurance cards have been rock solid though. I've abused the crap out of some of them and they're still running.
Restic And I mostly just script the install process
I use this https://github.com/seamusdemora/RonR-RPi-image-utils
I've been using this as well for a number of years. Lets me keep an updated archive of images for my multiple Pi's on my network attached PC.
This is the way.
I don't bother. Just rsync to nas nfs share or use diet pi if you want terminal menu
Dietpi-backup->samba share or ftp to nas
I generally stick to NFS for linux devices in the Lab because its easier permission on the server end. Either one does the job. I'd probably only bother with FTP or SFTP if there was a reason too eg unreliable link to a remote node.
I don't do anything fancy with partitions on my pi, and treat it just like I do my PC - I use rsync (in this case via rsnapshot) to copy the files to an external hard drive. For me at least, the data *in* the sdcard is the important part, I can format a new one if I need to.
The network
win32diskimager is what you are looking for OP. makes a bit accurate copy of and SD card that is saved as an image for burning to the sd card later
dd works fine
rsync cron job to my backup server.
Win32 disk imager. Makes a perfect iso to be written to another sd card of the same or larger size.
Just use the Sd-card copier function in the OS, works solid, never had any issue with it, others just gave me troubles and errors.
I've been using [USB Image Tool](https://usb-image-tool.en.lo4d.com/windows) for years, making an image of the entire SD card(s) as a sort of system restore point.
I use dd once I've got it all setup to create a snapshot I can revert to, and then have rdiff-backup saving filesystem changes to a separate RAID system for anything that changed since the image was created.
I use imagewriter on windows.
I also use Win32DiskImager to create an image of the SD card and I also am paranoid about backups. I have a bash script that I found somewhere that will shrink the image file down. I keep the full sized and shrunk images on a drive that is normally kept offline. And for extra measure, a couple of times a year I will copy the backups to another drive at my daughter's house, a 7 hour flight away.
I make an image of my micro SD card with Win32 Disk Imager and keep it on a PC.
I use the Linux "Disks" utility to create an image from the SD card, and "pishrink" to compress the image. It removes all blank space from the image. I then copy the image to my NAS, and to drive I keep off-site. [https://github.com/Drewsif/PiShrink](https://github.com/Drewsif/PiShrink)
I have a monthly cron job to incrementally backup the whole SD card as an image file (while the RPi is running) with these utilities: https://forums.raspberrypi.com/viewtopic.php?t=332000 The target image file is in a folder on my NAS, which is mounted as nfs share on my RPi. Just a few months ago my SD card died. I just wrote the image file to a new SD card with etcher.io (needed to solve a little mismatch of the part-uuid) and had my system back up and running. Simple as that.
Nothing. Installs are dd'ing a disk image, a few tweaks, and ansible.
I personally just use win32diskimager
I use rsync to back up all of the files I care about (which, in the case of RasPi OS is just the configuration changes I had to make).
I run local backups then copy that backup file to my computer, and remote offsite locations. Check out the Samba Backup add-on.
create an image of the full drive, but then shrink the image down to the size that is actually used: https://github.com/Drewsif/PiShrink
Honestly, I just backup the configs I need from it, and place a rebuild of the OS with a restore of the parts I needed. You can typically use the same thing you used to MAKE the SD card, to make a .IMG of the whole SD if you would like to have to backup that much data. I just find the previous simpler.
I have a local nas that I mount a share from using NFS. From there I do a regular backup of data using `rsync`. It's easy enough to set up. I also highly recommend using `etckeeper` which treats your `/etc/` directory as a git repo and tracks changes to it over time.
After 4 failures I've just started using an SSD connected via USB
SSD for persistent data / ansible for setup
SD Card should only contain OS and backup should be for the config files. All other data ( home/username or whatever construct you subscribe to should be on a separate media). This was the standard for all the open systems I managed back in the days of pre-Y2K and the subsequent dot com era (Sun Solaris, IBM AIX, HP UX and eventually Linux). I’ve been out of the Sys Admin game for over 25yrs now but that method is still how I configure my Linux systems (regardless HW platform being SBC, desktop system and home lab blade servers.
Would using Win32DiskImager to read an image from the card work?
Quick question: I use clonezilla for my PC and laptop backups. Would CZ also work for my Pi Backups? I only use my Pi for PiHole, but it took a while to set it up the way I like.
I don't bother. If I want to run things that require lots of setup and data, then I use a SATA SSD and just use the SD card for booting. For the systems that run SD card only, I just have a collection of configuration files that can be put on to a new card with OS quickly.
I copy the SD to a USB to reduce failure chance.
I use [raspiBackup](https://www.linux-tips-and-tricks.de/en/installation). It does incremental (fast) backups to a remote server or local usb drive. You can schedule it to run at night. Restore is very simple. I’ve backed up and restored many raspberry pis with this tool, and the developer is very friendly.
Nvme hat with SSD. SD card is my backup for logs and data. Everything else gets installed as an image so if something goes wrong, I just reinstall the image
Win32DiskImager for full sdcard back to .img file
Win32Diskimager and sometimes a script called [pishrink](https://github.com/Drewsif/PiShrink) (linux, works fine under wsl2) to reduce the size of the image. it will set a flag to automatically expand the file system if it boots up in a pi ever again. that gives the ability to use smaller sized cards as replacement.
I store the images on a network share with my private data, recently got into Proxmox and zfs and am now experimenting. But they are included in my private backup which right now are USB HDDs I only connect when I need to backup and one at a time. I also have something off-site, a Pi with another USB HDD at a relative but this will eventually become another mini pve node soon. Transfers are being done manually for now but I will look into automating stuff too
From time to time I make backups with the help of DD. Not necessarily the best and most economical method, but I have enough space on my NAS
When I ran two piholes on RPis I'd snapshot their cards into disk images, compress these and store them in my cold staging location on my PC. Usually one snapshot per Pi at a time. I'd use `dd` or `pv` for that, then `gzip` or `xz` to compress. I'd also hold several spare SD cards so I can get the image written, pop in the card, `apt update && apt upgrade -y` and be done with it. Pro: works and is somewhat reliable. Con: needs to be done on a separate machine while Pi is offline. Also since I started using SDs "for applications" and plugged them into a UPS I never had a card fail on me despite 24/7 usage for years. No messing with logging or anything.
Pi’s built in sd card copier or if you want to use cli / cron option then https://rpi-clone.jeffgeerling.com/