Second, be aware those savings come with some downsides. The major one for us has been their maintenance window every Thursday from 2:00-3:00pm Pacific Time. Usually there's no outage, but sometimes there is. There's no warning - it's just down sometimes during that window. So, if uptime is important for your data, consider the cost of also implementing a fallback solution to cover your production use during those maintenance windows. https://www.backblaze.com/scheduled-maintenance.html
A limitation I ran across when using B2 was that their pre-defined url generation doesn't allow you to set file-size limits nor does it allow you to set the file name in the pre-defined url. It simply gives you a url to upload it to. So if you are using b2 for storage for lets say image uploads from browser, some malicious user has the ability to modify the network request with whatever file name or file size they want. Next thing you know, you have a 5gb sized image uploads happening....
This pretty much prevents me from using B2 for now.
Side question: Apart from this maintenance window, is B2 Cloud reliable? I've heard of problems with the S3 API. Is the "native" API more stable? Would love to know your insight, it will potentially save me a lot of time!
I love B2's free ingress and egress when you use CloudFlare, they utterly destroy the competition on price.
But my true dream would be for backblaze to someday offer ZFS as a service.
I want to `zfs send -i my_pool@2020-03-11 | b2zfs recv some_bucket_id`, then be able to view my snapshots and files within in the backblaze web UI, and restore with `b2zfs send -i some_bucket_id/my_pool@2020-03-11 | zfs recv my_pool`.
You can already mount B2 as a FUSE filesystem with something like ExpanDrive, then write ZFS raw file vdevs to the B2 FUSE mount, but it's horrifically slow and probably too janky for any real use.
Without b2 adding anything zfs specific, that should be possible with a regular large file upload if you can deal with each upload part being buffered in a file/memory locally before upload.
It's interesting because it feels like a small turf war. The "Amazon Provider Team" wants to own the s3 provider backend, and you want to make it pluggable. Is this to avoid an explicit "b2" provider? I can see how it might be confusing to use terraform and see an s3 provider and then have it...not use s3. :)
Also, was there a reason it's not against the B2 API? Not a judgment, just curious about the design tradeoffs in a professional-talking-to-professional sense.
That design choice prevents their provider from working with official Terraform container images. They should make the API calls directly in Go, it's just weird to do it via Python... They have very few resources exposed on their API so it's not like writing a Go client would be all that hard.
> Terraform is an open-source infrastructure as code (IaC) tool
Maybe it was in the beginning, but Terraform is far more powerful than that now. Terraform is a monad that neatly separates pure declarative configuration from the I/O (side effects) that are factored out into providers. Terraform used at its most powerful is not limited to infrastructure, it also sets up the platforms and applications running on that infrastructure for you, by separating the configuration of the platforms and applications from the generic API calls that apply that configuration. Terraform's dependency graph ensures that the calls are made in the right order, no matter if they are made to infrastructure APIs, platform APIs, or APIs belonging to layers further up the stack
For large downloads, does BB support the Range header. If the user is on a connection that that is not suitable for long downloads, could the Range header be used to download a large file in several parts.
Popped in to say backblaze built out a tf provider at our request and they were great about it! Got a quick early build out to test, GA build a few months later and are very responsive to feedback. Pleasure to deal with
I was just looking at this new Terraform provider yesterday how timely. Nice to see the quickstart guide this will be helpful for managing the buckets and application keys.
You could use NixOps[0] for Nix but I'm not sure you can directly compare Terraform and Guix/Nix? My set up involves Terraform for infrastructure and Nix for provisioning, and it's working for me so far.
I think this too, but at the same time the reality is a tool like Terraform is really complicated to implement well, and, importantly, it always has to work. All the time. There are really high standards for this, and in my personal experience, alternative solutions like NixOps don't quite stack up in reliability or broad utility versus Terraform. The design is good in theory, but it needs just a huge amount of work to be trusted.
For the most part, I provision things with Terraform and then instantiate the servers with NixOS/Nix itself, and this mostly works. For bonus points you can use Nix to generate the HCL that Terraform reads in (because Nix can write JSON, and HCL is just JSON in a trenchcoat) if you want to put some veneer on it.
Are there any providers that to have such integration? I have only lightly used nix. Having a hard time understanding what a cloud provider integration would look like.
[+] [-] mattjaynes|5 years ago|reply
First, B2's pricing is pretty amazing, especially compared to S3 and similar competitors: https://www.backblaze.com/b2/cloud-storage-pricing.html
Second, be aware those savings come with some downsides. The major one for us has been their maintenance window every Thursday from 2:00-3:00pm Pacific Time. Usually there's no outage, but sometimes there is. There's no warning - it's just down sometimes during that window. So, if uptime is important for your data, consider the cost of also implementing a fallback solution to cover your production use during those maintenance windows. https://www.backblaze.com/scheduled-maintenance.html
[+] [-] qw3rty01|5 years ago|reply
I mainly only use them for backups instead of production data
EDIT: As of 2019 there are multiple datacenters, but it doesn't seem like the data is stored redundantly across them
[+] [-] busymom0|5 years ago|reply
This pretty much prevents me from using B2 for now.
[+] [-] vishnumohandas|5 years ago|reply
[1]: https://www.backblaze.com/blog/cloud-storage-durability-vs-a...
[2]: https://www.backblaze.com/company/sla.html
[3]: https://aws.amazon.com/s3/sla/
[+] [-] tedmiston|5 years ago|reply
[+] [-] preommr|5 years ago|reply
That seems way cheaper than this.
For backups and large, long term storage, AWS has Glacier, that's really really cheap.
[+] [-] truetraveller|5 years ago|reply
[+] [-] truetraveller|5 years ago|reply
[+] [-] fukmbas|5 years ago|reply
[+] [-] nikisweeting|5 years ago|reply
But my true dream would be for backblaze to someday offer ZFS as a service.
I want to `zfs send -i my_pool@2020-03-11 | b2zfs recv some_bucket_id`, then be able to view my snapshots and files within in the backblaze web UI, and restore with `b2zfs send -i some_bucket_id/my_pool@2020-03-11 | zfs recv my_pool`.
You can already mount B2 as a FUSE filesystem with something like ExpanDrive, then write ZFS raw file vdevs to the B2 FUSE mount, but it's horrifically slow and probably too janky for any real use.
[+] [-] ptomato|5 years ago|reply
[+] [-] mhio|5 years ago|reply
[+] [-] kgog|5 years ago|reply
[+] [-] philsnow|5 years ago|reply
"Backblaze now has a Terraform provider" or "Backblaze released a Terraform provider" makes more sense to me.
[+] [-] OJFord|5 years ago|reply
https://github.com/hashicorp/terraform/issues/27304
[+] [-] javajosh|5 years ago|reply
[+] [-] renewiltord|5 years ago|reply
Do you use a similar technique to https://poweruser.blog/embedding-python-in-go-338c0399f3d5 to embed the Python SDK?
Also, was there a reason it's not against the B2 API? Not a judgment, just curious about the design tradeoffs in a professional-talking-to-professional sense.
[+] [-] AYBABTME|5 years ago|reply
[+] [-] vbsteven|5 years ago|reply
[+] [-] atYevP|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] rattray|5 years ago|reply
[+] [-] solatic|5 years ago|reply
Maybe it was in the beginning, but Terraform is far more powerful than that now. Terraform is a monad that neatly separates pure declarative configuration from the I/O (side effects) that are factored out into providers. Terraform used at its most powerful is not limited to infrastructure, it also sets up the platforms and applications running on that infrastructure for you, by separating the configuration of the platforms and applications from the generic API calls that apply that configuration. Terraform's dependency graph ensures that the calls are made in the right order, no matter if they are made to infrastructure APIs, platform APIs, or APIs belonging to layers further up the stack
[+] [-] 1vuio0pswjnm7|5 years ago|reply
[+] [-] 0xbkt|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] nhoughto|5 years ago|reply
[+] [-] majormjr|5 years ago|reply
[+] [-] atYevP|5 years ago|reply
[+] [-] satyrnein|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] snicker7|5 years ago|reply
[+] [-] ethnt|5 years ago|reply
[0] https://github.com/NixOS/nixops
[+] [-] aseipp|5 years ago|reply
For the most part, I provision things with Terraform and then instantiate the servers with NixOS/Nix itself, and this mostly works. For bonus points you can use Nix to generate the HCL that Terraform reads in (because Nix can write JSON, and HCL is just JSON in a trenchcoat) if you want to put some veneer on it.
[+] [-] emptysongglass|5 years ago|reply
[+] [-] CameronNemo|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]