Monday, July 30, 2012

Mountain Lion Brings Encrypted Backups to Network Drives

Starting with OSX 10.8 (Mountain Lion), the "encrypt backup" checkbox in the Time Machine preferences is no longer disabled when you're looking at a network volume like a share on a Time Capsule. It's about time.

Before this, only directly attached volumes (like USB, firewire, eSATA) had this option. This bugged me endlessly because all the beauty and ease of Time Machine was dangled in your face then taken away.

Anyone on 10.7 or lower who really wants to use Time Machine but wants it backed up to network shares and encrypted will have 2 choices.  First choice is to follow advice mentioned in the previous post about putting the unencrypted Time Machine backups into an encrypted sparseimage that resides on the network. The down side of this is that you have to mount the disk image before Time Machine will be able to back up to it. Even with Keychain memorizing the password to the encrypted disk, it still takes some manual intervention or custom Applescript automation to get it mounted.

Second choice is to find a NAS that supports iSCSI (just about all of them except the DroboFS) and configure the backup volume as an iSCSI target. This works to because to the operating system, an iSCSI volume looks like direct attached storage, not a network share. So the "encrypt backup" checkbox in Time Machine options is not grayed out, it is enabled just as if you had plugged in a Firewire external drive. The down side of this is that for 10.7, the cheapest iSCSI initiator is about $80, and the other one is $200. For 10.6, there is a free iSCSI initiator. Aside from having to buy software that costs more than OSX itself, iSCSI shares get forcibly ejected when your computer wakes up from sleep or your network connection goes away. This is the same as yanking the cable of an external drive out of your machine without properly "ejecting" it first. It can corrupt data.

So, this fix in 10.8 is welcome, and is the only reason I upgraded from Lion (which I was almost immediately sorry for last year). Now with Mountain Lion I can set and forget Time Machine to make encrypted backups to network attached storage.

As long as you are making backups, you might also think about keeping a copy off-site in case your house burns down or your stuff gets stolen. Crashplan has a nice way of letting you make backups onto your friends' computers. But suppose you have no friends and need to buy storage? Look at these annual prices.

5G 10G 20G 25G 50G 100G 200G 500G 1TB Unlimited
Google Drive free $29.88 $59.88 $119.88 $599.88
Amazon Cloud free $20 $50 $100 $200 $500 $1000
Apple iCloud free $20 $40 $100
Dropbox free $99 $199 $499 $795
Crashplan $24.99 $49.99

Biggest rip-off is from Apple. The best deal for a place to put your backups is Crashplan, who allows unlimited data storage. Its competitors like Carbonite also have unlimited storage for a slightly higher price, but I didn't bother to list them here because their programs have such strange restrictions like not backing up video files or files larger than 4GB unless you specifically ask for them, and not allowing data from external drives unless you pay more. Crashplan, on the other hand backs up everything you have unless you say not to, including all the external disks you can plug into your computer. Plus, Crashplan gives you the option to backup to local storage (your USB drive) and to your friends' computers, not just to the online service they sell. It's clearly the best deal. When digital stuff is so important in our lives, how is it not worth $4 a month to keep it safe?

