I just had a few quick questions that some of you may be able to help me with.

I am based Hong Kong and have about 2tb of data to backup, I am more then happy to wait 2-3 months for it to get backed up… that doesn’t worry me.
I have been reading about crashplan and backblaze as they seem to be the best options for me. I don’t think either have servers based in Asia, does any one know if they do ?

Of course I am a bit worried about experiencing issues like some of you have had regarding losing your backups as I would hate that to happen to me as my seed time is so so long esp being out here in hong kong.

Is anyone else using either backblaze or crashplan from asia with a large amount of data to backup?

Actually I have a few friends all with 2-6tb of data that are also considering using one of these providers.

Thanks for your help and once again a great blog here for people for finding out information.

Cheers,
Mike

I can understand their reasoning as far as playing it safe with the average user but I deal with corporate backups on a day to day basis so I’m happy to take responsibility for what is backed up. Unfortunately I just can’t get that level of granularity with Backblaze :(

- @courtneyBolton

Ideally I would use Amazon S3 given the huge redundancy they offer but I found the price prohibitive given it is personal data (maybe I will store a small subset of near and dear finished albums on there still). If I was running a professional business I would do it without a second thought, but as a private consumer it can add up quickly.

I had narrowed it down to Backblaze and Crashplan. My favourite was easily Backblaze due to the high level of openess and honesty present within the company (recent reddit AMAs for example), but the application just didn’t offer the functionality I was after. I only wanted to backup my photos and nothing else (I have a Windows Home Server backing up our PCs, I can live without some of our other data in a major emergency but losing all our photos would be heartbreaking). I live in New Zealand and bandwidth caps are a very limiting factor for me. In fact up until about a week ago online backup was simply out of the question, so it is absolutely critical I have the granularity to backup only what I explicitly want.

This left me with Crashplan, which I initially felt pretty good about until seeing this post and comments. They do seem like they have put a lot of work into their product and are willing to help the end user. I can understand that support is stretched thin at the moment due to rapid growth. I hope they’ve learnt some valuable lessons from these events and can only hope they come out better for it.

This thread provided an opportunity for Crashplan to establish itself as a responsive, attentive company that understands and respects the needs of its users. Instead they look secretive and out of their depth.

This stuff is really not hard. Responding to these kinds of things is essentially free. I know you are reading this (yes, you) – if you think this thread will just evaporate on its own, you’re crazy. Respond! Egads. Oh, and while you’re at it, I want my promised 3 months of free service – though my data was restored, my account has yet to reflect this change.

To their credit, the refund was relatively quick & easy.

Perhaps in time I’ll revisit Crashplan Enterprise, as there really isn’t anything quite like it on the market that I can find.

However, the situation described above is quite different. As stated in CrashPlan’s announcement: “a storage node in one of our Minneapolis data centers experienced a hardware failure. While typically a non-event, additional human error escalated this failure into backup archive corruption”

Since the data loss was triggered by a hardware failure (and then exacerbated by human error), having a second copy of the data stored elsewhere would have allowed a full recovery.

A bit of conjecture based on CrashPlan’s description of the source of the problem: Their description of the problem sounds as if they had a drive failure in a RAID array. Normally this is a non-issue, since there is no data loss at this point and replacing the drive will restore redundancy.

Until the failed drive is replaced and the RAID has had a chance to rebuild, the data stored in the RAID remains vulnerable. The failure of another drive in the array prior to the replacement drive being rebuilt will cause all data in the RAID array to be lost.

If CrashPlan’s “human error” involved replacing one of the good drives of the RAID array instead of replacing the failed drive, this would be the same as having a second drive fail before the RAID has rebuilt its redundancy. The result of this human error would be the loss of all data in the RAID, instead of the RAID rebuilding its data redundancy using the failed drive’s replacement.

If this conjecture is correct, total data loss was unavoidable since CrashPlan does not have redundant storage and apparently does not backup their data servers.

As with all purchases, you get what you pay for. Since the fees charged by CrashPlan for their unlimited plans won’t even cover the cost of the hard drives needed to store a heavy user’s data, it is understandable that they don’t provide redundant storage (although it would be nice if they offered this as an extra cost option).

While I feel that they should still perform periodic backups of their data servers, the volume of data requiring backup makes this expensive (but potentially less expensive than true redundancy).

So, unless CrashPlan eventually offers redundant cloud storage for an extra fee, we shouldn’t rely exclusively on their copy of our data. Of course, this remains true even if they do offer redundant storage, even though the odds of failure are vastly reduced.

In their defense, CrashPlan’s software is unique, since it supports multiple ways of performing off-site backups – we aren’t tied exclusively to their data center.

The ideal backup plan should include a local, on-site backup, a backup to an off-site computer and a backup to the cloud.

In the end, if any data were to be completely lost, much of the blame has to be placed on the user who failed to design a proper, multi-level backup strategy. At most, the loss of data stored in the cloud is a (albeit major) contributing factor to the total loss of data.

Also, if you read the details of this data loss, it appears data corruption was the culprit, and it’s not clear if redundancy would have been any help in this case (data could be identically corrupt on several servers). There are lots of ways software error or user error can delete or screw up data on all servers.