Read the statement by Michael Teeuw here.
SD Card Backup
-
I was wondering this same thing myself. I wanted to backup my raspberry pi sd card to another card that I have which is alot faster. Turns out the raspberry pi site has instructions on how to do this
-
In your predicted year that your rpi will crash, everything would have been upgraded anyway, libraries, OS, other programs. It makes more sense to redo it from scratch rather than reloading old (and in some cases, obsolete) software back on. What’s the point in doing that, and then spend another several hours upgrading, and recompiling anyway? Even Raspberry Pi’s OS gets upgraded a few times a year …
Honestly, this is how people get themselves in trouble with security patches that are never applied. They have a device running, in their mind it’s fine, and yet it has gaping security holes that are addressed in future upgrades. Seriously folks, stay ontop of updates, upgrades, and what not. Don’t juse assume a backup from a year ago, or even 3 months ago, is “just fine”. None of my OS (I said OS, not config files) backups are more than a few days old.
-
@KirAsh4 In general I agree with you. Systems with an outdated level of security patches shouldn’t be used at all. They are welcome by botnets.
But if you create a backup on a regular base - let’s say every week - your backup will not be seriously vulnerable. If you have to restore the backup for any reasons the first activity has to be to update the OS to the latest security level and everything is fine. Even if the backup is a couple of months old this works. If the backup is older than one year the OS most probably is out of service and shouldn’t be used any more. So as long as you create a regular backup every month and keep only some older backup versions (e.g. 3) you’ll be fine.
But I also agree with you that depending on your OS experience you have you also can just save version.js on a regular base via rsync and setup the system from scratch to recover. But people with less OS experience who are happy they managed to setup and configured their box will be happy to just kick off the restore followed by ‘sudo apt-get update; sudo apt-get upgrade’ in order to recover.
-
@KirAsh4 I didn’t mean that i will do a backup now and then never again. I just think it would be pretty cool to know, when someday the card is corrupt or whatever, that i have an actual backup (lets say not older then one month).
So in one or two years (and theirwhile i will have done all updates) i need to install the pi again, i will not have to do all the installation progresses of all services i used till then cause i have an actual backup i can use :) Cause it isnt just the MM i need to restore maybe…
And that is exactly the reason i opened the thread cause i want to know how others do their backups (IF they do ;) )
I hope my grammar is understandable :P -
Well, my rpi isn’t backed up. The data that’s on it is all on github so all I would have to do is restore the OS. I have yet to compile anything from scratch as I use pre-compiled packages and install via
'apt-get'
. However, for other, more dedicated servers that I run, I do back them up every single day, however again, I don’t bother with the OS. What I do backup (list based on a CentOS machine):/home - where everyone's user accounts reside /etc - because it contains a myriad of config files for the whole system /var/lib/mysql - all the MySQL databases live there /var/spool/cron - because I really don't remember all the various custom service tasks that are running /root - because I tend to keep some important, system wide stuff there /var/mail - users tend to lose their heads if suddenly their entire INBOX goes missing
Everything is done using
'rsync'
in incremental hard-links mode. This way I can keep (on average) 2 weeks worth of data without it also taking up 14x the amount of physical storage; it only copies a file if it has changed. I have a single terabyte drive that has been the backup drive for 15 different servers, storing anywhere between 2 to 4 weeks worth of data (and it’s also backed up to a secondary machine). One of the servers takes up 175GB all on itself. If I didn’t do incremental hard-links, I’d be needing a larger backup drive just for that one machine.Should the main hard drive in any of the servers die, all I have to do is swap it out for a new one and push the power button. PXE (pixie) takes over, sees that there’s no OS on the drive, and automatically re-installs everything for me from the source OS server on the network. 10 minutes later the server is up and running, fully configured, with a restore rsync running. That’s faster than many will take to finish a hot cup of coffee in the morning.
I realize this is a more advanced setup that will not apply to 95% of you here. But then, you did ask how we backup. :)
If I were to backup my rpi, that’s the same process I would take, with the exception that rpi does not support PXE, so I will still have to manually re-image the SD card and go through the setup process to get it back up and running, prior to doing any kind of restore operation on it. And since I use my rpi only for MM, there isn’t a whole lot in terms of what needs to be redone on it, other than a few git clone commands and restoring my config file. But since I run an identical setup at my office but on a regular unix server (for when I’m bored and want to do dev work), I just copy that file over and done.
One of these days I’ll map out how my internal network runs and “maintains” itself.
-
@cruunnerr I just noticed the question is not MM specific.
I have two Raspberries in production @home and I use raspiBackup which was mentioned already above by yawns to create backups every weekend - triggered by a crontask. I use rsync together with nfs and hardlinks to backup the whole systems and keep 12 backups (3 months). Hardlinks minimze the backup space used and reduce the backup time significantly because only new and changed data will be saved in every new backup. All constant data including the constant OS files will be saved only once and linked to in all backups created later on. To restore the backup I use my Linux box but you also can use your Raspberry running Raspbian if you don’t have a Linux box handy.
If you want to restore the backup from your Windows box you can create a dd backup with raspiBackup whi ch can be restored with win32diskimager. But then you don’t benefit from the nice rsync feature to use hardlinks and every backup run will save the whole SD card all the time and the backup will take much longer and you need more backup space.
I also should mention that you need an ext3 or ext4 filesystem on your backup space if you want to use hardlinks. You also can use a network drive connected via samba but then there is no hardlink support. But you can then create a tar backup which in general will be smaller than a dd backup. -
I just tried Rasperry’s built in “SD Card copier” function and it worked perfectly (16GB -> 64GB). You can find it under Accessories > SD Card copier. Look here for more specific instructions, chapter three:
https://www.raspberrypi.org/blog/another-update-raspbian/Since my actual mirror is on the to-do-list i think i’m gonna use flush mount style usb cable extension (wireless dongle for mouse/keyboard and microsd reader) as well as microsd cable extender. Both can be found on Amazon.
-
A backup of a running system is a good idea. Keep in mind how often we have trouble with new Raspbian versions. It still seems to run best on Jessi, so at least keep an image of that Raspbian version at hand that works for you (but then again, why not a complete backup image?).
My Mirror crashed with data loss and corrupted sd card and for weeks, evening after evening I couldn’t get WiFi to run on my RasPi with the new card and latest Raspbian. Finally found my old Jessi image and it worked immediately. If only I had made a backup, it would have been a 10 minute thing.