Back Up

It took three days, but my main computer is up again. Though, to be fair, one of those days was spent determining the extent of the problem.

At this point, let me state for the record that backups were not the problem.

I don’t actually know what the root cause of the problem was. Over the course of a couple of months, I got occasional pop-ups from Windows telling me to restart so it could check the hard drive for errors. And before anyone asks, yes, as best I could tell, the warnings were legit. Each time, I did as requested, the pop-ups stopped, and Windows kept chugging along.

Until last week. I restarted, watched the error check fail, and then Windows crash on boot. Several attempts to repair the problem failed.

Conveniently, my automatic backup had run the night before. I figured I could just restore from the backup and be set.

Before I go any further, let me summarize my backup strategy:

  1. I keep Windows and my programs on a separate hard drive from my data. That makes it easy to do…
  2. A full backup of the Windows drive that runs once a week. This is stored on a separate computer.
  3. A backup of all of the important data from the data drive to the second computer. This runs daily.
  4. Critical file–mostly, my writing–are stored in Dropbox, meaning they’re typically backed up within a few minutes of my making changes.
  5. Unfortunately, there are a few things that don’t fit well in this scheme. My email archive, for example, is stored on the Windows drive and can’t easily be moved. So messages I thought were important enough to save only get backed up once a week. Not ideal. I’m looking at that and a few other similar cases.

So I had a full backup of the Windows drive that was less than twelve hours old. Since the backup runs during the night, I’d only lose emails that had come in before I got up—which, as it happened, were entirely spam. Seems like a no-brainer to restore, right?

It took less than fifteen minutes. Windows booted, and I was back in business. For about an hour. Then I got the dreaded pop-up.

Restarted. Windows crashed.

I’ll skip about six hours of experimenting. Long story short, the backups were faithfully backing up both the corrupted files on the drive and whatever rogue program was causing the corruption. Which meant that, even if I fixed the corruption before booting Windows, the damage would continue to accumulate. I also checked back several months and the corruption was in those backups as well. Obvious in retrospect, since I’d been getting the warnings for several months.

At that point, I had two choices: I could wipe the disk clean, reinstall Windows and my programs, and reconfigure everything. Or I could go back far enough to get clear of the corruption.

The second choice had a lot of appeal, but when I started looking at the amount of work involved, I realized it would have taken even longer, since I’d have to figure out which backup was safe, and then do all the same reinstallations and updates to get me back to current. And there are some advantages to starting fresh, most notably, all the programs I’d installed ages ago and hadn’t used since would be gone, freeing up disk space and clearing a bunch of useless junk out of the Windows configuration.

So I did the clean install. The good news: Most programs store their configuration information in a hidden folder called “AppData”. Since my AppData had been backed up and was, fortunately, free of corruption, I was able to skip a lot of setup work. Instead of installing the programs and then trying to remember how they had been set up originally, I could restore the AppData information for a program and then install it. Most of the programs recognized the AppData and treated their installation as an upgrade. Very handy.

Also very handy: Windows 11 has a new installer program called “winget”. Instead of going to the website, clicking through several links to find the installer, then running it and answering a bunch of questions about how to install it–questions that I, like everyone else, generally takes the defaults on–all I had to do was type “winget install” and the name of the program. The installer downloads automatically installs with all the default values*. No questions, no clicking. A shame Microsoft didn’t do that years ago.

* The Linux-savvy among you may be thinking “Hey, that sounds a lot like installing a program with apt-get or zipper.” You’re absolutely right: it does. Funny, that.”

Lessons learned:

First–and I knew this already, but it bears repeating–you can’t have too many backups. Not backups of backups, necessarily, but the more important something is, the more often you should back it up and the more places you should back it up to.

Second, since you’re doing multiple backups anyway, use different tools. This improves your chances of being able to recover your data from somewhere even if one or two copies isn’t available, due to a forgotten password or other lapse.

Third, automate your backups as much as possible. A backup that has to be done by hand is a backup that isn’t going to happen nearly often enough.

And fourth, don’t assume your backups are perfect. Have a backup backup plan.

Good Times

The good times never last forever. That’s a universal law–just ask any Warriors fan. It’s true in baseball, and it’s true in technology.

Since I wrote about the winning ways of the Mariners, Orioles, and Giants, the three teams have gone a collective 3-10. It’s not hard to see why: in those thirteen games, they’ve scored 43 runs and given up 86. With run differentials like that, it’s a minor miracle they’ve won any games. (Kudos to the Orioles, who contributed two of the three victories.)

There are around fifty games left in the season. The Mariners are trying to figure out their next few seasons, the Orioles are looking for ways to earn some self-respect, and the Giants are hanging onto a small chance of making the playoffs.

