December 2014

A Backup Restoration Story

For most of my computing lifetime, I didn't bother with backups. They were too much trouble, and back when it took 20 floppy disks to back up a Mac hard disk, they took too much time. But now with services like Time Machine, CrashPlan, Backblaze, Dropbox, and Google Drive, it is pretty easy to keep redundant copies of everything. I had files in these locations:

  • my main laptop
  • my old laptop (given to stepson for schoolwork), which still had all my files on it from the time before I got the new laptop
  • family iMac, which in addition to having copies of my important files also had an external hard drive that held Time Machine backups for all home computers
  • CrashPlan (offsite backup)
  • Dropbox (which is not really a "backup", but it means it's easy to maintain multiple copies of important files)

So I thought I was pretty well backed up, until a few events happened in a short period of time:

  1. My main laptop's SSD filled up with work-related stuff, so I deleted some big non-work-related stuff (Aperture library, virtual machine images), because I knew I had copies of those things on my old laptop, our iMac, and in CrashPlan offsite backup.
  2. My old laptop died when the kid dumped a glass of milk on it. So that's one old copy gone, but hey, we have others, right?
  3. The external hard drive that held our Time Machine backups failed. So I bought a new external drive and reconfigured Time Machine on all our machines to back up to it. That meant we lost our old Time Machine backups, I didn't worry because I knew I had copies of important stuff on the family iMac, and we'd have fresh new Time Machine backups in no time.
  4. The old family iMac died. We were lucky in that Apple botched the repair, and gave us a brand new machine to replace it, but the downside was that we lost everything that was on that machine's internal hard drive.

These events all happened within a month. In hindsight, I wish I'd reacted faster, but at the time, I just thought, "It's OK, we still have other backups."

So, anyway, we get this new iMac, and I figure I can just plug the external Time Machine drive into it and we'll have all our data back. But no: apparently I when I configured all the other family Macs to back themselves up to the family iMac's external drive, I neglected to configure the iMac to back itself up.

I had to fall back to the CrashPlan backup. I am very glad we had it, because otherwise we would have lost our family photo archives and some other important stuff. But the downside is that it has taken about five days to restore everything from CrashPlan. I don't know whether to blame our ISP or CrashPlan for the slowness of the restoration, but being unable to use that new machine for five days has been annoying.

CrashPlan's restoration functions suck. When I set up the CrashPlan app on the new iMac, it asked whether I would like to synchronize that new iMac with the old iMac's backup. "Sure, that would be awesome" I thought, and I clicked Yes. Then it took two days for the synchronization to complete, and during that time I couldn't restore anything.

Then, when synchronization finally completed, I checked the box to restore the entire hard drive and clicked the Restore button. CrashPlan spent a couple of hours counting up how many files that was and how big they were, and then it crashed. I tried again, waited a couple of hours again, and it crashed again. (So you need to have a plan for when CrashPlan crashes.)

Because it apparently couldn't restore the entire hard drive at once, I selectively restored individual folders (Applications, /Users/kdj, /Users/pebble, etc.). This worked, but again I had to sit at the computer for a long time while CrashPlan counted up all the files, because after selecting something, you can't click Restore until it finishes counting them up.

And then after restoring, I noticed some files missing, so I had to go back into CrashPlan and play with the options to get it to restore files from the date our old iMac died, and to include deleted/hidden files.

So, lessons learned:

  • Make sure all machines are backing up to Time Machine. Check this every week or so.
  • Restoring from CrashPlan sucks. Maybe that's just the nature of restoring a few hundred gigabytes of data over the Internet, but I may look into other options when my annual subscription expires.
  • When some link in the backup chain breaks, fix it right away.

The Good Old Days and Tiny BASIC

This week, we learned that Dr. Dobb's Journal is shutting down after 38 years. Admittedly, I haven't paid much attention to Dr. Dobb's for the past few years, but back when I was a kid who wanted to be a programmer, I anxiously awaited each monthly issue so that I could read every single article multiple times. We didn't have the Internet to give us whatever training we needed whenever we wanted, so magazines like Dr. Dobb's were precious.

While reminiscing about Dr. Dobb's with other grieving Twitter users, somebody brought up the fact that the first issue was titled "Dr. Dobb's Journal of Tiny BASIC Calisthenics & Orthodontia: Running Light Without Overbyte" (which I think is the coolest magazine title I've ever heard). It started as a xerographed newsletter to tell people about Tiny BASIC, a simplified BASIC programming language interpreter that could run in 2 or 3 kilobytes of memory. That was an important feature back when personal computers had only 4 kilobytes of memory.

Having just completed an implementation of a Forth programming language interpreter in Apple's new Swift programming language, I got the idea of implementing a Tiny BASIC interpreter in Swift. It didn't make any sense. I didn't want to write any programs in Tiny BASIC. I didn't think anybody else would want to write any programs in Tiny BASIC. There are more important things I could be doing with my free time.

But, apparently, reimplementing 50-year-old programming languages in Swift is my thing now

I did it. I call it "Finch", and if you want it, you can find it here:

Useless as it may be, it was an interesting exercise. Most of the Tiny BASIC implementations you find are focused on the original goal: getting a full implementation to fit in a few kilobytes. That isn't an important goal anymore, but I liked the idea of implementing a very-simple programming language. I focused on these goals:

  • Use Swift's high-level abstraction features, rather than writing code that looks like C or assembly language.
  • Make it easy for new Swift programmers to understand, so it could be useful as a beginner's example or in a tutorial.
  • Make it easy for people to hack on to add new features.

I think I did alright. It's about a thousand lines of code (not counting blank lines and comments), which is smaller than a C-based Tiny BASIC implementation I found, and I don't think I did anything too complicated. I will have to wait and see if anyone else wants to hack on it.

BASIC was the first programming language I learned. I expressed an interest in programming after attending an IBM open house, and my father brought home a BASIC programming manual. I studied it intently, but there weren't any computers around, so it was a while before I could try out what I had learned. But eventually the Radio Shack at the local mall started selling the TRS-80, and I could walk into that store and write my very first program:

10 PRINT "TRS-80 SUCKS! ";
20 GOTO 10
RUN

With great power comes great responsibility.

SuwaneeForth: A Forth Implementation in Swift

Using a new high-level programming language to implement an old low-level language is a strange thing to do, but I've done just that. SuwaneeForth is an implementation of Forth interpreter, written in Swift. If you are interested in such a thing, you can find it here:

SuwaneeForth is a translation/port of the system described in "A sometimes minimal FORTH compiler and tutorial for Linux/i386 systems" (a.k.a. "JONESFORTH") by Richard W.M. Jones. I'd suggest that all programmers read the source to that, as it is a very readable tutorial for bootstrapping a programming language implementation.

I heartily agree with the first paragraph of jonesforth.S:

FORTH is one of those alien languages which most working programmers regard in the same way as Haskell, LISP, and so on. Something so strange that they'd rather any thoughts of it just go away so they can get on with writing this paying code. But that's wrong and if you care at all about programming then you should at least understand all these languages, even if you will never use them.