The unavoidable downside of online backup service is that your hard drive is probably hundreds of gigs, if not terabytes, and so will take a very long time (days or weeks) to upload your first complete backup. Then, if you have an emergency and need your data back, downloading that much data can still take days. (You are also allowed to cherry-pick files to recover, you're not required to download everything.) To alleviate these delays, Crashplan offers a service for $125 in each direction where they ship you an external drive and you send it back when you're done. 

I'm not subscribing right now because I prefer backing up to my own external drive at an off-site place with good internet access, but if that went away, I'd sign. They even have a "family" plan for about twice as much that allows everyone in your house to pile on to make sure their funny-faces from Photo Booth will be safe forever. 

Saturday, July 14, 2012

Still chasing automatic encrypted backups

Apple disables the "encrypt backup" checkbox for any network volume.

The only way to have an easy encrypted Time Machine backup is to use a directly attached storage device (Firewire, USB, Thunderbolt). That works fine for a desktop computer that stays in one place and you can just leave it plugged in all the time. But if I have to plug an external drive in to my laptop before starting Time Machine, it's not going to get done.

Time Machine volumes are supported on my NAS, but I don't want unencrypted backups so that anyone who steals the backup hardware has total access to all my files. That would be an especially ridiculous result for any who has bothered to enable Filevault (full disk encryption) on a machine. To make it clear, Time Machine backups are not encrypted, even when Filevault is enabled, unless you check that little box to make them so, which you can't if they are on a Time Capsule, NAS or any network volume.

The workaround is to create an encrypted disk image with a special filename, mount that, saving the password in your keychain, and use the "tmutil" terminal command to make Lion accept your Time Machine disk. Even this solution is still wanting, because you have to first mount the sparse bundle before Time Machine will do any work, and if the backup plan relies on me to do anything, it's not going to be reliable or regular.

Until I figure out whether something like iSCSI will work, I'll just keep doing intermittent Crashplan offsite backups (things copy only when I connect to a VPN) and the bi-monthly SuperDuper! disk clone, which is really inconvenient on a Macbook Air whose USB ports don't have enough bus power for a 500G external drive, forcing me to also haul out and get tethered to an AC adapter for the duration.

Friday, July 13, 2012

Faster wifi for NAS or bust

The DroboFS has always been so slow that I never use it. It's just a big waste of $600. Now that I have last year's Macbook Air, there are no fast Firewire 800 (800 mbps) ports, so am stuck with USB (480mbps) for any directly attached external drives. I hate having to plug anything into the laptop, and am enamoured with the idea that Time Machine backups can happen automatically without me having to do anything or think about it.
Because I never actually get to use the massive storage in the DroboFS (because it's so slow it is unusable), I got the biggest internal SSD drive available for the Air. Now that space is running low, so I am ready to fight with the Drobo again to try to get some value out of it.

A fairly nice mechanical (as opposed to SSD) SATA hard drive may be able to read/write at 100MBs (megabytes per second).  To put that into network throughput terms, which are measured in megabits, multply by 8 because there are 8 bits in a byte. So you need at least 800mbps of network bandwidth to work a decent SATA hard drive to its limit. I'm parenthesizing megabits per second (mbps) and megabytes per second (MBs) throughout this post to relate network speed to hard drive speed (measured in MBs), since the point is answering why Network Attached Storage (NAS) like a DroboFS is slow on a slow wireless network.

Recent computers with a "SATA II" bus are capable of moving data at 3 gigabits per second (3000mbps, about 6 times faster than USB speed). Machines made after 2011 probably are "SATA III," and can drive 6 gigabits per second (6000mbps). A "SATA III" machine like my 2011 Macbook Air can work a hard drive up to 750MBs. The fastest SSD drives available right now go only 500MBs, 5 times faster than a decent mechanical drive. Is it starting to be clear that if your network has only 54mbps (54/8 = 6MBs) of bandwidth, there is no way you can take advantage of what even a crappy hard drive can do? That is my problem. Disk access to the DroboFS is only like 5MBs = unusable.

In the DroboFS are a bunch of 2TB Western Digital WD20EARS energy saving "SATA II" hard drives. The lowest benchmarks on these individual drives are around 80MBs. When added to the Drobo, though, they become part of its disk array, and how fast is that? I need to measure from the DroboFS itself, not from my Mac, because I want an answer that does not include any slowdown caused by accessing the device over a network. I just want to know what the Drobo is capable of, and then try to see how close I can get to that when accessing the device as a NAS.

So I get a root shell on the Drobo (DroboApps Dropbear) and ask how long does it take to write a 2,048 megabyte file ("8" * 1024 byte blocks, written "256" * 1024 times)

# time sh -c "dd if=/dev/zero of=/mnt/DroboFS/output.img bs=8k count=256k && sync"
real 0m 54.97s

Now I flush out any filesystem cache that might exist in the Drobo's memory by writing another file that is at least as large as the amount of Drobo's memory, so that when we read the first file back in, it will be a full read, with no "cheating" from the use of any cache. This Drobo hunk of junk has only 128MB of RAM, so 16000 * 8000 should wipe anything.

# dd if=/dev/zero of=/mnt/DroboFS/flush.img bs=8k count=16k 

After any caches are flushed, how fast can it read the first file we wrote?

# time dd if=/mnt/DroboFS/output.img of=/dev/null bs=8k
real 0m 33.70s

Thanks to this blog for the commands, info about sync time and filesystem caches.

write: 37MBs (2048/54.97)
read: 60MBs (2048/33.7)

Now I see that the maximum potential disk speed on the DroboFS is only 40-60% of what the bare drives have benchmarked when connected directly to a computer with a SATA cable. Even though I know from internet chatter that the processor and memory components of a DroboFS are cheap and under-powered, this performance loss is still a surprise. RAIDed drives add spindles, which should increase performance. But the Drobo is not RAID, it is a proprietary "Beyond RAID." Whatever.

The true performance that I will see in real world use will actually be even less than the result from the test above because those tests are done with "dd" which doesn't really consider the overhead of filesystem format.  So, real world maximum potential will be worse than those figures, let's say 30MBs, which is what most people who are giving the DroboFS favorable ratings say that it can do.

Botom line: You take a 80MBs drive, put it in a DroboFS, and now it is a 30MBs drive. Boo.

30MB/s should still be usable though for Time Machine and other backups, iTunes and iPhoto Libraries, which are the things that are taking up all the space that pushed me to external storage in the first place. Except that when I access the NAS over wifi, I'm getting only like 5MBs.

In my last post, I said I thought the slowness was due to the network, related to my Airport Extreme Base Station being from 2008 when the 802.11n spec (the fastest wifi) was still in draft. Looking at my wifi connection settings on my Air, I was always seeing slow transmit rates like "30" or "54" (megabits per second), which, divided by 8, works out to those slow MBs disk speeds on the NAS.

So I bought a new Time Capsule (instead of a cheaper diskless Airport Extreme, hedging against getting rid of the stupid Drobo at some future time) to see if that would boost my wifi speed from 50mpbs to something closer to the maximum potential of 802.11n wifi, which is 300mbps (37MBs).

I also bought an Apple USB-to-Ethernet adapter made for the Macbook Air without realizing that it has a maximum throughput of only 100mbps. I thought it was GigE (1000mbps) and just expected it to be capped at USB's maximum of 480mbps. It's not, and I've only been able to get about 80mbps out of it. That's still not fast enough (10MBs) to do anything useful with the Drobo, so it will just be an extra part I have lying around.

With the new Time Capsule, I saw my wifi Transmit Rate jump up to 130, almost triple what I was getting with the old Extreme.

But I'm sitting right next to the Time Capsule, and the maximum "n" speed is 300, so it should be faster. Then I notice that it is connecting to the 2.4Ghz band. A nice thing about the new Airport Extremes and Time Capsules is that they broadcast on both the 5Ghz and 2.4Ghz frequencies (so 2.4Ghz-only "n" devices like iPhones and iPads can still join). I wanted to connect at 5Ghz, expecting it to be faster, but the laptop always ended up on 2.4.

I fixed this with Airport Utility by setting the 5Ghz frequency to get a different SSID under the Wireless tab, then the Wireless Options button.
Then I could force the Macbook Air to connect to the 5Ghz network by clicking the Menubar's wifi fan icon, Join Other Network, and entering the distinct SSID. After that it connected to the 5Ghz network with the full 300mbps Transmit rate.

Now my wifi is 6 times faster than when I started. It's still nowhere near the 1000mbps of a wired GigE network, where a NAS would work fine because there's more than enough bandwidth to get full performance from even a 100MBs (800mbps) hard drive. But accessing the same drive at maximum wireless speed, 300mbps, still cuts off about 60% of the drive's performance (300/8 = 37.5MBs). Even so, 30MBs should at least be usable, not like 5MBs. Or 2.5MBs, as experienced by this person whose DroboFS review I enjoyed.

I'll tell you whether any of this saves my DroboFS from the garbage can as soon as my Time Machine backup to the Time Capsule finishes.

* * * *

After my new Synology DS412+ arrived, I took 4 WD20EARS 2TB drives out of the DroboFS and put them in the new NAS configured in a RAID10 set.

RESULTS from "dd" tests at DS412 shell:
write: 273MBs (2048/7.49)
read: 218MBs (2048/9.36)     <-- wow, is that crazy fast for "green" disks?

RESULTS from "dd" tests at Mac shell writing to DS412's AFP share over Wifi
read: 24MBs (2048/85.76)
write: 27MBs (2048/74.68)

RESULTS from "dd" tests at Mac shell writing to Time Capsule (4th gen) share over Wifi
read: 19MBs (2048/108.82)
write: 12MBs (2048/175.14)

Summary: Time Capsule passes (it's just backups and doesn't need to be very fast). DS412+ fileshare over 802.11n wifi is in the usable range. Numbers directly on the DS412 made me recheck my math 3 times.

This tells me that, yes, the DroboFS was about the worst network attached storage device available on the market when I bought it in 2010. They still sell them today. Garbage.

Sunday, July 08, 2012

DroboFS, so slow. NFS Slower.

Two years ago I got a DroboFS because I wanted extra storage accessible to the whole family, a place to keep Time Machine backups, easy hotswap maintenance, and no hassle with plugging in any directly attached storage devices. The Drobo FS can do all this, but it is so slow, I hardly ever use it. Whenever I do try to use it, it is such a slug, I almost always get sidetracked starting to research something to replace it so I can get rid of it. Like this guy.

Using the DroboFS over 802.11n (2.4Ghz, n-only) wireless, it reads and writes at about 5MB/s (megabytes per second). This is under OSX 10.7.4 Lion, the most recent Drobo firmware 1.2.4, and all Western Digital 2TB EARS "green" drives. It's about the same speed when the base station is set to n plus b/g compatibility. In my house, the n-only 5Ghz was worse.

I have read that the best DroboFS will ever do is about 30MB/s (megabytes per second, or 240 megabits per sec), which is 6 times faster than what I am getting out of it over wifi. Sometimes I would be willing to plug in to ethernet to get things moving faster, but that's not very convenient on a Macbook Air with no ethernet.

The Apple Airport Extreme Base Station that I have is from 2008 and can do "802.11n" according to the draft specification that there was at the time. That should mean wireless speeds of up to 160mbps (20 megabytes per second). However, I have never seen it go faster than "g," which is a maximum of 54megabits/sec (6.75MegaBytes/sec). I know this because iStat Menus gives me nice little speedometers in the menubar that I am always checking. If my base station is too old to get real world "n" speed, then I am within 1MB/s of what the hardware can push and it's not Drobo's fault that it's  practically unusable over wifi. But, assuming that I can get "n" wifi speed, there are 15 more megabytes/second (3 times faster) that I should be able to read from/write to it.

While trying to find out whether there was any way to make it faster, I read that some people found some performance gain using NFS, as opposed to the built-in AFP protocol. In order to try it, you have to enable DroboApps, and install the unfsd. I did that and found NFS is even worse than AFP, losing about 1MB/s in both read and write speed.

In order to get NFS to even work at all, I had to read a lot of blog posts. The default exports file that comes with the unfsd app offers to share every share created in the Drobo Dashboard:


and uses the "no_root_squash" option, which means that files created over NFS get done on the Drobo system as the root user. That is usually not good, and usually the opposite of how any software would generally come by default.

In order to connect to this NFS export you can either get to the Finder and choose "Go, Connect to Server" from the top menu (Command + K) and type:

nfs://[IP address of DroboFS box]/mnt/DroboFS/Shares/

(Notice that the path on the end of that connection string is the entire full path to the share from the perspective of the Drobo box. It won't work if you put the share name alone after the IP address.)

Or you can manually mount the export from a shell prompt. Before mounting this way, you have to make an empty directory as the spot that you will mount it on top of. So, first:

mkdir ~/myDroboshare

sudo mount -w -t nfs /Users/[your username on your Mac]/myDroboshare

all the above has to be typed on 1 line.

If you do one of the above, then you'll find the share accessible to OSX and can see it in Finder windows, and from a shell prompt you will be able to write in there. But from the GUI, everything will appear as a read-only filesystem. GUI apps will think they cannot write in there and give you error messages.

In order to fix this problem, you need to get back to the Drobo box and edit the file that is in the same directory as the exports file (/mnt/DroboFS/Shares/DroboApps/unfsd/) and add in a "-s" for "single user mode" to this line:

${prog_dir}/unfsd -s -e ${exportsfile} -i ${pidfile} >> ${logfile} 2>&1

After editting the file, you want to restart the nfs service on the Drobo box. The best way to do that is by running that script from a shell prompt on the DroboFS box:

/mnt/DroboFS/Shares/DroboApps/unfsd/ restart

In order to do it that way, you will have to have installed the Dropbear SSH app, and ssh into the box as root. Otherwise, the only way to restart any of these DroboApps is to restart the whole DroboFS box, by turning it off and on, or using the "restart" button in Drobo Dashboard under the "Tools" menu.