Meanwhile, we’ve recently gotten a lesson in how the universal law applies in the wonderful world of technology.

Maggie’s much-beloved cell phone passed away. Maggie refuses to give up a physical keyboard, so she clung resolutely to her BlackBerry Q10.

Let it be noted that I’m not casting aspersions on her choice. I see the appeal of a physical keyboard and still fondly recall my RIM 750, from back in the days when pagers were state-of-the-art. Where we differ is that I’m not willing to put up with the compromises necessary to have that keyboard.

Those compromises are on the software side of the equation. BlackBerry is, if not the only company still making phones with keyboards, the only one with any actual US distribution. Their latest phones run almost-stock Android–although updates can be erratic–but the Q10 runs BlackBerry’s proprietary operating system.

That, naturally, makes it hard to find software to do some very basic things. Like, for example, back up your data.

There is, or was, a Dropbox client for the Q10. It was hard to install, confusing to configure, and usually refused to run automatically. These are not desirable traits in software you want to back up something as precious as years of cat photos.

Then there are all those years of collected emails, text messages, and the contacts that go with them. Turns out that even though the Q10 requires you to use a GMail account for setup, it only uses GMail for transport. Received emails and contacts live on the device. Contacts can be synced to Google, but it’s a manual process.

Want to see if anything has been backed up to your user account on the carrier’s system? Better hope you don’t have Sprint: they require a two-step authentication process that involves sending a text message to your phone. You know, the phone that doesn’t work.

The lesson here is NOT that BlackBerry sucks or that Sprint is horrible.* It’s not even that one should avoid unusual systems or devices.

* Ironically, it was exactly here that Firefox crashed, taking Windows down with it and forcing me to turn the power off without saving anything. Fortunately, I had just saved two minutes before, so I didn’t have much to recreate.

The lesson is that the good times will end. They’ll be back eventually, sure. But they’ll return much faster if you prepare for them. In baseball, build up your farm system. In computers, backup.

Backup everything. Frequently. Make it part of your daily routine. If you can’t do an automatic backup, do it manually.

Ite, missa est

Ick!

If you’ve got a sensitive stomach, you might want to stop reading this post now.

Still here? The subtitle of this post is “How do you disinfect a tablet?”

The short answer appears to be “You don’t.” But let’s back up a bit.

A few weeks ago, I dropped my Nexus 9 (poor Kei-kun!). It landed on edge (wince) in the litter box (double-wince). Fortunately, I had just emptied the box, so there weren’t any, ah, chunks of ickiness. That also meant the top layer of litter was about as clean as it gets. And, since the tablet was in its case, the only part to come in contact with the contents of the box was the screen.

Have I mentioned that there are many good reasons to keep your tablet in a case that provides full coverage? No? Consider it mentioned.

Step One was to get the tablet out of the case. Easily done. I set the tablet and case on newspaper* and moved on.

* I have one thing to say to my friends who tease me about still reading the newspaper instead of getting all my news online: “Nya, nya!”

Step Two was to wash my hands. Thoroughly. Several times.

Step Three: Research!

I couldn’t find any reputable sites that gave instructions for decontaminating tablets or phones–though quite a few warned against spraying Apple screens with any kind of cleaning fluid. Apparently the coating Apple uses to minimize fingerprint smudges is very vulnerable to cleaners. Since, as far as I can tell, Nexus devices don’t have a similar coating–a quick look at all the smudges on my poor tablet made that obvious–I moved on.

OK, I can’t sterilize Kei-kun. What about disinfection? There are quite a few click-bait articles referencing a somewhat questionable study that claim phones are covered with something like 18 times as many bacteria as toilet seats. Most of the articles take great pleasure in telling you there’s nothing you can do about it; A few suggest using alcohol, though it’s unclear whether you’re supposed to use it to disinfect the device or just drink enough that you don’t care how disgusting your phone is. sigh

How about benign neglect? I tried to figure out how long bacteria live on glass and plastic. Turns out it depends on the specific bacteria, the kind of plastic, the humidity, and probably several thousand other factors. The range is from “a couple of hours” to “months”.

At this point, it had been a couple of hours, and I was suffering from tablet withdrawal. No way was I going to make it for months. I sprayed the tablet and case with an alcohol-based screen cleaning solution–carefully avoiding the buttons, camera, and speakers–and went to bed.

Step Four: Ignore the case. I figured that most of the bacteria on it would either die or get bored and go in search of a more interesting habitat within a couple of days. And, as long as I washed my hands, using the tablet was no more of a health risk than cleaning the darn box. I went through an unusually large amount of soap over the next couple of days.

I also noticed that the tablet was running hot. Mostly just warm, but when installing app updates, it got uncomfortably hot on a couple of points. Since I’d been using in the case, I had no idea whether the amount of heat I was feeling was normal.

