'While files are expunged from the servers after 30 days if they're removed from a computer, your most recent backup snapshot will be retained for 6 months if your computer is completely unable to contact our servers (either it's shut off, or no internet connection). As long as your computer can contact Backblaze at least once every 6 months and perform a full Backblaze file scan operation, you don't delete or transfer the backup and you retain active billing, your most recent snapshot will be retained.'
https://help.backblaze.com/hc/en-us/articles/217664898-What-...
I use it strictly for "personal" and critical data that I cannot recover or get from anywhere else once lost - personal pics, personal videos, my notes - diary, some mails. No, not all mails - most of them are left with Google, MS, on my VPS and if they are gone, I am not gonna miss them terribly. I don't even store my code on CrashPlan servers - for that's there gitlab and bitbucket (mirrored there) and my external hard disk.
In fact I have a ~3GB folder in Dropbox that I have named "Emergency Backup" and if all is lost I might be happy with just that.
It's not that I am being a model "low storage" customer so that CrashPlan can function. But I want to keep my backup habit disciplined (in my own way, of course - many would find my backup strategy as stupid for their own use cases and that's fine).
So please, for the love up proper backup, bring unlimited versioning and file retention for customers like me :-) Or float a cheaper plan where you limit the storage. Or hell, bring something like cold storage and dump my backup there (I know B2 but that's not what I am looking for; something baked in your main backup service). All I would do is periodically keep checking whether my backup is there or not and I will just leave it be. (Okay, if not really unlimited then something close to it).
We need a CrashPlan alternative. I am willing to stick with and wait for almost a year but after that I would like to move to a better alternative and more trustworthy which you are - except, in all honestly - that glaringly missing (or omitted) critical backup feature. Also, my backup is something I want to pay and let someone else handle in a very solid way.
Here's a discussion I had with Brian few days back and there are some points I have raised. I am not saying they are brilliant ideas, actually that is a wish-list but please have a look if you can - https://news.ycombinator.com/item?id=15074647
I understand the price difference but I want the ease, peace etc, not something where I need to hook two or few things together.
Keep your focus on the storage angle, there are ways to accomplish this, I use a "glue box" (Synology NAS) to collect the data and fire it off to B2, could easily be a linux machine running b2 cli tools[1].
[0]: https://wiki.zmanda.com/index.php/Zmanda_Windows_Client
[1]: https://www.backblaze.com/b2/docs/quick_command_line.html
For offsite backup, I use a time4vps storage server, but I might transition to B2 in the future. I like what I'm hearing.
> Part of it might be because they don't support Linux
Backblaze DOES support Linux through the B2 product line and third party applications. There is a list of applications that support Linux here: https://www.backblaze.com/b2/integrations.html (scroll down and look for pictures of Penguins).
Supported applications include Dupicity which ships inside of several Linux distributions such as Ubuntu and Debian. So you may already have your local client application pre-installed on your linux computer ready to backup to Backblaze!
> I've heard stories of people using Amazon to store over 1PB of data which would be thousands of dollars monthly even at Glacial cost. Do the "ultra" users weigh down on your margins?
(Obviously with a price that scales with the amount of data stored, "ultra" users wouldn't be a problem on B2.)
If their building catches fire, you're SOL.
The second consequence is that yiu can't choose a data center that is geographically close to you.
That makes B2 unsuitable for off site primary storage for critical data and I wouldn't use it for more than a backup.
That being said, I'm a happy backblaze customer and if I ever get a NAS, I would definitely use B2 as the backend for my backup solution.
Source: I emailed Jeff Barr and asked.
AZs are usually within something like a 50-mile radius, which doesn't get you meteor level separation but does get you fire level separation.
The TL;DR from AWS documentation [1]:
An Availability Zone is represented by a region code followed by a letter identifier; for example, us-east-1a. To ensure that resources are distributed across the Availability Zones for a region, we independently map Availability Zones to identifiers for each account. For example, your Availability Zone us-east-1a might not be the same location as us-east-1a for another account. There's no way for you to coordinate Availability Zones between accounts.
The long and confusing explanation:
At least not in us-east-1 and us-west-1-2, but I am pretty sure many of the large regions are also run in multiple physical facilities.
The so-called availability zone is an abstract and virtual concept. Let us use us-east-1 as an example.
Assume the following:
* Physical DC buildings: Queens, Brooklyn, Manhattan, Staten Island
* AWS accounts: Joe, Alice, Bob
* AZ: us-east-1a, us-east-1b, us-east-1c, and us-east-1d
Every AWS account in us-east-1 region is assigned three AZs. But for sake of this explanation, we assume only two.
* Joe: 1a, 1b
* Alice: 1a, 1b
* Bob: 1a, 1c
You now ask, "WTF?" but you let this go, think this is done for capacity reason. So do we actually have four different physical facilities, one per each AZ? Nope.
So is 1a and 1b in the same facility? Not necessarily, but very possible.
So 1a and 1b in Queens, 1c in Brooklyn, and 1d in Manhattan? Nope.
So what the fuck is AZ? What is the relationship between AZ and physical facility?
Think about virtual memory address space.
Joe's 1a and Bob's 1a are in Queens, but Alice's 1a is in Manhattan. But Joe's 1a and Bob's 1a are on a different floor, different racks, while Joe's 1b and Bob's 1c are in Brooklyn and on the same floor. This is why certain customers run out m3.xlarge in 1a but others don't in their 1a.
In essence, AZ is a label and is unique per account. AZ is very similar how virtual memory address in OS looks like.
We learned this because our EMR failed due to low capacity in one account.
[1]: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-reg...
https://datacenterfrontier.com/inside-amazon-cloud-computing...
"Amazon initially said little about the physical layout of AZs, leaving some customers to whether they might be different data halls within the same facility. The company has since clarified that each availability zone resides in a different building."
“It’s a different data center,” said Hamilton. “We don’t want to run out of AZs, so we add data centers.”
To make this work, the Availability Zones need to be isolated from one another, but close enough for low-latency network connections. Amazon says its zones are typically 1 to 2 milliseconds apart, compared to the 70 milliseconds required to move traffic from New York to Los Angeles.
“We’ve decided to place AZs relatively close together,” said Vogels. “However, they need to be in a different flood zone and a different geographical area, connected to different power grids, to make sure they are truly isolated from one another.”
So, distance of availability zones from each other is limited by speed of light in fiber optics (which is slower than through a vacuum or microwave wireless).
Based on this calculator: http://wintelguy.com/wanlat.html, availability zones can't be more than 0.5-1 miles apart (about) to retain their 1-2 millisecond network latency, so they're different buildings in the same industrial/business park. We could confirm this by pulling permits (public record) in Amazon's (or their subcontractor's) name.
That is not a guarantee. AWS doesn't actually publish more than what I cited (well there are photos of the DC flooding around the Internet). But there are different physical facilities, and they are some miles apart. Like I said above, 1a for Joe and 1a for another customer don't have to be in the same building, or on the same floor.
> If their building catches fire, you're SOL.
We call this the "meteor hits our datacenter" scenario. With the Backblaze Online Backup product, the hope is your laptop isn't hit by the same meteor so you still have a primary copy of the data.
But I'm a HUGE believer in having two lower redundancy backups stored with completely different technology backed up by two separate companies that don't share a single line of code. In two separate locations. For example, make a local copy onto an external USB hard drive, and use Backblaze for a remote copy in case your house burns down. It would also be Ok to put one copy in Amazon S3 and a separate copy in Microsoft Azure, and try to use two separate pieces of software to do each of those backups.
The main reason to use two different companies is in case a bug exists in the backup software. The same bug won't hit both backups at the same time.
Just reading this right now I realized, actually, usually for online services you want to use the server closest to you, but for backup I guess it's the opposite - you want the server that's furthest away from you!