Unfortunately, that’s a hard one to figure out. It’s going to have to be a trial and error for you. Generally, the higher the transmission rate, the less reflective you will get.

I don’t remove config sections … I comment them out … If I’m going to edit that file to change a flag, it’s just as easy to add a /* ... */ tag around the specific section. :)

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.

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.

You can’t put it in a Win machine and “see” it. Those partitions are unix specific, and Windows can not read them, at least one of them it can not read. Different filesystem. If you need a backup, your question should be: what do I want to back up?

• The file system can be recovered simply by burning a new image on the SD card and reconfiguring
• MagicMirror can be reinstalled by doing a 'git pull'

As far as MM is concerned, what’s user configurable is your config.js. Any modules you’ve installed can be reinstalled with a simple 'git pull' to the repository. So you can cut and paste your config.js into Notepad. You can use FTP to transfer it …

For the other, system specific configurations, you can copy all of those config files over to a Win machine.

Honestly, I don’t backup my MM. I don’t see a need to. It’s easy enough to recover, unlike a Windows machine and all the applications on it. I can wipe the card, and start from scratch and have it back up and running within 15 minutes. Try doing that with a Win machine … unless you’re doing a full system image restore, which still takes longer.

And I’ve been running computers, servers, all types of systems for decades … an rpi running MM isn’t worth doing a backup on. And mine even contains copies of my own code that I’ve written. But since that stuff is also on github, again I don’t see a need to bother. A simple 'git pull' and 30 seconds later I have it all again.

I probably won’t, at least not on my production mirror. I will on my test mirror, but that won’t happen this weekend … maybe next.

I’m expecting my very own issue in my mailbox, together with some parts to make one … c’mon MagPi!

If your FitBit application requires running on port 8080, you will run into exactly the problem you have because MagicMirror also runs on that same port. You will have to change one of them. MagicMirror is easy to change, it’s in the config.js file. Change the port setting to something else, like 8081 …or 8585 … or 8123 … doesn’t matter, as long as it’s above 8000, and not 8080 since the Fitbit runs on that port.

You have something else on port 8080. Figure out what, change it, and the problem is fixed.

NOTE: MagicMirror runs on port 8080 by default.

If you can’t log in with that default user and password, and you never changed it to begin with, I would seriously wipe that SD card and start over. There’s no telling what happened to it or why the password is different. And since it’s an internet connected device, that’s cause for alarm, or at least be concerned.