Step Five: Return table to case. I was figuring another couple of days of excessive handwashing, and life would be back to normal. A couple of hours after I started using the case, the Nexus rebooted. And again forty-five minutes later. Back out of the case and back to the Internet.

Interestingly, overheating Nexus 9s seem to be a thing. The consensus is that it could be caused by a hardware problem or a corrupted system file, and either condition can be caused by dropping the tablet.

Step Six: Use tablet without a case and switch to a “smart cover” to protect the screen without allowing heat to build up. I figured that would hold me until the Android Marshmallow rollout. Upgrading the OS would then replace the entire system, and–hopefully–resolve the overheating problem. And it does seem to have helped. The tablet is definitely running cooler. I’m just not sure it’s running cool enough to risk putting it back in the case.

Which, of course, means that it could give out on me at any moment, case or not. I had some hope that Marshmallow’s auto-backup system would give me some peace of mind. Early reports were that it would back up all apps unless developers specifically opted out. However, it turns out that’s only true if the app has been targeted for API 23*. Older apps won’t be backed up.

* That is, the app needs to be compiled with the Marshmallow SDK and have the Marshmallow feature-set turned on. This is easy to do, but good software practices require app testing before making such a change. As of this writing, approximately a week after I got the upgrade, exactly two non-Google apps are being backed up: my alarm clock app and Yelp.

So I’m back to using the command line backup tool I talked about back in January. And running with the less-secure smart cover instead of the case. Pray for me and poor Kei-kun.

Google, can we please get a backup system that Just Works?

Interesting Times, Part 2

Welcome back. Last time, I implied that Google had made a big mistake in designing Android. Today, I’ll explain.

I can summarize the problem in one simple sentence. It’s impossible to back up your Android device.

Really.

There are some partial methods:

  • Turn on “Back up my data”. (Android prompts you to turn it on when you’re setting up the device, but if you declined, you can find it in the “Backup & reset” section of the Settings app.) This sounds good. According to the menu in Lollipop, it will back up “app data, Wi-Fi passwords, and other settings to Google servers”. Unfortunately, the description is somewhat misleading. Your Android settings will be backed up. So will a list of all of the apps you’ve installed. What won’t be backed up is the settings of all those apps. Game progress? Not backed up. List of websites in your RSS reader? Not backed up. Configuration of your e-book reader, social network apps, and weather app? Not backed up–unless you’re using Google’s own apps. The problem is that Google has made the APIs for saving configuration and app state optional. The number of developers who actually use them is miniscule.
  • Install a backup app. There are some. Some of them even work–but only for data the individual apps have marked as public. As part of Android’s security model, apps are largely prevented from accessing any data but their own. In order to do a full backup, you need to root the device. That requires a user to gather instructions and software from several places around the Internet and risk bricking the device. In many cases, it will void the warranty and prevent automatic installation of OS updates–and configuring the device to allow rooting will wipe all of the data on the phone. Yeah, the same data you were trying to back up.
  • Use the backup tool from the developer’s kit. Uh-huh. The average user isn’t going to use any tool that requires them to type commands. Heck, never mind the fact that the average user doesn’t back up their computer and wouldn’t see the point in backing up their phone; the portion of users who would even install a command line program is too small to count. Not that it would help much if they did. Google warns that backing up app data isn’t fully supported, and may not work.

The bottom line here is that as soon as you install one non-Google app, you have almost certainly lost the ability to move your electronic life from one device to another.

That’s not just a problem for people whose devices suddenly drop dead. It affects anyone who wants to upgrade to a new phone (Gotta have that larger screen, right?); anyone who needs to change carriers; and, of course, anyone who doesn’t trust Google to keep their data safe when the NSA comes calling.

Unfortunately, there isn’t much Google can do to repair the problem at this point. Google doesn’t review apps at a level of detail that would allow them to require apps to use their backup APIs. Future versions of the OS could introduce a limited form of root access (similar to Windows’ “Administrator mode”), but that wouldn’t help anyone using a device with an older OS–which is most users*.

* As of January 5, Google’s own numbers show that less than 0.1% of users have picked up Lollipop since its November launch. Less than 40% have even gotten as far as last year’s KitKat release. Hell, nearly 8% are still using Gingerbread, which hasn’t received any updates since 2011.

Security is a spectrum. Every vendor has to strike a balance between user freedom and protecting users from themselves. In this case, Google put the balance point in the wrong place. How many would-be phone upgraders, faced with the task of re-entering all their app settings have changed their minds? A little more freedom, and we might not have all of those Gingerbread and Honeycomb users still clutching their aging hardware and praying that it won’t die on them.