Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Router Charts

Click for Router Charts

Router Ranker

Click for Router Ranker

NAS Charts

Click for NAS Charts

NAS Ranker

Click for NAS Ranker

More Tools

Click for More Tools


Implementing Crashplan

The day arrived to install Crashplan on seven computers my client wanted backed up. The seven include a file server that I put in last year to serve as the dump point for most of my client's work.

Crashplan recently released an updated client, which includes a number of requested features like requiring users to enter a password to open Crashplan on a desktop. It did not change the overall feature set though, and is still easy to set up and manage.

The three Macs I installed Crashplan on all worked flawlessly, as did the file server running Windows 2008 R2 and a dedicated video processor running Vista 64-Bit Professional.

Two Vista 64-bit Home machines and an older Windows XP workstation gave me problems. All three were afflicted with the same issue: the background service that Crashplan uses to monitor backups and file revisions had trouble starting up. Fortunately, a reboot of each machine fixed the problem.

I don’t fault Crashplan for this. The two Vista machines had a lot of crapware running on them from both the original Dell image and user installs. The XP machine is probably about four years old now, and has never had an OS reinstalled. So I can’t even begin to imagine what lurks inside its registry.

Configuring the clients required a little thought. Files stored on the file server are, in general, going to be huge. Crashplan's client can be set to only upload backups at certain times of the day. So I set the file server and most of the computers to upload at night.

The administrative machines were set to upload during the day because they are usually shut down at night. But since the administrative machines aren't working with large video files, setting them to upload upon file changes won't impose a large bandwidth load.

Problems and Solutions

Crashplan is not the fastest service to upload to, at least for East Coast users. On the client's 35 Mbps Business FiOS line, I averaged 7 Mbps upload speed from each computer. I made sure to disable Crashplan's built in network throttling on the file server, since it has about 1 TB of data to transfer.

Crashplan Uploading Forevermore
21 days to upload almost 1 TB. That's brutal.

In total, my client has about 3 TB worth of data to transfer to Crashplan. Since the data is spread out over several computers, several uploads can run concurrently and still get about 7 Mbps per connection on average. But for the 1TB of data on the file server, Crashplan is estimating about 18-21 days to finish uploading data.

Figure too that my client won't be staying at 3 TB for long. Judging from how the file server is being filled, I would estimate a data growth rate of six to nine months per terabyte. Growth won't be consistent, since, like most businesses, my client has slow and busy times. Fortunately, we chose a slow time to implement Crashplan, so the server and the computers should have a chance to catch up.

What does all this mean? If cost were not a constraint, I would have ordered the data pre-loading service for the file server. This would have had the files loaded in a week or so vs. the three weeks it will take via internet upload.

Also, as the consultant, I should have been more forceful about streamlining workflow. Having the data spread across six or seven computers is a workflow issue and complicates the backups. This client has gotten better about this as I’ve continued to nag. But there is probably duplicate data being uploaded as I write this. Crashplan does have data de-duplication, but only within each client, not across the entire account.

Crashplan has two different product lines: Pro and regular. The professional suite is significantly more business oriented, with a server required to handle on-site backups. While we decided for cost purposes to not go with the on-site server, I would seriously recommend it once you reach more than six or seven computers being backed up. The management features alone make it worthwhile.

Pro is much more expensive, however. Crashplan Pro, for 10 computers, is $686 dollars for the first year, and $122 each subsequent year in support. Additionally, the Pro support requires an on-site server, which in my case would have required purchasing a server with enough storage to back up the file server and all the client.

A server with enough storage would have cost over $1500, which would put the initial outlay over $2100. However, Pro's centralized management is a necessity for larger deployments, and Crashplan+ does not support more than ten computers.


Overall, Crashplan works as advertised. Crashplan's unlimited data plan is a huge benefit, along with the option to overnight a large hard drive filled with data for recovery. The client interface is friendly enough for non-technical users to understand what they are looking at, so I can walk someone through a recovery over the phone.

I would love to see Crashplan improve its upload performance, or offer the ability to piggy-back on Amazon's S3. My reasoning is purely speed related. Right now we are limited to between 5 and 7 Mbps per machine. That is fine while all the machines are completing initial backups. Once that process is completed, though, only the server will be doing large uploads. And there's a good chance nightly backups will not finish in time due to the 7 Mbps limit.

My best advice for anyone looking to implement cloud backup is to take time to understand the data flow. This will highlight possible choke points, issues, and critical areas that need the most attention.

Update: Crashplan+ is no longer licensed for commercial use. Read the this for the details.

Wi-Fi System Tools
Check out our Wi-Fi System Charts, Ranker and Finder!

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Over In The Forums

I own a RT-AC3200 which is stuck on 384_13.10.However, there is a serious bug in router/rc/udhcpc.c:int dhcp6c_wan(int argc, char **argv){ if (argv...
Hello, I want to preface that I've come to this forum for troubleshooting in the past and I've usually found the answers I was looking for with a simp...
From what I've seen, Asus' speedtest inclusion in 386 looks very good, making me unsure if I should continue with spdMerlin as a project.For anyone ru...
Continuation of the first thread which covered beta 1 through 3.Beta 4 is now available. Changes since Beta 3:Code: 6adb157bea asd: disable asd on al...
I've been considering building my own router for a while now and am looking for the right SBC, or maybe even super small motherboard. I considered usi...

Don't Miss These

  • 1
  • 2
  • 3