Tag Archives: Featured

Backblaze, Part of Computer History

Post Syndicated from Yev original https://www.backblaze.com/blog/backblaze-part-of-computer-history/

A decorative image showing a stylized version of the original Storage Pod.

Some innovations change the trajectory of a company, others change the trajectory of an entire industry. Today, I’m absolutely chuffed that one of our original Storage Pods, ul010 to be exact, is heading to the Computer History Museum. Not as a curiosity, but as a piece of living history that changed not just how Backblaze stored data, but how the entire cloud industry thought about server design.

Some history

On September 1, 2009, we published a blog post called Petabytes on a Budget: How to Build Cheap Cloud Storage. The post went into detail about how we, as a bootstrapped company, could provide an unlimited backup service at a reasonable rate without compromising on performance or burning through cash. Essentially, open-sourcing our server design and making it available to the masses was a bit of a gamble given that a better-funded company could copy our design, deploy it at scale, and put us out of business.

Our “secret sauce” has always been our software stack and design decisions, so we felt strongly that while they could mimic some of our economics, being able to build a service as performant as ours would be out of reach. 

At the beginning

Founder Brian Wilson had this to say about some of Backblaze’s history:

The founders of Backblaze were primarily software engineers, and after wiring up some prototypes on Tim’s office desk, we worked with the company Protocase all by email and telephone to have the first actual sheet metal Pod enclosure manufactured. The “custom” part of the Pods is the sheet metal enclosure, for cost reasons all of the components inside the enclosure are standard drives, motherboard, power supplies that you can purchase for consumers.

A photograph of an early Storage Pod prototype.
An early Storage Pod prototype (never in production)

So the sheet metal Pod has screw holes where the computer motherboard sits down and gets attached to the metal enclosure. They have to be precisely in the correct location or the screws wouldn’t line up. I (Brian) thought there was no way we (a bunch of software engineers) could get that all perfectly lined up on the very first prototype. But when we got the very first sheet metal enclosure shipped to our corporate office, every screw hole to mount the drives, backplanes, power supply, and motherboard were in perfect with alignment. However…

We forgot that computers have power buttons! All the complex stuff was correct, but there was no location on the case to have a power button. So Tim jammed a screwdriver in some air vents on the first prototype sheet metal Pod and opened up a hole wide enough for the power button. Below is Tim opening a hole for the Pod’s power button:

A photo of one of the Backblaze founders modifying a Storage Pod prototype.

And with that one modification, the very first sheet metal Pod was deployed in the datacenter and started storing customer data for the next several years, performing flawlessly.

While we’d spend the next decade moving away from the title word “cheap”, the blog post and how we thought about our storage problem struck a chord with enthusiasts, businesses, and the storage industry at large. Our Storage Pod wasn’t just a chassis full of drives, it was proof that infrastructure innovation doesn’t have to come from billion-dollar labs. Sometimes it comes from engineers willing to be cleverly unconventional. 

Innovation across the industry followed. Partially inspired by our architecture and philosophies around solving storage density and interconnectivity issues, the Open Compute Project (2011), and Netflix’s Open Connect (2012) came to life and continue their innovative charters to this day. Protocase, which bent the sheet metal for our original Storage Pod, spun up an entire company, 45 Drives, to meet the “build this for us” demand they were experiencing. As we moved from version 1 to version 6 of our Storage Pods and beyond, we looked on fondly as capital-efficient, high-density 4u servers became commonplace, and commoditized. Today, you can customize your own dense servers from a variety of providers, from 45Drives to Sanmina to Dell.

Why donate the Pod?

One of my favorite places in the Bay Area is the Computer History Museum in Mountain View. Walking through the exhibits, and seeing an old Babbage machine, telecom equipment, and the evolution of electronic gaming was inspiring to me when I first moved to the bay 15 years ago. At Backblaze, we’ve also kept a museum of sorts, originally created by Andy Klein. Our museum consisted of Storage Pods from version 1 all the way to version 6, along with the original RAID array we tested our systems on, and it has been displayed at our office for years.

A photo from the Backblaze Storage Pod museum (now closed).
A photo from the Backblaze Storage Pod museum (now closed).
A photo from the Backblaze Storage Pod museum (now closed).
A photo from the Backblaze Storage Pod museum (now closed).

Backblaze went fully remote in mid-January, and as our museum became destined for storage, I tried to think of other interesting things to do with it, and the Computer History Museum sprang to mind. I reached out and they graciously agreed to consider the original Storage Pod. (I appreciated the kind way in which they declined taking on our entire museum—they have space constraints as well!)

The handoff was a bit of an adventure

I went to our office before it closed up for good to take some pictures and bring the Storage Pod to their ingestion site.

Yev at the Backblaze Storage Pod museum.
The Backblaze Storage Pod getting transported to the Computer History Museum.
The Storage Pod being transported to the Computer History Museum.

I drove to the Shustek Research Archives, which serves as an archive, preservation, and ingestion site for all the historic items bound for the Computer History Museum and its archives. It’s also where the curators do a final yay/nay on whether the items truly are a part of computer history. It was a little bittersweet to drop off the Storage Pod, but knowing it would be going to a nice home felt great.

When Backblaze began in 2007, their goal was to provide unlimited cloud backup storage for $5 a month. Their first product relied on hardware—Storage Pod 1.0—which represented a watershed, defying the era’s proprietary technical norms by using off-the-shelf components and open-source software. By famously sharing their design blueprints with the world, Backblaze also ignited a revolution in ‘open hardware,’ proving that high-density enterprise storage could be built for a fraction of the cost of traditional approaches. We are honored to preserve this original unit.

— Dag Spicer, Senior Curator, Computer History Museum

Yev with the Storage Pod at the Computer History Museum.
The Storage Pod in its new home at the Computer History Museum.

After the handoff, all I could do was wait and see whether the curators felt that our Storage Pod was worthy to be a part of their collection. Less than three weeks later, I got the news that the Pod was accepted and will join the historical relics of the CHM.

A post-Pod world

While our Storage Pod helped democratize storage at a time where the industry was in need, today B2 Cloud Storage with B2 Overdrive and B2 Neo help companies, industries, and builders democratize their tech stacks. And that kind of flexibility will help accelerate them into and past the AI-era. 

Our donated Storage Pod once held backups—data comprising the many aspects of our customer’s lives, stories, and work. And, it’s also a symbol of our stories—the late nights, bold bets, and belief in the innovation that sparked the Backblaze founders in the first place. My sincere hope is that through its retirement at the Computer History Museum, it will inspire the next generation of innovators, and if that’s you…hey, nice to meet you!

The post Backblaze, Part of Computer History appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Managing Backblaze B2 with Claude: Introducing the B2 Cloud Storage Skill for Claude

Post Syndicated from Jeronimo De Leon original https://www.backblaze.com/blog/managing-backblaze-b2-with-claude-introducing-the-b2-cloud-storage-skill-for-claude/

A decorative image showing gears on a cloud.

Modern infrastructure teams increasingly interact with their systems through automation and AI-assisted tooling. Terminal-native agents like Claude Code are beginning to act less like chatbots and more like operational collaborators, able to inspect environments, run commands, and help maintain infrastructure.

Today we’re releasing a new open-source tool designed for that workflow: the Backblaze B2 Cloud Storage Skill for Claude.

This GitHub repository provides a structured skill that allows Claude-based agents to safely interact with Backblaze B2 Cloud Storage through the B2 CLI. Instead of manually running storage audits, searching buckets, or reviewing lifecycle rules, you can ask an AI assistant to help perform those tasks directly in your development environment.

The result is simple and powerful: An open source natural language interface for inspecting and managing B2 Cloud Storage, built with guardrails.

What is the B2 Cloud Storage Skill for Claude?

The B2 Cloud Storage Skill for Claude is an open-source repository that enables AI-assisted management of B2 buckets using the official Backblaze B2 CLI.

The project includes three primary components:

1. A Claude Skill Definition

The skill file provides structured instructions that teach Claude how to safely interact with B2 Cloud Storage. It defines the commands the assistant can use, outlines safe operational practices, and establishes restrictions around sensitive data and destructive actions.

This allows Claude to perform storage operations while respecting operational safeguards.

2. A Storage Audit Script

The repository includes a Python script that analyzes the contents of a bucket and produces a structured report. The audit can:

  • Summarize storage usage by directory prefix
  • Analyze file types and extensions
  • Identify files older than 90 days
  • Flag objects larger than 100MB
  • Detect potential duplicates based on filename

The result is a quick operational snapshot of a bucket’s structure and usage patterns—useful for cost awareness, lifecycle planning, and housekeeping.

The skill supports per-project configuration through a .claude/b2-config.json file. This allows developers to specify a default bucket, a working prefix, or a project-specific credential file.

In practice, that means different repositories or services can point to different storage buckets without changing global CLI configuration.

How to use it

The skill is designed to work in environments where Claude Code or similar agent-based developer tools can execute terminal commands.

A typical workflow looks like this:

  1. Install and configure the B2 CLI.
  2. Authorize the CLI with a B2 application key.
  3. Add the skill repository to your Claude environment.
  4. Optionally configure a project-specific bucket.

Once configured, you can ask Claude to perform storage tasks directly from your terminal.

Examples include:

  • Audit the contents of this bucket.
  • List files older than 90 days.
  • Show the largest objects in this prefix.
  • Check the bucket’s lifecycle rules.
  • Find duplicate filenames across directories.

Under the hood, the assistant is running standard B2 CLI commands and the included audit script. The skill simply provides the structure that allows an AI agent to use those tools correctly.

This approach keeps the operational layer transparent: Everything ultimately resolves to normal CLI commands you can run (and double check) yourself.

Why it matters

Cloud storage environments grow quietly.

Buckets accumulate logs, backups, generated assets, and intermediate files over time. Without periodic inspection, those collections can become difficult to understand or maintain.

Historically, storage audits have been manual exercises: writing scripts, exporting listings, or running ad-hoc commands.

AI-assisted tooling changes that interaction model.

Instead of constructing queries, operators can ask for insights:

  • Where is the storage concentrated?
  • Which files are stale?
  • Are lifecycle policies doing their job?
  • Are there large objects that should be archived or removed?

The B2 Cloud Storage Skill bridges the gap between AI-assisted workflows and real storage infrastructure.

Just as importantly, the repository is designed with safety in mind. The skill restricts commands that could expose credentials, requires dry-runs before deletion operations, and warns when actions could change bucket visibility.

In other words, it treats AI as an operational assistant—not an autonomous administrator.

Open source and extensible

The repository is intentionally lightweight and open.

It’s meant to serve as both a practical tool and a starting point for developers exploring how AI agents can interact with storage infrastructure.

Possible extensions include:

  • Automated lifecycle policy recommendations
  • Deeper storage analytics
  • Integration with monitoring pipelines
  • Custom audit rules for specific workloads

If you’re experimenting with AI-assisted operations—or simply want a faster way to inspect your B2 Cloud Storage—this skill provides a practical place to start.

You can explore the repository and try it yourself here:

https://github.com/backblaze-b2-samples/claude-skill-b2-cloud-storage

The post Managing Backblaze B2 with Claude: Introducing the B2 Cloud Storage Skill for Claude appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Neoclouds Are Winning on Compute. Storage Shouldn’t Slow Them Down.

Post Syndicated from David Johnson original https://www.backblaze.com/blog/neoclouds-are-winning-on-compute-storage-shouldnt-slow-them-down/

A decorative image showing servers, the cloud, and drives.

Neoclouds are having a moment.

As demand for AI infrastructure keeps climbing, a new wave of providers is proving there’s real appetite for something other than the traditional hyperscaler model. They’re moving fast, specializing deeply, and building strong businesses around the layers that matter most to their customers: GPU access, high-performance compute, AI services, and developer experience.

That momentum is real, as is the next bottleneck. For many neoclouds, the challenge is no longer just how to deliver more compute. It’s how to deliver a more complete platform without taking on all the complexity of becoming a full-stack cloud provider. And that usually brings teams to the same question: Sshould we build our own storage layer?

Key points: Why should neoclouds care about specialized storage?

  • Neoclouds are capturing a major market opportunity by specializing in compute, AI, and high-performance infrastructure instead of trying to replicate the hyperscaler model. But without an independent, S3 compatible storage layer, many providers run into a split-stack problem: compute lives on the neocloud while data stays in a major cloud, bringing egress fees, friction, and architectural sprawl.
  • Teams that decide to build storage themselves often underestimate what that really means. Whether the path is open-source software like Ceph or purpose-built hardware, the result is often the same: Slower execution, more operational burden, and less focus on the product that actually differentiates the business.
  • The stronger strategy is to treat storage as a specialized tech stack layer and intentionally partner to solve the need, so internal teams can stay focused on compute, AI services, and customer experience.
  • Backblaze gives neoclouds an S3 compatible object storage backbone that can be integrated quickly, scaled immediately, and delivered without the overhead of building and operating storage from scratch.

The real neocloud opportunity is specialization

The shift toward neoclouds is really a shift toward specialization.

For years, the default assumption in cloud infrastructure was that the winning model looked like a hyperscaler: Build the entire stack, own every layer, and expand horizontally into as many services as possible. That model produced scale, but it also produced operational sprawl, complexity, and costs that many customers are increasingly motivated to avoid.

Neoclouds are succeeding because they’re taking the opposite path. Instead of trying to be everything to everyone, they’re building best-of-breed platforms around targeted workloads and high-value services. That’s especially true in AI, where performance, cost control, and speed matter more than a long menu of loosely related products.

But the closer a neocloud gets to becoming a full platform, the more pressure it faces to solve for storage.

The split-stack problem gets expensive

Without integrated object storage, customers often end up in a split-stack architecture. They run compute on a neocloud, but keep their data parked in a major cloud provider, which creates problems quickly.

For example: Large training datasets, model checkpoints, and output artifacts have to move across environments, costs become harder to predict, egress charges start to shape architecture decisions, and performance can suffer when storage and compute are no longer designed to work together.

At that point, storage becomes a core requirement for offering a platform that feels complete, efficient, and economically viable.

So teams ask the obvious question: should we build it ourselves?

Building storage usually means building a second company inside your company

This is where the conversation often gets framed too narrowly.

On paper, the decision can look straightforward: deploy open-source software such as Ceph, or design purpose-built hardware for tighter control over performance and economics.

In reality, both paths create the same strategic problem. They pull engineering focus away from your core platform and into a long-term storage business you never actually meant to start.

That matters because storage is not just infrastructure. It is an operating discipline. It comes with its own tuning, scaling, durability trade-offs, support burden, procurement risk, migration complexity, and day-two operational entropy.

Once you build it, you own all of it.

The software trap: Ceph is open source, not low overhead

Ceph is often the default option for teams exploring S3 compatible storage because it appears flexible, proven, and relatively accessible on commodity hardware.

And to be clear, Ceph can be powerful. But there’s a big difference between deploying Ceph and running it well at scale.

In production, Ceph demands specialized expertise. Teams have to manage CRUSH maps, OSD tuning, replication behavior, rebalancing events, and the network impact that comes with those changes. Those are not occasional tasks. They are part of the ongoing operational load.

That burden grows as environments get larger and more performance-sensitive.

For AI and high-performance compute use cases, generic Ceph deployments can also become throughput bottlenecks. When storage ceilings start constraining training jobs or data-intensive workflows, the problem is no longer confined to the storage team. It starts affecting the value of your core compute offering.

And migration is rarely simple. Because data is distributed across the cluster in ways that are optimized for internal resilience, moving out of a Ceph environment can become a resource-heavy extraction exercise that introduces risk to live workloads.

So while Ceph may reduce license costs up front, it can create a much more expensive operational reality over time.

The hardware trap: more control, more rigidity

For some neocloud teams, custom storage hardware feels like the more strategic answer.

The logic is easy to understand: if storage is critical, why not optimize the hardware and software stack together and get more predictable performance?

The issue is that custom storage hardware rarely stays clean and predictable for long.

Supply chains change. Drive capacities shift. Components become harder to source consistently. Architectures designed around one hardware profile suddenly have to absorb another. This dynamic can leave teams paying for density they can’t fully use or reworking systems to accommodate equipment that wasn’t part of the original plan.

Durability management adds another layer of complexity. As systems age, parity strategies and erasure coding decisions may need to change to maintain reliability. That can reduce usable capacity, increase cost per terabyte, and trigger compute-intensive re-encoding processes at exactly the wrong time.

Then there’s the networking layer. At scale, object storage is not just disks and nodes. It also depends on a traffic management architecture capable of handling massive ingress and egress flows without introducing opaque failure points. Whether you build around open source components or buy expensive hardware appliances, you’re signing up for another category of highly specialized infrastructure work.

And all of that comes with a capital model that is harder to unwind. Hardware investments lock teams into depreciation cycles and planning assumptions that may not match where the market is headed next.

The strategic shift: own differentiation, not every layer

The most important shift here is not technical. It’s organizational.

At a certain point, the storage question becomes a question of where your best people should spend their time.

Should your engineers be tuning replication policies, planning hardware refreshes, and troubleshooting storage network behavior?

Or should they be improving the platform features your customers actually choose you for?

For most neoclouds, the answer is clear.

Their advantage comes from how well they deliver compute, how quickly they adapt to AI demand, how smooth their developer experience feels, and how effectively they help customers run modern workloads. That is where focus compounds. That is where differentiation lives.

Storage matters enormously, but that does not mean it has to be built in-house.

Storage works better as a specialized utility

The neocloud ecosystem works best when providers can connect to open, specialized layers instead of rebuilding the entire stack themselves.

When storage is treated as a utility rather than an internal R&D project, teams can move faster and stay aligned with what the business actually needs. They avoid procurement cycles, reduce operational overhead, and eliminate a category of complexity that would otherwise keep expanding over time.

Equally importantly, they can offer customers a more complete and coherent platform without forcing data to remain trapped in legacy cloud environments.

How Backblaze helps neoclouds move faster

Backblaze gives neoclouds an independent, S3-compatible object storage backbone that can plug into existing compute, AI, and container workflows without requiring a storage buildout from scratch.

That means teams can:

  • Integrate with existing tooling: Use a drop-in, API-compatible storage layer that works with existing workflows, SDKs, CLIs, and infrastructure tools.
  • Reduce operational burden: Offload the complexity of durability engineering, bit-rot protection, fleet management, and storage operations.
  • Avoid punitive egress economics: In Backblaze-powered and colocated partner environments, move data between compute and storage without the cost friction that often comes with major cloud architectures.
  • Scale immediately: Go from terabytes to exabytes without waiting on hardware procurement, deployment schedules, or expansion projects.
  • Keep teams focused: Direct engineering effort toward the product roadmap instead of a second internal storage program.

Backblaze also brings the underlying scale and performance neoclouds need to support modern AI and data-intensive workloads, including up to 1Tbps aggregate throughput, 11 nines of annual durability, a 99.9% uptime SLA, and enterprise security and compliance capabilities.

Build what matters

Neoclouds are winning because they know where to specialize.

That focus is their strength. It is also their opportunity.

The fastest path to a stronger platform is not to recreate every layer of the cloud stack. It is to build the parts that make your business distinct, then connect them to the right partners for the rest.

Storage is too important to ignore, but it is also too easy to underestimate.

If you want to move faster, serve customers better, and keep your roadmap centered on what makes your platform valuable, don’t turn storage into a distraction.

Build what matters. Let Backblaze handle the storage.Interested in learning how Backblaze supports neocloud platforms? Explore B2 Neo or talk with our team about building a more open, AI-ready storage architecture.

The post Neoclouds Are Winning on Compute. Storage Shouldn’t Slow Them Down. appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Backblaze Pricing and Product Updates

Post Syndicated from Backblaze original https://www.backblaze.com/blog/backblaze-pricing-and-product-updates/

A decorative image showing the Backblaze logo on a cloud. A title reads Product Updates and Upgrades

As our customers scale larger AI workloads, build increasingly data-intensive applications, power more complex media workflows, and demand faster recovery times, we continue to invest in performance, infrastructure, and features to support them.

Today, we’re announcing updates to B2 Cloud Storage pricing and APIs that reflect those investments and reinforce our long-standing commitment to straightforward pricing and open cloud freedom.

Price updates

  • Free API calls: Effective May 1, we’re making API calls free for all B2 Cloud Storage customers.* This removes transaction costs and makes it easier to build, scale, and run high-volume workloads subject to our standard platform usage rules and Terms of Service.
  • Storage price: Also effective May 1, we are updating pricing from $6/TB to $6.95/TB.

Things that aren’t changing

Pricing on existing committed contracts will not change until renewal, and pricing for B2 Overdrive and B2 Reserve will remain the same. Also not changing: 3x free egress for all B2 customers and unlimited free egress between Backblaze B2 and many leading neoclouds, content delivery network (CDN) and compute partners. Our commitment to transparent, predictable pricing remains unchanged.

Why the changes for B2 Cloud Storage?

1. Continuing to deliver high-performance, cost-effective cloud storage

Backblaze B2 has long been the simplest and most cost-effective alternative to legacy cloud providers. That value proposition hasn’t changed.

Behind the scenes, however, we continuously invest in infrastructure capacity, durability, performance improvements, security enhancements, and product innovation to support increasingly demanding workloads, especially AI training, large-scale media processing, and application data at scale.

This pricing update allows us to continue making those investments while maintaining the simplicity and cost advantage our customers rely on.

2. Doubling down on openness and predictability

One of the biggest reasons customers choose B2 Cloud Storage is freedom: 

  • Freedom from surprise bills
  • Freedom from punitive egress fees
  • Freedom from vendor lock-in

By making API calls free for all customers*, we’re removing another layer of billing complexity and friction. Customers can build, iterate, and scale without worrying about transaction costs adding up in the background.

Cloud storage should enable innovation, not penalize it at the moment of success.

3. Why eliminate API charges now?

As workloads like AI training, media pipelines, and high-frequency application access grow, API activity increases. Removing API charges simplifies billing and ensures customers can innovate without worrying about transaction-level costs.

Thank you

We know you have a lot of choices when it comes to cloud storage. The trust you place in Backblaze to safeguard and power your data is something we never take lightly.

Our goal is to be a long-term partner in helping you build, protect, and scale your business. These updates ensure we can continue investing in performance, reliability, and simplicity for years to come.

Thank you for choosing Backblaze and for being part of our community. We’re honored to support the work you’re building.

*Fees apply for the Event Notifications feature as part of that specific offering.

FAQ

Am I affected by this B2 Cloud Storage pricing update?

The storage price increase applies to pay-as-you-go B2 Cloud Storage customers beginning on May 1. Existing committed contracts stay the same until renewal time. New committed contracts will start at $6.95/TB. Pricing for B2 Reserve and B2 Overdrive will remain the same.

When will I, as an existing B2 Cloud Storage pay-as-you-go customer, see this update in my monthly bill?

The updated rate will apply to storage usage beginning on May 1 and will be reflected in your next billing cycle after that date.

Are API calls now completely free?

Beginning May 1, all standard API calls for B2 Cloud Storage are free for all customers except transactions related to a product or features with a different price point. As of this publishing, the only transactions in this category are related to our Event Notifications feature.

Will Backblaze continue to offer unlimited free egress to neocloud, CDN and compute partners?

Yes. Unlimited free egress to approved neocloud, CDN, and compute partners remains unchanged.

Is Backblaze still much more affordable than other cloud providers like AWS?

Yes. B2 Cloud Storage remains substantially more affordable than traditional cloud providers, particularly when factoring in API fees, egress policies, and predictable pricing—often one-fifth the price.

Are you introducing minimum storage duration fees or other hidden charges?

No. Unlike some competitors, we are not introducing minimum storage duration fees or new complexity into our pricing model. Our commitment to straightforward pricing remains the same.

Will this impact performance, durability, or SLAs?

No changes are being made to durability or availability commitments. We continue to offer an SLA of 99.9% uptime and design for 11 9’s durability.

What sort of improvements do you plan alongside the increase in pricing?

We continue investing in performance optimizations, partner integrations, security enhancements, and features that support AI, media, backup, and application workloads. Stay tuned for upcoming announcements.

The post Backblaze Pricing and Product Updates appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

How Neocloud Alliances Reduce the Internet’s Largest Single Point of Failure

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/how-neocloud-alliances-reduce-the-internets-largest-single-point-of-failure/

A decorative image showing several columns on a gradient background.

When AWS’s us-east-1 region went down for over 15 hours on October 20, 2025, the cascade of failures exposed just how fragile the internet’s infrastructure has become. Major services like Discord, Slack, Atlassian, and parts of Netflix suddenly went dark. These companies weren’t all direct AWS customers, but the vendors they relied on were. Authentication systems failed. CDNs stopped responding. Monitoring tools went blind. Companies that thought they’d diversified their cloud strategy discovered their backups were just as offline as their primary systems.

This was far from an isolated incident. CrowdStrike’s faulty update took down 8.5 million Windows machines in July 2024. Microsoft Azure suffered multiple regional outages throughout 2024 and 2025 affecting Office 365, Teams, and Azure DevOps. The pattern is clear: As more of the internet’s critical infrastructure consolidates onto a handful of hyperscale providers, the blast radius of any single failure grows exponentially.

The solutions organizations thought they’d implemented, like multi-cloud deployments, redundant architectures, and disaster recovery plans, often provide little more than the illusion of protection.

The illusion of diversification

A company migrates its primary compute workload from AWS to Google Cloud or Azure, checks the “multi-cloud” box, and considers the job done. But authentication still runs through AWS Cognito. The CDN is CloudFront. Monitoring lives in CloudWatch. DNS resolution depends on Route 53. When AWS’s control plane fails, the entire architecture collapses regardless of where the compute actually runs.

ThousandEyes documented exactly this pattern during the October 2025 AWS outage. Packet loss and routing instability affected direct AWS customers and cascaded into dependent networks and services that appeared independent on paper, but shared the same regional infrastructure under the hood. Organizations often discover these dependencies only during outages, when it’s too late to do anything about them.

Why concentration accelerates despite known risks

Everyone knows concentration is dangerous, yet it keeps accelerating. The same forces that make hyperscalers attractive—operational simplicity, unified tooling, procurement efficiency—concentrate risk faster than diversification efforts can mitigate it.

Teams often adopt unified tooling for operational simplicity, which reduces integration costs and builds vendor-specific expertise. As more systems integrate with that tooling, switching costs increase. Eventually, the platform becomes the default rather than a choice. Each new service added to the stack makes it harder to leave.

Hyperscaler architecture isn’t just a risk, it’s a cost

Amplify’s AWS egress fees were growing to 10x their storage costs as customers downloaded more datasets. CTO Ameya Pathare evaluated Azure, Google Cloud, Digital Ocean, and Wasabi before building a modular architecture: Snowflake for data transformation and Backblaze B2 for staging, with outputs available across Google BigQuery and Tableau.

The two-week migration with zero downtime delivered 70% cost savings that compound with every download. When individual providers experience issues, customers maintain access through alternative paths. “If we had stayed on AWS, we’d have needed to change our pricing and pass on those egress fees to the customer,” Pathare says.

Diversification efforts lag behind because they require deliberate architectural decisions that run counter to operational efficiency. According to the CNCF’s 2025 State of Cloud report, 30% of organizations deploy to hybrid cloud environments and 23% to multi-cloud. That sounds encouraging until you look at what they’re actually distributing. Most organizations spread their compute across providers while consolidating authentication, orchestration, and monitoring with a single vendor. Deployment location differs from dependency structure.

Gartner projects that 90% of organizations will adopt hybrid cloud approaches by 2027. But without intentional failure domain separation, these deployments maintain the same concentrated dependencies they’re meant to avoid.

Why untested recovery paths fail

Most organizations treat failover mechanisms like insurance policies: pay the premium, file the documentation, and hope you never need to use it. Then an outage hits and they discover their recovery paths don’t actually work.

Google’s SRE team analyzed this pattern in their twenty-year retrospective: “Recovery mechanisms that are not tested before an incident routinely fail when they are needed most.” Configuration drift makes systems behave differently in production than they did in testing. Teams encounter unfamiliar tooling under pressure. Communication systems fail because they rely on the same infrastructure that’s down.

Three practices separate resilient systems from brittle ones:

  • Explicit failure domain mapping: Document which components fail together, including indirect dependencies. During Google’s 2017 OAuth incident, teams assumed Hangouts and Meet would remain available for coordination during the recovery. Both services relied on the failing authentication system.
  • Continuous exercised recovery: Failover paths tested regularly rather than only during incidents. YouTube’s 2016 caching failure required risky load-shedding operations that had never been practiced outside staging environments.
  • Graceful degradation by design: Systems intentionally reduce functionality rather than collapse completely. Without this capability built in and tested, systems crash entirely instead of slowing down when they encounter partial failures.

Most organizations implement sophisticated monitoring and alerting but lack tested mechanisms to act on that information when infrastructure degrades.

How modular infrastructure reduces risk

Resilient architectures break infrastructure into interoperable components from specialized providers. Organizations can select compute, storage, networking, and delivery independently based on performance and reliability characteristics. A disruption in one layer no longer automatically incapacitates the entire system.

Cloudflare’s October 30, 2023 incident demonstrates what happens when this separation doesn’t exist. A deployment misconfiguration propagated across tightly coupled internal services. Workers KV became unreachable, which cascaded into failures across Pages, Access, Zero Trust, Images, and the Cloudflare Dashboard itself. Shared tooling and control systems collapsed multiple services into a single failure domain, even within a provider marketed as redundant.

Sardius Media demonstrates what modular cloud infrastructure looks like in practice. The company architected its system from inception to be cloud-agnostic, using a race algorithm that queries multiple cloud providers and CDNs for every API call and selects the fastest response. True resilience through competitive redundancy.

The data layer as a gating factor

Storage architecture determines whether all this architectural planning actually works. Can your data move when you need it to? The answer depends on whether systems can replicate and recover across providers under real-world conditions.

Control-plane access matters more than data replication. During Google Cloud’s June 2025 API misconfiguration, Gmail, Spotify, and Cloudflare went dark despite having intact data layers. Replication across availability zones provided no protection when authentication and API access failed.

Three technical barriers trap workloads in place: 

  • Large dataset transfer costs make migration prohibitively expensive. 
  • Proprietary vendor APIs create application lock-in that requires substantial refactoring to escape. 
  • Unpredictable egress charges turn what was supposed to be a temporary deployment into permanent infrastructure because moving the data out costs more than leaving it there.

Storage architectures that support open APIs, predictable pricing, and cross-provider replication enable genuine mobility. Systems can replicate data across providers, recover faster from incidents through parallel data access, and maintain portable compute and delivery layers. Implementation requires mapping both direct dependencies (compute, storage, CDN) and indirect ones (managed services that converge on the same infrastructure), then assigning explicit recovery requirements to critical workloads.

From scattered clouds to a united front

The internet’s reliability challenges stem from correlated dependencies rather than cloud technology. Neocloud ecosystems make resilient architectures achievable by promoting specialization and interoperability. 

Organizations can select best-of-breed providers for each infrastructure layer—compute, storage, networking, delivery—without forcing everything through a single vendor’s control plane. Open cloud storage ensures those ecosystems remain flexible under pressure, with data that can replicate across providers, portable applications that aren’t locked into proprietary APIs, and predictable costs that don’t trap workloads in place.

The result is systems that continue operating when individual providers fail. They’ve ensured that failures remain isolated rather than cascading across the entire architecture.

The post How Neocloud Alliances Reduce the Internet’s Largest Single Point of Failure appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Back Up Your Entire OpenClaw State to Backblaze B2

Post Syndicated from Jeronimo De Leon original https://www.backblaze.com/blog/back-up-your-entire-openclaw-state-to-backblaze-b2/

A decorative image showing a series of 0s and 1s.

There’s a new open-source plugin that snapshots your OpenClaw config, memory, and sessions to B2. It’s designed to be as simple as possible: Three fields to configure. Rollback from chat. Migrate to a new machine in one restart. 

Let’s get into how and why you might want to use it.

OpenClaw keeps everything local. That’s great until it isn’t.

Your config, sessions, memory databases, hooks, cron jobs—everything that makes your OpenClaw instance yours lives on one machine with no built-in redundancy. Compaction can rewrite session transcripts and cause memory loss. A bad config edit or an accidental deletion means rebuilding from scratch: re-onboarding channels, re-pairing devices, re-teaching your agent who you are.

openclaw-b2-backup adds automatic encrypted backups to Backblaze B2 without changing how you use OpenClaw.

Three fields and you’re done

Setup is intentionally minimal:

openclaw plugins install openclaw-b2-backup

Then open ~/.openclaw/openclaw.json and add your B2 credentials to the entry the installer created:

{
"openclaw-b2-backup": {
"enabled": true,
"config": {
"keyId": "004a...",
"applicationKey": "K004...",
"bucket": "my-openclaw-backups"
}
}
}

Restart the gateway, and you’re done. Region is auto-detected from your application key. Encryption is on by default. The first backup runs at midnight, and then daily after that. You can change the schedule to weekly or any cron expression you like.

Free tier friendly: Backblaze B2 includes 10GB of free storage. A typical OpenClaw state directory is 50–500 MB, so even with 10 encrypted snapshots retained, you’ll comfortably stay within the free tier.

Backups that actually happen

The hardest part of any backup system is remembering to run it. This plugin takes care of that with multiple automatic triggers:

  • A daily cron job (configurable) runs a full incremental push at midnight. 
  • Every time you shut down the gateway, a final push runs before exit—so you always have a snapshot of your latest state. 
  • And, before compaction fires (the thing that rewrites your session transcripts and can cause memory loss), the plugin automatically pushes a snapshot. That last one is the one you’ll be most grateful for.

There’s a 5-minute debounce on the compaction trigger, so rapid-fire compactions don’t queue up a dozen pushes.

Rolling back from chat

The plugin registers a b2_rollback tool with your agent, which means you can manage backups conversationally. Just tell your agent:

“Show me my B2 backup snapshots”

And it’ll list all available snapshots with timestamps. To restore one:

“Roll back to the snapshot from before compaction”Before any restore, the plugin automatically creates a safety snapshot of your current state. Safety snapshots are stored separately and never auto-pruned, so you can always recover from a bad rollback. It’s an undo for your undo.

Moving to a new machine

This was one of the most requested use cases: Getting your entire OpenClaw setup onto a new machine without manually copying files and hoping you got everything.

Install the plugin on your new machine, add the same B2 credentials, and restart. The plugin detects the empty state directory, finds your existing snapshots in B2, and automatically restores the latest one. Same memory, same sessions, same config, same personality. No manual file copying.

openclaw plugins install openclaw-b2-backup
# Add your B2 config to openclaw.json
openclaw gateway restart
# Plugin detects empty state + existing snapshots → auto-restores latest

Security by default

Everything is AES-256-GCM encrypted before it leaves your machine. Each file gets a random salt and IV, so identical files produce different ciphertext. The encryption key is derived from your B2 application key via scrypt—no separate key to manage or lose.

Manifests (which contain only file paths and SHA-256 hashes) stay unencrypted so incremental diffing works regardless of encryption. Credentials and auth profiles are excluded from sync by design—secrets stay per-machine, and you re-auth on new machines.

Best practice: Use a B2 application key scoped to a single bucket for least-privilege access. The plugin works perfectly with bucket-scoped keys—region is auto-detected from the authorize response.

Zero external dependencies

The plugin has no external runtime dependencies beyond croner for scheduling. The B2 client is a hand-rolled AWS Signature V4 implementation using only node:crypto. No AWS SDK, no S3 library, no heavyweight dependencies to audit or keep updated.

It runs entirely inside the gateway process—no external scripts, no separate cron daemon, no stopping the gateway to take backups.

Get started

The plugin is open source (under the MIT license) and available now:

openclaw plugins install openclaw-b2-backup

Source code and full documentation: github.com/backblaze-b2-samples/openclaw-b2-sync-backup

npm package: npmjs.com/package/openclaw-b2-backup

If you run into issues or have feature requests, open an issue on GitHub. And if this plugin saves you from a rebuild, we’d love to hear about it.

The post Back Up Your Entire OpenClaw State to Backblaze B2 appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Advanced Installer and Backblaze Command Line Interface (CLI): More Control for IT

Post Syndicated from Natasha Rabinov original https://www.backblaze.com/blog/advanced-installer-and-backblaze-command-line-interface-cli-more-control-for-it/

A decorative image showing a cloud, a computer, and other digital elements.

Backblaze Computer Backup is designed to be simple: install it, and it runs in the background protecting data. For many businesses, that’s enough. 

But, IT teams managing large deployments asked for more control over how backup is configured across their environments. We are now introducing two new tools built specifically for that need: Advanced Installer and the Backblaze Command Line Interface, bzcli.

What it does

The Advanced Installer gives IT teams a way to preconfigure and lock down certain client settings during rollout. That means when Backblaze is installed on an employee’s machine, it already has the company’s preferred settings in place—no need for end users to make adjustments.

Admins can:

  • Lock schedules so backups always run at the right time.
  • Manage exclusions centrally, avoiding the risk of someone skipping important folders.
  • Control security preferences to keep things consistent across the organization.
  • Suppress non-essential desktop notifications.

Instead of configuring machines individually or correcting settings after deployment, IT teams can define standards once and apply them consistently.

For organizations that frequently onboard employees, manage distributed teams, or provide backup as part of a managed service, this reduces variability and support overhead.

The Advanced Installer integrates with common deployment tools such as Jamf, Kandji, Addigy and other MDM/RMM platforms.

Bzcli: Remote configuration and reporting for RMM environments

In addition to the Advanced Installer, Backblaze Computer Backup will have access to bzcli, a new command-line interface designed for enterprise IT teams using RMM and MDM platforms.

Until now, Backblaze’s command-line support focused primarily on installation. Once deployed, there wasn’t a structured way for administrators to modify configuration settings or retrieve information remotely through automation tools. Bzcli addresses that gap.

Configure after installation

With bzcli, administrators can update client configuration settings after deployment using a structured JSON input file.

It supports the same settings available through the Advanced Installer and Preferences interface, including:

  • Backup schedules
  • Exclusions
  • Network controls
  • Security-related preferences
  • Notification behavior

This allows IT teams to adjust policies centrally without requiring user interaction.

Designed for automation

Bzcli uses a command-based structure (for example, bzcli configure and bzcli report) with clear flags and predictable output. It’s designed to work cleanly within scripts and automation workflows.
The tool is cross-platform and included as part of the standard client installation on both Mac and Windows. It is intended to support environments using tools such as Jamf, Kandji, Addigy, and Microsoft Intune.

Why it matters

As organizations grow, consistency becomes more important. Backup policies need to be enforced reliably. Configuration drift creates risk. Unnecessary notifications create noise.

Advanced Installer and bzcli are designed to reduce that friction.

IT teams can define standards once, apply them consistently, and adjust them when needed, without manual intervention on individual machines.

For teams responsible for protecting company data across large environments, that added control makes deployment more predictable and ongoing management simpler.

Get started with a free 14-day trial of Backblaze Computer Backup today. Or, contact our Sales team to talk about your enterprise deployment today. 

The post Advanced Installer and Backblaze Command Line Interface (CLI): More Control for IT appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Announcing B2 Neo: The Solution for the Neocloud Storage Problem

Post Syndicated from David Johnson original https://www.backblaze.com/blog/announcing-b2-neo-the-storage-problem-neoclouds-dont-talk-about/

A decorative image with a colorful gradient and the words "Backblaze B2 Neo."

Every neocloud in the market right now is winning or losing on the same battlefield: GPUs. Availability, performance, price per hour. That’s the game, and it’s the right game to play. 

But there’s a problem compounding underneath it, one that doesn’t show up in benchmark reports or investor decks, and one that customers will eventually force platforms to confront—neoclouds need highly available, performant storage so that GPUs are never waiting on data. 

Neocloud customers need more than compute

Cloud storage isn’t adjacent to what neoclouds sell—for buyers, it’s the difference between a complete platform and a partial one. Neocloud customers need:

  • Somewhere to put a 10PB training dataset before it touches WEKA, VAST, or DDN boxes
  • Persistent storage for model checkpoints between training runs
  • A place for production inference pipelines to pull weights from at scale, fast enough that GPU nodes aren’t sitting idle waiting on data

Most platforms know this. The ones that are honest about it will also tell what happened when they tried to solve it: Engineering sprints planned around storage tooling that competed directly with GPU roadmap work. Ops overhead for infrastructure that customers take for granted when it’s working and blame the platform for when it’s not. Capital allocated to storage hardware and the teams to manage it.

The platforms that figured this out first didn’t hire their way through the problem. They stopped building storage and started shipping it.

Introducing B2 Neo

That’s the insight behind Backblaze B2 Neo. We built it in direct collaboration with the neocloud operators already utilizing Backlaze in production. The result is a white label cloud storage backbone that neoclouds can launch as a native extension of their platform. Here’s what that means in practice:

  • Up to 1Tbps throughput: Storage that keeps GPU clusters fed and AI workflows moving without becoming the bottleneck.
  • Launch under your own brand: Branded endpoints, partner-controlled pricing, and a native customer experience that keeps the platform front and center.
  • API-driven provisioning: Provision accounts, manage permissions, and handle billing through existing platform tools without a separate console or manual setup.
  • 17 years of operational maturity and exabyte scale expertise: Enterprise durability and reliability that customers expect, operated by Backblaze so internal teams don’t have to.

It doesn’t require a storage team. It doesn’t compete with the GPU roadmap. And it doesn’t route customers away from neocloud platforms where their workflows slowly migrate away.

Already in production with leading platforms

Multiple neoclouds are already using B2 Neo. It’s infrastructure that’s already handling AI training workloads, high performance compute (HPC) pipelines, and media delivery at scale and the platforms already running it are direct about why they made the call. 

One global edge services platform, after a rigorous technical and business evaluation, put it this way: Their customers were demanding cost-effective yet performant storage as their AI business scaled and Backblaze gave them the ability to deliver cloud object storage as a native extension of their own platform without taking focus away from their roadmap. 

Rob Strechay, Principal Analyst at Smuget & theCUBE Research, framed it simply:

With B2 Neo as a first-party service offering to neoclouds, I see the advantage for those organizations of being able to turn on cloud storage without the toil and expense of building it themselves. It is a near-instant value-add offering, helping their customers control costs and achieve the ROI of AI faster.

The question for the rest of the market is how many more quarters of DIY storage ops—or hyperscaler dependency—they can absorb while competitors ship that outcome instead.

B2 Neo is available now. If you’re building a neocloud and storage is either a distraction or a gap, I’d encourage you to talk to us.

The post Announcing B2 Neo: The Solution for the Neocloud Storage Problem appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Introducing the Backblaze Flamethrower Startup Program

Post Syndicated from Stephanie Doyle original https://www.backblaze.com/blog/introducing-the-backblaze-flamethrower-startup-program/

A decorative image showing cogs and cubes with digital lines.

The Backblaze Flameflower Startup Program is here, and it’s built by people who’ve been burned before (and that’s a good thing for you). 

Startups don’t fail because they pick the wrong cloud storage provider.

They fail because everything else is already hard enough, and infrastructure quietly becomes the thing that slows them down, surprises them, or blows up their budget at exactly the wrong moment.

That’s why we’re launching Flamethrower, the new startup program from Backblaze.

It’s not a gimmick. It’s not a lead trap. And it definitely doesn’t bring the “here’s some credits, good luck” energy.

Flamethrower exists for one simple reason: Founders deserve storage infrastructure that helps them move faster, not learn expensive lessons the hard way.

Why Flamethrower exists

Why Flamethrower? 

Startups don’t need more friction, they need a way through it. Metaphor-wise, flames have always been a part of Backblaze’s DNA, and we want this program to speak to the strongest parts of that fire: speed when you need it, reliability when it counts, and power to scale without drama. 

Flamethrower takes these ideas and applies it directly to startups, burning away the biggest blockers between you and your next milestone.

I’ve spent most of my career in and around startups, as a founder, an operator, a partner, a mentor, and occasionally as the person explaining to a CFO why last month’s cloud bill looked like a typo.

I’ve seen the pattern repeat over and over:

  • Early teams optimize for speed (correct)
  • Infrastructure decisions get made quickly (also correct)
  • Those decisions quietly become very sticky
  • And later… someone realizes storage costs are now a board-level discussion

Flamethrower is designed to meet teams before that moment, making your architecture deliberate, not accidental.

Not with abstract promises, but with:

  • Real infrastructure used in real production environments
  • Credits that actually help you get to product-market fit
  • And access to real, live humans who understand what it’s like to build under pressure

This program was built by founders, for founders, including a lot of hard-earned lessons from what doesn’t work.

What makes Flamethrower different

There are plenty of startup programs out there. Many are well-intentioned. Some are very good at marketing. A few are genuinely useful.

Flamethrower is focused on a few things we think matter more than buzzwords:

Human interaction (Yes, really)

Your application is reviewed by real people. Your emails are read by real people.

And if you want to talk to someone, you’ll talk to someone who understands startups, architectures, and workflows, not a generic support queue.

Infrastructure that scales with you

Backblaze B2 is simple, predictable, and S3 compatible. Teams use it for:

In other words: the boring stuff that absolutely has to work.

A program that respects your time

No mandatory demos. No surprise sales motions. No pressure to “convert” before you’re ready.

If Flamethrower helps you build faster—great.

If it doesn’t—that’s okay too, we’ll handle the boring bits until your rocket ship takes off.

Why Backblaze

Backblaze has always had a bit of a different personality.

We believe:

  • Pricing should be understandable
  • Infrastructure should behave predictably
  • Documentation should be written by people who actually use the product
  • And success shouldn’t be punished with surprise bills

That mindset is exactly why Flamethrower fits here.

This isn’t a side project. It’s an extension of how Backblaze already works with developers and builders, just with a little more gas on the fire (if you will).

A bit about me

If we haven’t met yet: I’m James, and I lead Startups and Developer Relations at Backblaze.

I’ve spent years building and running startup programs, developer ecosystems, partnerships, and learning, sometimes painfully, what not to do. I’ve been on the receiving end of “exciting programs” that turned out to be mostly slide decks.

Flamethrower is my attempt (with a very smart team) to build the kind of program I wish existed when I was earlier in my career: practical, honest, and actually useful.

No heroics. No silver bullets. Just support where it counts.

What happens next

The Flamethrower Program is officially live!

If you’re:

  • A founder building something data-heavy
  • An early team thinking about long-term infrastructure
  • Or someone who just wants storage to be the least cumbersome (and most strategic) part of their stack

We’d love to hear from you.

  • Learn more and apply to Flamethrower
  • Or just explore Backblaze on your own terms.
  • Sign up for the Developer newsletter to stay up-to-date with news about the platform and other peoples’ cool projects. 

And if nothing else, thanks for building things. The world needs more people who do.

The post Introducing the Backblaze Flamethrower Startup Program appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Amazon EC2 Hpc8a Instances powered by 5th Gen AMD EPYC processors are now available

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/amazon-ec2-hpc8a-instances-powered-by-5th-gen-amd-epyc-processors-are-now-available/

Today, we’re announcing the general availability of Amazon Elastic Compute Cloud (Amazon EC2) Hpc8a instances, a new high performance computing (HPC) optimized instance type powered by latest 5th Generation AMD EPYC processors with a maximum frequency of up to 4.5 GHz. These instances are ideal for compute-intensive tightly coupled HPC workloads, including computational fluid dynamics, simulations for faster design iterations, high-resolution weather modeling within tight operational windows, and complex crash simulations that require rapid time-to-results.

The new Hpc8a instances deliver up to 40% higher performance, 42% greater memory bandwidth, and up to 25% better price-performance compared to previous generation Hpc7a instances. Customers benefit from the high core density, memory bandwidth, and low-latency networking that helped them scale efficiently and reduce job completion times for their compute-intensive simulation workloads.

Hpc8a instances
Hpc8a instances are available with 192 cores, 768 GiB memory, and 300 Gbps Elastic Fabric Adapter (EFA) networking to run applications requiring high levels of inter node communications at scale.

Instance Name Physical Cores Memory (Gib) EFA Network Bandwidth (Gbps) Network Bandwidth (Gbps) Attached Storage
Hpc8a.96xlarge 192 768 Up to 300 75 EBS Only

Hpc8a instances are available in a single 96xlarge size with a 1:4 core-to-memory ratio. You will have the capability to right size based on HPC workload requirements by customizing the number of cores needed at launch instances. These instances also use sixth-generation AWS Nitro cards, which offload CPU virtualization, storage, and networking functions to dedicated hardware and software, enhancing performance and security for your workloads.

You can use Hpc8a instances with AWS ParallelCluster and AWS Parallel Computing Service (AWS PCS) to simplify workload submission and cluster creation and Amazon FSx for Lustre for sub-millisecond latencies and up to hundreds of gigabytes per second of throughput for storage. To achieve the best performance for HPC workloads, these instances have Simultaneous Multithreading (SMT) disabled.

Now available
Amazon EC2 Hpc8a instances are now available in US East (Ohio) and Europe (Stockholm) AWS Regions. For Regional availability and a future roadmap, search the instance type in the CloudFormation resources tab of AWS Capabilities by Region.

You can purchase these instances as On-Demand Instances and Savings Plan. To learn more, visit the Amazon EC2 Pricing page.

Give Hpc8a instances a try in the Amazon EC2 console. To learn more, visit the Amazon EC2 Hpc8a instances page and send feedback to AWS re:Post for EC2 or through your usual AWS Support contacts.

— Channy

Backblaze Drive Stats for 2025

Post Syndicated from Drive Stats Team original https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/

A decorative header showing hard drives with the title 2025 Year-End Report Drive Stats.

This year marks 13 years of collecting Drive Stats data. Thirteen is an unlucky number (to some), but we count our lucky stars (or perhaps our lucky stats?) that we’ve had 13 years of this experiment. 

The traditional 13-year anniversary gift is lace—intricate, impressive, and vulnerable to a snag if you don’t plan ahead to protect the pattern. Systems, like lace, don’t survive by pretending there are no points of vulnerability. When it comes to our infrastructure, we want to build with the snags in mind to create something durable, and the Drive Stats series is always seeking to publish and provide data so that you, too, can go the distance with your drives. 

This year-end Drive Stats report looks at Q4 2025, the full year, and the lifetime view with that in mind. I think you’ll find the same things we do: over time, the patterns matter more than any single strand (or drive, to run this lace metaphor into the ground once and for all). Let’s look at the stats. 

Drive Stats is here for you

Drive Stats is not a situationship. We’re a conversation and a relationship—to the data. Join the Drive Stats team for our regularly scheduled webinar to walk through the 2025 annualized failure rates, break down the data for interesting trends, and get the latest from the Backblaze drive fleet happenings.

Once More With Feeling

Drive Stats: The digest version

A summary infographic showing the Q4 2025, annual, and lifetime hard drive failure rates.

Q4 2025 hard drive failure rates

As of the end of 2025, Backblaze was monitoring 341,664 drives used to store data. For our evaluation, we removed from consideration 4,013 boot drives and 459 hard drives, as they did not meet the criteria to be included. We’ll discuss the criteria we used in the next section of this report. Removing these drives leaves us with 337,192 hard drives to analyze. The table below shows the annualized failure rates for Q4 2025 for this collection of drives.

Backblaze Hard Drive Failure Rates for Q4 2025

Reporting period October 1, 2025–December 31, 2025 inclusive
Drive models with drive count > 100 as of December 31, 2025 and drive days > 10,000 in Q4 2025.

Note and observations

  • New drives!
    • Seagate ST16000NM000J 16TB, with 112 drives
    • WDC WUH722626ALE6L4 26TB with 1,201 drives. Our first 26TB drive! 
  • The honor roll:
    • HGST HMS5C4040BLE640 4TB: 1 failure 
    • Seagate ST8000NM000A 8TB: 0 failure 
    • Seagate ST12000NM000J 12TB: 1 failure 
    • Seagate ST16000NM000J 16TB: 1 failure
    • Seagate ST16000NM002J 16TB: 0 failure 
    • WDC WUH722626ALE6L4 26TB: 1 failure. Shoutout to the new kid—starting off strong!
  • Red flags:
    • HGST HUH728080ALE600 8TB: 10.29%
    • Seagate ST10000NM0086 10TB: 5.23%
    • Toshiba MG08ACA16TEY 16TB: 4.14%

We talked about two of these drives last quarter, and what we said about the Seagate still holds true—we’re seeing end of life activity with this drive. But, let’s dig in on the 8TB HGST and 16TB Toshiba and see what’s going on. 

HGST HUH728080ALE600 8TB

There’s always some digging to be done when we see a double digit failure rate, especially on a drive that, in the past year, hasn’t had terrible failure rates (despite the fact that it’s about 7.5 years old).

It’s worth contextualizing, first, that the total drive count of this model is 1,073, which equates to less than one Vault. (A standard Vault has 1,200 drives.) While Vaults aren’t always the same drive model, especially with older drives, in an ideal world, those Vaults would be uniform. So, in this case, we’re dealing with drives that are all hanging out in the same location in a data center, which means we could be working with environmental factors like a change in temperature or airflow. 

By the time Drive Stats data gets to me, of course, lots of smart people have already seen the disturbances in the force, so to speak. When I dug into the data center work tickets, it turned turned out that folks had already ruled out temperature as a factor—the working theory at the moment is that the drive could be sensitive to vibration, but given the age of these drives, we decided to just flag them for our normal CVT migration process. 

Toshiba MG08ACA16TEY 16TB

We talked about this model last quarter because it clocked in at a 16.95% AFR (!!). Our investigation turned up some collaborative (and routine) firmware work with Toshiba, and at that time, we predicted that these failure rates would normalize once again. We’re still a little high, but that’s likely a function of rolling out the work. As predicted, this is a healthy normalization.

Defining the relationship, aka setting some boundaries

We’ve covered the reasons that we’ve designed these exclusions in past reports, but here’s the quick and dirty:

Period Drive Count Drive Days
Quarterly > 100 > 10,000
Annual > 250 > 50,000
Lifetime > 500 >100,000

Regardless of whether or not a given drive model is included in this article’s charts and tables, all of the line item data is included in our Drive Stats dataset which you can download by visiting our Drive Stats page.

Sharing Is Caring

2025 Annual hard drive failure rates

As of the end of 2025, Backblaze was monitoring 349,462 hard drives used to store data. We removed 4,176 boot drives and 1,090 hard drives from consideration as they did not meet the annual criteria we have defined. This leaves us with 344,196 drives divided across 30 different drive models. The table below shows the AFRs for 2025 for this collection of drives.

Backblaze Hard Drive Failure Rates for 2025

Reporting period January 1, 2025–December 31, 2025 inclusive
Drive models with drive count > 250 and drive days > 50,000 in 2025

Notes and observations

  • The annual AFR is down: This year finishes strong at 1.36%, down from 1.55% in 2024. Still those paying attention to the quarterly AFR have seen some volatility in that number.
  • Nobody made it out unscathed: There are zero 0 failures.
  • But, let’s talk about it: These are the drives that averaged less than two failures per quarter (though, not necessarily evenly distributed when you look at the data).
    • HGST HMS5C4040BLE640 4TB: 5 failures
    • Seagate ST12000NM000J 12TB: 4 failures 
    • Seagate ST14000NM000J 14TB: 7 failures 
    • Seagate ST16000NM002J 16TB: 1 failure
    • Toshiba MG09ACA16TE 16TB: 3 failures
    • WDC WUH722626ALE6L4 26TB: 1 failures.
      • Note that this drive is in its first quarter of life, so it’s hard to call this significant yet. 

And, all those drive tickets and models mean lots and lots of work—we wrote a whole article on that front, but here’s a breakdown of hours spent in each data center. 

A chart showing the total work time spent per data center in 2025.

And here’s an even more interesting slice, from a drive perspective:

Yes, you’ll see some funky drive sizes on that list; it’s inclusive of all of our drives, not just the hard drives we include in this report. 

Comparing Drive Stats for 2023, 2024, and 2025

Let’s take a look back at the previous years’ annual AFRs to get a sense of how 2025 compares:

Three Year Comparison of Annual Backblaze Hard Drive Failure Rates

For drive models with > 250 drives as of 12/31/25 and drive models with > 50,000 drive days in 2025
Data for each year is inclusive of that year.

Notes and observations

  • The annual AFR is down to 1.36%. We haven’t seen those numbers since 2022 (1.37%). Cool!
  • Slicing our data by drive size shows how impactful the shift to high capacity drives really is: based on the current quarterly data, our drive size breakdown looks like this:
    • 0–12TB: 25.13%
    • 14–16TB: 52.06%
    • 20TB+: 22.81% 

This is an already long report, so in the interest of time, we’ll just say this: There are multiple factors that go into how and why things are changing, including the average age of drives within our cohort, how much drive technology has improved over the years, how drives on the market have gotten bigger over time while the cost per GB has also dropped, and how the current demand for drives has been changing some of those things.  

If that sentence sounds confusing, welcome to the world of enterprise drive buying. But, as always, we have to contextualize the real data we see with the way we source and use drives. 

Lifetime hard drive failure rates

Backblaze Lifetime Hard Drive Failure Rates 

Reporting period ending December 31, 2025 inclusive
Drive models with > 500 drives and > 100,000 lifetime drive days

Notes and observations

  • Ol’ faithful: Lifetime AFR is 1.30% this quarter, and there’s been no significant change in that number for quite some time. 
  • Say hi to the new guy: The Toshiba MG11ACA24TE 24TB made the cut for the lifetime table. Last quarter, we deployed another 2,400 of these, bringing us to 4,806 drives total. 

The Hard Drive dataset (and beyond)

Thank you, as always, for making it through ~2,500 or so words to examine the fun side of data. Here’s our standard fine print: 

The complete dataset used to create the tables and charts in this report is available on our Hard Drive Test Data page. You can download and use this data for free for your own purpose. All we ask are three things: 

  1. You cite Backblaze as the source if you use the data; 
  2. You accept that you are solely responsible for how you use the data, and; 
  3. You do not sell this data itself to anyone; it is free.

If you’re a new Drive Stats fan, consider signing up for the newsletter. If you’re not ready for that kind of commitment, sound off in the comments section below or reach out directly to us to let us know what you’re working on. Happy investigating!

The post Backblaze Drive Stats for 2025 appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

A Deeper Look at S3 Compatible Lifecycle Rules in Backblaze B2

Post Syndicated from Bala Krishna Gangisetty original https://www.backblaze.com/blog/a-deeper-look-at-s3-compatible-lifecycle-rules-in-backblaze-b2/

A decorative image showing a pattern of diamonds on a gradient background.

As data footprints swell and multi-cloud strategies become the norm, the complexity of managing object lifecycles—from initial creation to eventual archival or deletion—can introduce significant risk and operational overhead. To help our customers solve for this, we recently announced support for lifecycle rules through S3-compatible APIs.

While the previous post focused on what the feature enables and why it matters, this follow-up will look at how lifecycle rules work at a deeper level and what to keep in mind when using them in production.

Why S3 compatible lifecycle rules matter

Let’s quickly refresh your memory about why this feature matters. Many customers already rely on lifecycle rules in Backblaze B2 to manage storage costs and data retention. These rules automate actions like deleting old objects, hiding previous versions, or cleaning up incomplete multipart uploads.

By adding S3 compatible support for lifecycle rules in Backblaze B2, it allows you:

  • Lift and shift migrations from AWS S3 to Backblaze B2
  • Reuse of existing tools, xml configurations, scripts, applications & infrastructure as code
  • Predictable behavior across environments as part of multi-cloud strategy

API surface area and XML structure

Lifecycle rules are managed using three APIs:

  • PutBucketLifecycleConfiguration
  • GetBucketLifecycleConfiguration
  • DeleteBucketLifecycleConfiguration

These APIs accept and return XML documents that follow the AWS S3 lifecycle configuration format. From a client perspective, this behaves the same way it does on S3, including rule IDs, status flags, filters, and actions. 

Example put lifecycle request

Below is a simple example that hides objects under the logs/ prefix after 30 days.

PUT /?lifecycle HTTP/1.1
Host: my-bucket.s3.us-west-004.backblazeb2.com
Content-Type: application/xml
<LifecycleConfiguration>
<Rule>
<ID>deleteOldLogs</ID>
<Status>Enabled</Status>
<Filter>
<Prefix>logs/</Prefix>
</Filter>
<Expiration>
<Days>30</Days>
</Expiration>
</Rule>
 <Rule>
<ID>deleteOldLogs_marker</ID>
<Status>Enabled</Status>
<Filter>
<Prefix>logs/</Prefix>
</Filter>
<Expiration>
<ExpiredObjectDeleteMarker>true</ExpiredObjectDeleteMarker>
</Expiration>
</Rule>
</LifecycleConfiguration>

If the XML validates successfully, B2 stores this configuration and returns a 200 OK response.

Example get lifecycle response

GET /?lifecycle HTTP/1.1
Host: my-bucket.s3.us-west-004.backblazeb2.com
<LifecycleConfiguration>
<Rule>
<ID>deleteOldLogs</ID>
<Status>Enabled</Status>
<Filter>
<Prefix>logs/</Prefix>
</Filter>
<Expiration>
<Days>30</Days>
</Expiration>
</Rule>
</LifecycleConfiguration>

The response mirrors the original configuration, allowing tools like Terraform or AWS CLI to reconcile state.

Mapping from S3 rules to B2 rules

Backblaze B2 already supported lifecycle rules through the B2 Native API. The S3 compatible lifecycle implementation builds on this foundation.

Here is how the mapping works at a high level:

  • Each S3 lifecycle rule is converted into one or more internal B2 lifecycle rules.
  • Prefix filters in S3 map directly to B2 file name prefixes.
  • Expiration actions translate into B2 hide or delete operations.

This approach allows us to reuse the same lifecycle execution engine while exposing a familiar S3 interface.

Conceptually, the flow looks like this:

S3 XML lifecycle rule
|
v
XML validation
|
v
S3 rule compilation
|
v
B2 lifecycle rule objects
|
v
Lifecycle execution engine

Expiration behavior

Lifecycle rules can target both current and non current versions.

Some important details:

  • Expiring the current version results in a hide marker being created, matching S3 behavior.
  • Non current version expiration deletes older file versions after the configured number of days.
  • B2 keeps the same guarantees around version ordering and visibility that exist in the native API.
  • To remove abandoned hidemarkers by default, an ExpiredObjectDeleteMarker rule for expiration by days is a must.
  • The ExpiredObjectDeleteMarker rule ID is derived from the expiration by days rule ID with a “_marker” suffix.

Understanding this behavior is important if you rely on object versioning for recovery or audit purposes.

Here is an example to remove older versions of objects with prefix data/ that are hidden for more than 90 days.

<Rule>
<ID>delete-old-versions</ID>
<Status>Enabled</Status>
<Filter>
<Prefix>data/</Prefix>
</Filter>
<NoncurrentVersionExpiration>
<NoncurrentDays>90</NoncurrentDays>
</NoncurrentVersionExpiration>
</Rule>

How this behaves internally

At evaluation time, B2 walks object versions in order and applies rules like this:

Pseudo code:

for each object in bucket:
for each version of object with data prefix:
if version is non current:
if age_in_days >= NoncurrentDays:
delete version

For current versions, expiration works differently.

Expiring the current version

When a lifecycle rule expires the current version, B2 creates a hide marker instead of deleting data immediately.

This matches S3 semantics and preserves version history.

current version expired
|
v
hide marker created
|
v
current version becomes non current

Overlapping and nested prefix rules

Backblaze B2 supports multiple lifecycle rules on the same bucket, including overlapping and nested prefixes.

For example, you might configure:

  • A general rule for logs/ that deletes objects after 365 days
  • A more specific rule for logs/audit/ that deletes objects after 90 days

When rules overlap, the configuration with lowest value is applied to save cost to you. This mirrors S3 behavior and allows fine grained control without duplicating buckets.

Matching logic:

object path: logs/audit/2024/01/file.json

matching rules:
- logs/
- logs/audit/

selected rule:
- logs/audit/ because it has lowest value, 90 days

Multipart upload cleanup

Lifecycle rules can also be used to abort incomplete multipart uploads if not completed in a certain number of days. This is implemented by tracking the initiation time of multipart uploads and periodically removing uploads that exceed the configured threshold. This helps prevent abandoned uploads from consuming storage indefinitely. 

Below is an example rule to delete multipart uploads that are not completed after seven days after starting the upload process.

<Rule>
<ID>abort-multipart</ID>
<Status>Enabled</Status>
<AbortIncompleteMultipartUpload>
<DaysAfterInitiation>7</DaysAfterInitiation>
</AbortIncompleteMultipartUpload>
</Rule>

Internal execution model

Multipart uploads are tracked with their initiation timestamp.

Pseudo code:

for each multipart_upload:
if now - initiation_time >= DaysAfterInitiation:
abort upload
delete uploaded parts

Lifecycle execution model

Lifecycle rules are not executed in real time. Instead, they are evaluated by background processes that scan eligible objects and apply actions asynchronously.

Important characteristics:

  • Rules are not evaluated in real time
  • Execution is eventually consistent
  • Large buckets may take multiple passes to fully apply changes

This design allows lifecycle processing to scale across billions of objects efficiently without impacting foreground operations.

High level execution flow:

scan bucket periodically
|
v
identify eligible objects
|
v
apply lifecycle actions (hide and/or delete)
|
v
record progress and continue

Error handling and validation

Lifecycle XML is validated using S3 compatible rules:

  • Invalid combinations of actions are rejected
  • Missing required fields return errors
  • Unsupported actions return descriptive failures

While error messages may differ slightly from AWS, the validation logic follows the same constraints.

Compatibility considerations

While the goal is strong S3 compatibility, there are still some things to keep in mind:

  • Not all S3 lifecycle actions are supported yet
  • XML validation follows S3 rules, but error messages may differ slightly
  • The underlying storage model of B2 can affect timing and visibility

We recommend testing lifecycle rules in a non production bucket before rolling them out broadly.

Final thoughts

Adding S3 compatible support for lifecycle rules on Backblaze B2 was all about making migrations simpler and letting customers reuse existing automation with confidence. It behaves the way you expect while benefiting from B2’s internal scalability. 

If you already manage lifecycle rules using S3 APIs, those same configurations can now run on Backblaze B2 with minimal or no changes.

The post A Deeper Look at S3 Compatible Lifecycle Rules in Backblaze B2 appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Network Stats for Q4 2025: Neocloud Traffic Trends

Post Syndicated from Brent Nowak original https://www.backblaze.com/blog/network-stats-for-q4-2025-neocloud-traffic-trends/

A decorative image with the text Q4 2025 Network Stats.

Welcome to our second quarterly Network Stats report covering Q4 of 2025. Along with Drive Stats and Performance Stats, Network Stats pulls back the curtain on real-world infrastructure data, particularly how network-level analytics reflect emerging AI industry trends and usage patterns.

Get more Network Stats (and the details of the dataset)

If you are curious about what metrics we’re recording and how we classify data in this series, check out the details outlined in our Q3 2025 Network Stats  report.

One of the roles of the Network Engineering (NetEng) team at Backblaze is to monitor how traffic moves into, out of, and across our platform—not just day-to-day, but over time as customer behavior and industry dynamics evolve. Right now, few forces are reshaping networks faster than AI. 

With the launch of B2 Overdrive in April 2025, we built a direct, high-performance path between our storage layers and neoclouds where processing, inference, and modeling take place. It has given us a front-row seat to the impact of AI and how network behavior is changing with it. This quarter, in addition to our regular data analysis, I’ll walk through where AI-driven traffic is concentrated, how ingress and egress patterns showed up, and what the findings say about where AI infrastructure might be headed next. 

Continue the conversation

Join us live for the Q4 2025 Network Stats webinar Wednesday, February 4, 2025 at 10:00 a.m. PT / 1:00 p.m. ET. We’ll explore where AI traffic concentrates, how high-magnitude data flows behave, and what early indicators suggest about the future of AI-native infrastructure design.

Can’t make it live, or reading this article after-the-fact? Sign up anyway and catch the recording on demand.

Get Inside Real AI Network Flows

Brave new market

AI workflows don’t just need a place to store data, they need to be able to move it quickly, easily, and nearly constantly for short bursts. Large, multi-petabyte datasets are ingested, transformed, exported for training, pulled back for evaluation, and periodically refreshed as models evolve.  

Backblaze plays a key role at both ends of that lifecycle. We serve as a durable storage layer for the initial data ingestion, and as the high-throughput source feeding model training, evaluation, and validation to whatever best neocloud is suitable at the moment. Once that model has been trained, it needs to be stored, served, and periodically retrained, where we serve as the storage medium.

This quarter, we saw a large amount of traffic between Backblaze, neoclouds, and traditional hyperscalers for processing concentrated across the months of June to November. This reflects large-scale ingestion events followed by intensive data manipulation and model-related egress. 

From a network perspective, this represents a meaningful shift from diffuse, internet-style traffic patterns to large, high-bandwidth flows between a smaller set of endpoints typical of AI-centric infrastructure.

The neocloud slice

The defining theme of the quarter is “new:” new AI-oriented workflows, new traffic patterns, and leading indicators of new infrastructure trends. 

The stacked area graph below shows total traffic by network type over time. While content delivery network (CDN), hosting, and internet service provider (ISP) traffic stayed largely within historical norms reflecting steady-state usage patterns like content delivery, web hosting, and traditional backup workflows, two slices stand out:

  • Migration traffic: We saw a notable increase in migration traffic from August through October.  This classification reflects an influx of data into our network over fiber connections we have in the data centers to cost effectively migrate large amounts of data over private links, not using the public Internet.
  • Neocloud traffic: We saw a sharp increase in July through November, peaking in October.

What do we think is happening? Taken together, these patterns suggest a familiar AI lifecycle:  large datasets consisting of assets like images, videos, and metadata are ingested and consolidated then exported for training and experimentation. Now, those assets can be periodically updated as new assets are added and generated models and stored. We see that heading into the new year, the overall baseline has increased indicating a new normal.

Quick terminology refresher

  • Regions
    • US-West: Our largest and longest-running region
    • US-East: Region with the most observed proximity to neocloud infrastructure
    • CA-East: Our newest region in Canada. 
  • Network Types
    • CDN: Networks that use Backblaze as an origin store for content delivery 
    • Hosting: Traditional hosting providers that runs workloads like physical or virtual servers for web, database, or application tasks
    • Hyperscaler: Large, traditional cloud providers
    • ISP Regional: Local or regional ISPs, think of these as the “last mile” paths as these networks are very close to customer equipment and efficient 
    • ISP Tier1: National or international ISPs that carry our traffic long distances
    • Neocloud: AI -focused compute networks
    • Migration: Network links that we use for large-scale data onboarding

Heatmaps: Where AI traffic concentrates

To better understand where AI activity is happening, we thought it would be interesting to isolate the different Backblaze regions and to view concentrations of metrics visualized through heatmaps. We’re going to look at the following three dimensions: 

  1. Total traffic volume: Where did we send and receive the most traffic? 
  2. Magnitude: Where were the data transfers with the most bits per unique IP address?
  3. Uniqueness: What does the number of distinct IP addresses look like? 

Heatmap #1: Where did we send and receive the most traffic?

Unsurprisingly, US-West ↔ ISP-Regional traffic dominates in total traffic volume. This region has the largest data center footprint behind it, with connectivity to internet exchanges (IX) such as Equinix-IX that were brought online in 2023. Internet exchanges bring us closer to consumer networks, where we can deliver traffic with lower latency.

More interesting, however, is the US-East ↔ neocloud concentration. Our flow data shows neocloud activity clustering in regions including Chicago, Dallas-Houston, Denver, New York, Northern Virginia (Reston/Ashburn corridor), and Atlanta—skewed more towards the East Coast where there’s dense AI compute availability. 

From a performance standpoint, this makes sense. It’s important to keep latency (the time between the source and destination) lower to achieve consistent high bandwidth rates for AI data transfers. For now, that gravity is pulling activity towards the East coast. 

Will neocloud traffic concentrations shift over time? Since this is our first quarter with a full dataset, it’s a bit early to draw long-term conclusions. But this is exactly the kind of trend we’ll be tracking. Stay tuned for future Network Stats reports.

Heatmap #2: Where were the data transfers with the most magnitude (bits per IP address)?

Another metric we record is bits per IP or what we termed in our last report “magnitude.” This combination of the amount of traffic transferred with how many actors are involved per network is a good proxy to measure how heavy or impactful individual data flows are. In short:

  • High volume, many IPs: Easier to distribute and load-balance across infrastructure. And many source and destination pairs means that we can traffic engineer at the WAN layer, sending some traffic over one provider and some over another.
  • High volume, few IPs: More difficult, but more interesting, from a NetEng perspective. 

With B2 Overdrive, we routinely support client transfers starting at 100Gbps up to 1Tbps of throughput.These high-magnitude flows show up clearly in the data, especially in regions serving AI-heavy neocloud endpoints. Seeing these patterns emerge in the data validates that customers are actively using the platform the way it was designed.

Heatmap #3: How many unique addresses do we interact with?

Uniqueness—measured by the number of distinct IP addresses per network type—adds another dimension to the story. 

  • US-West shows the highest overall uniqueness, driven by its larger number of data centers and mix of workloads.
  • Neocloud traffic, by contrast, tends to involve fewer, more persistent endpoints, consistent with AI pipelines that rely on stable, long-standing connections between storage and compute. 

This contrast reveals a broader trend: AI networking is less about many-to-many communication and more about sustained high-throughput relationships between specialized systems.

A chart showing the number of unique IP addresses that sent or received data to the Backblaze networks by region.
Communication uniqueness across our regions to each network type

Summary: Early indicators of an AI-native network era

This quarter represents an early but important snapshot of how AI is reshaping network behavior:

  • AI-driven traffic is concentrated and heavy (not groundbreaking news by any means, but interesting to see it played out on a network).
  • Neocloud connectivity is a defining feature of data movement today.
  • Data gravity is pulling storage, compute, and network design into tighter alignment.

This is our first look at these patterns specifically. As we gather more quarters of data, we’ll be watching closely to see how cyclical neocloud activity becomes, how regional concentrations shift, and how the growing ecosystem of AI-focused ISVs continues to change the shape of the network.

Quarter over quarter data

Last quarter we started capturing data and metrics that we were interested in tracking over time. This represents our first full quarter of data as we only started tracking in August of 2025, so it’s still early to start to see trends, but we’re including the visualizations for fidelity. 

First let’s take a look at where all our traffic goes from a global perspective with an updated view of last quarter.

A Sankey diagram that tracks total data traffic flow between Backblaze and different types providers for Q4 2025.
Sankey diagram of all August ingress and egress traffic grouped by type of network

Traffic to other clouds has increased (36.2% to 49.6%) since we last reported in August of 2025, with a slight decrease (19.8% to 18.4%) in Neocloud destinations, but a large increase (3.5% to 18%) to hyperscalers. It’s too early to call these things statistically significant trends or patterns that impact the cloud storage industry broadly, because they’re reflective of what types of customers Backblaze specifically has and our sampling range is only a quarter. That said, we do see an overall increase in cloud to cloud traffic, but the higher percentage to the type of clouds rotated from last quarter.

Next, let’s look at the magnitude of our network traffic based on the category of the traffic destination. As a reminder, magnitude represents the amount of traffic transferred with how many actors are involved per network. 

Next, to be consistent with our previous report, we’ll look at magnitude on a linear scale. 

With more datapoints, we can clearly see the magnitude of the neocloud and hyperscaler transfers when compared to other network types. As above, it’s a bit early to claim concrete quarter over quarter patterns, but we’ll keep monitoring and updating the dataset. 

What’s next?

Next quarter will be the first where we have true quarter over quarter data to analyze, and we’ll be back with more on how AI-driven flows change quarter over quarter. And as we get more data, we’re interested in looking at other trends like IPv4 vs. IPv6 traffic, cross-cloud connectivity trends, and revisiting the concentration analysis we did this quarter. 

Anything specific you want to see? Let us know in the comments or reach out to our Evangelism team. Or, keep up-to-date with the latest technical content with our Developer Newsletter. 

The post Network Stats for Q4 2025: Neocloud Traffic Trends appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

The New Shape of Risk: How Generative AI Is Changing the Security Landscape

Post Syndicated from Stephanie Doyle original https://www.backblaze.com/blog/the-new-shape-of-risk-how-generative-ai-is-changing-the-security-landscape/

A decorative image showing several cubes split into different smaller shapes.

As generative AI has shifted from selective experimentation to broad operational use, large language models (LLMs) now sit inside developer environments, support workflows, internal knowledge systems, and security tooling itself. Adoption has widened for both enterprises and consumers alike, and, unsurprisingly, have a whole new set of security patterns.

Though oftentimes single catastrophic failures are the types of stories that make the news (like an AI agent pushing code to production against its explicit instructions), the truth is that there’s a bigger narrative here. Generative AI has introduced a whole new way to work, and we’re seeing a set of recurring behaviors—ways that AI systems interact with data, instructions, and people—that either introduce new risks or enhance some tried-and-true bad actor tactics (like more convincing phishing attacks, for example).

This article focuses on seven patterns that have emerged in real deployments and documented incidents. Let’s get into it. 

1. Prompt injection and instruction hijacking

Prompt injection has matured from a research concept into a practical exploit vector. The issue is structural: LLMs interpret text holistically using tokenization, which makes it difficult to maintain a strict separation between instructions and data. When untrusted content is introduced into an AI system with elevated permissions, that ambiguity becomes exploitable.

Recent incidents show how this plays out in production tools. Researchers analyzing Microsoft Copilot demonstrated that carefully crafted inputs could override intended behavior, expose system prompts, or trigger unintended actions within the model’s sandbox.

The common thread is authority. When models are allowed to act on retrieved content or invoke downstream tools, text becomes a control surface.

2. Prompt poaching and peripheral exfiltration

Not all AI-related data loss requires access to the model itself. A recent malware campaign demonstrated how attackers can siphon AI conversations by compromising the surrounding ecosystem.

Malicious Chrome extensions posing as productivity tools were found harvesting prompts, responses, and browsing context from users interacting with AI assistants; the data was quietly sent to external servers.

These attacks target trust boundaries adjacent to AI systems rather than the models directly. Browser extensions, plugins, and integrations become collection points for high-value contextual data that did not previously exist in a single place. And, they’re often less controlled by enterprise IT teams compared with other types of software. 

3. AI-powered malware and ransomware

AI-assisted malware is no longer hypothetical. Security researchers have now documented ransomware that uses generative models as part of its operational logic.

One example: PromptLock, a ransomware strain that leverages LLMs to dynamically generate portions of its code and behavior during execution.

At the ecosystem level, threat intelligence reports show ransomware groups using AI to accelerate development, customize payloads, and craft tailored extortion communications. Akamai’s 2025 ransomware trends report documents LLM usage by active groups for both technical and social components of attacks.

It’s less about how it’s done and more about how fast it’s done: Iteration cycles are shorter, and adaptation happens more quickly.

4. Acceleration and competitive pressure in the ransomware economy

Even when AI is not embedded directly into malware, it influences the broader threat environment. Ransomware activity increased throughout 2025 despite arrests and takedowns; new groups emerged quickly to replace disrupted ones.

As we said above, speed matters here. Defensive models that assume time for analysis, tuning, and response are increasingly stressed by attackers who can prototype and redeploy faster than those cycles allow.

And it’s not just speed—the volume of (credible, real) attacks matters too. The truth of the game has always been that bad actors only have to succeed once whereas defenders have to succeed every time. If better ransomware is being produced more quickly, defenders are having to adapt just as (or more) quickly to a higher volume of attacks (which makes the demand for employees in the security industry that much more understandable). 

5. Semantic noise and operational fatigue

Generative AI produces a large volume of plausible output: summaries, recommendations, alerts, explanations. In isolation, that capability is helpful; in aggregate, it introduces a new operational burden.

Security teams report growing difficulty distinguishing signal from well-formed noise. In reality, this means that over-taxed employees are getting pinged while on-call far more. 

AI-generated conclusions often require human validation, but their tone and confidence can reduce scrutiny over time. That creates opportunities for malicious activity to hide inside outputs that appear reasonable and routine; or, on the flip side, for things like process and architecture misconfigurations to masquerade as security events by creating too many requests. 

This pattern does not map cleanly to a single exploit; it shows up as delayed detection, slower response, and missed anomalies.

6. Code supply chain risk from generated code

AI-generated code compounds familiar supply-chain issues. Generated snippets often compile cleanly, pass tests, and follow common patterns; they also tend to replicate insecure defaults or omit contextual safeguards.

As these patterns are reused across services, small mistakes scale quickly. Not only that, but basic parameters like privileging recency (e.g., new security patches) vs. commonality (e.g., the most often used code) can have major implications and be weighted differently in different tools. While there is demonstrated risk of malicious insertion, it’s also the normalization of fragile or incomplete logic through automation.

7. Potential human skill erosion as a force multiplier

One of the quietest risks is also the hardest to measure. As AI tools handle more analysis, summarization, and decision support, human operators spend less time interrogating raw data. That’s both a good and a bad thing—really, it begs the question of how we go about creating and applying expertise in a new and developing epistemological framework. (Wait, you thought engineering wasn’t philosophical?)

Over time, that shifts how teams validate outcomes and how comfortable they are challenging AI-generated conclusions. This erosion does not cause incidents by itself, but it can amplify the impact of every other failure mode.

Where this leaves us

Across these examples, a consistent theme emerges. Generative AI changes how authority, context, and action flow through systems. Many of the resulting failures are subtle and blend into normal usage patterns.

The next phase of response is already taking shape. Government agencies and standards bodies are beginning to formalize guidance on securing AI systems, managing AI-related risk, and adapting existing security practices to these new patterns.

That guidance belongs in its own discussion. For now, the takeaway is simpler: AI adoption has altered the shape of risk. 

The post The New Shape of Risk: How Generative AI Is Changing the Security Landscape appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

A Developer’s Guide to Migrating Multimodal AI Training Data (and Putting It to Work) with Pixeltable

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/a-developers-guide-to-migrating-multimodal-ai-training-data-and-putting-it-to-work-with-pixeltable/

A decorative image showing gears and a cloud.

Today’s AI models consume much more than text—everything from product images to video from surveillance feeds to audio from customer calls to metadata spread across an ever-expanding set of systems. These multimodal datasets drive everything from computer vision pipelines to customer service automation. But as they scale, the underlying infrastructure starts to creak.

Costs can become unpredictable. Data fragments across S3 buckets, HDFS clusters, and local drives. Maintaining cross-modal alignment, i.e. ensuring that media files stay linked to their labels, embeddings, and annotations, becomes a bottleneck that slows development to a crawl.This article outlines a practical path forward: how to migrate multimodal training data using proven open-source tools, and how Pixeltable helps unify and index that data for training once it lands in Backblaze B2.

Moving multimodal training data: Practical open source software (OSS) tools that do the heavy lifting

Before you can train on consolidated data, you need to get it all into one place. These three open-source tools handle the migration work, each addressing a different piece of the puzzle.

Apache NiFi for moving large media reliably

When your dataset includes terabytes of video files, thousands of high-resolution images, or large binary assets like LIDAR scans, you need something more robust than a shell script. Apache NiFi is purpose-built for moving large media files at scale.

NiFi provides:

  • Flow control and retry logic that handle network interruptions gracefully, which is essential when transferring terabytes of data over hours or days.
  • Data provenance tracking that records exactly which files moved where and when, making it possible to debug issues without guessing.
  • A visual workflow designer that lets you build and monitor data flows without writing custom code.

For multimodal datasets where media volume dominates, NiFi ensures files arrive intact and trackable. Check the Apache NiFi User Guide to get started with building your first data flow.

Airbyte for syncing structured and semi-structured metadata

Media files are only half the story. Annotations, labels, captions, transcripts, and database records provide the context that makes raw media useful for training. Airbyte excels at moving this structured and semi-structured metadata.

Airbyte handles:

  • Schema consistency when pulling metadata from multiple sources, ensuring annotation formats don’t drift between your labeling platform, your CRM, and your feature store.
  • Incremental syncs that only transfer changed records, avoiding unnecessary data movement as your datasets grow.
  • Multiple data systems via a broad catalog of connectors for databases, SaaS platforms, file formats, and cloud storage services.

Unlike NiFi, which focuses on raw file movement, Airbyte understands data schemas and transformations. Use it to keep your metadata in sync across systems. The Airbyte documentation provides setup guides for most common data sources.

lakeFS for versioning for reproducible training

After moving media via NiFi and metadata via Airbyte, you need a way to snapshot the entire dataset so you can reproduce training runs six months later. lakeFS brings Git-like version control to object storage.

lakeFS enables:

  • Branching and snapshots of entire datasets without copying data. You can create a branch, run an experiment, and merge or discard the results.
  • Atomic commits that ensure media, metadata, and derived features stay aligned as your corpus evolves.
  • Zero-copy clones that let multiple teams work on isolated versions of production data without storage overhead.

lakeFS acts as a version control layer on top of storage like Backblaze B2, tracking changes without duplicating objects. When a training run produces a new model, you can tag the exact dataset version that went into it. The lakeFS quickstart guide walks through creating your first repository and branch.

After migration, the hard part begins: Making the dataset usable

Moving data into object storage solves logistics, not usability. Even in B2, your media files, labels, and derived features remain scattered—images in one prefix, annotations in another, embeddings in a third. Training code becomes a tangle of custom loaders that stitch everything together, break when datasets change, and consume more engineering time than model tuning.

Where Pixeltable fits

Pixeltable provides the missing layer between migrated storage and training-ready data. It’s a declarative data infrastructure specifically designed for multimodal AI applications.

Here’s what Pixeltable does:

  • Unifies media and metadata into a single table interface: images, video frames, audio clips, and their associated labels, embeddings, and annotations live in one queryable structure.
  • Stores computed results automatically. Run OCR on documents, generate CLIP embeddings for images, or extract audio transcripts once, and Pixeltable caches the results for reuse.
  • References Backblaze B2 objects directly without copying data. Files stay in Backblaze B2, and Pixeltable maintains pointers and metadata in a local Postgres instance. Pixeltable automatically caches the files locally on access, and can write media files back to B2 (see our project for examples: https://github.com/backblaze-b2-samples/b2-pixeltable-multimodal-data).
  • Supports built-in transforms like embedding generation, image captioning, and OCR with lazy evaluation. Define transformations once, and they run incrementally as new data arrives.

Instead of maintaining custom loaders and indexing scripts, you define a schema once. Pixeltable handles orchestration, caching, and queries. The result is a training dataset you can slice, filter, and feed directly into PyTorch DataLoaders or Hugging Face Datasets.

Check the Pixeltable documentation to see how tables, computed columns, and queries work in practice.

A practical end-to-end workflow

Here’s how these tools fit together in a real-world pipeline:

1. Move media via NiFi → Backblaze B2

Set up an Apache NiFi flow to transfer images, video files, or other large binaries from your current storage (on-premise NAS, another cloud provider, or local drives) to a Backblaze B2 bucket. Configure retry logic and provenance tracking so you can verify every file arrived.

Use NiFi processors like GetFile, PutS3Object, and RouteOnAttribute to handle file movement and error routing. The Backblaze B2 Cloud Storage S3-compatible API works seamlessly with NiFi’s S3 processors.

2. Sync metadata via Airbyte

Configure Airbyte to pull annotations, labels, captions, and database records from your labeling tool, feature store, or other sources. Set up connections to sync metadata incrementally as it changes. If annotations live in Postgres and captions come from a cloud-based labeling platform, Airbyte normalizes both into a consistent schema in Backblaze B2 or a dedicated metadata store.

3. Create a lakeFS branch to snapshot the dataset

Initialize a lakeFS repository pointing to your Backblaze B2 bucket. Create a branch to isolate this version of the dataset. If something goes wrong during training, you can roll back or compare versions. Use the lakeFS CLI or Python client to create branches and commits programmatically.

4. Define a Pixeltable schema referencing B2 objects + synced metadata

In Pixeltable, create a table with columns for image paths (pointing to Backblaze B2), labels, captions, and any other metadata fields. Import your data so each row represents one training example: one image, its label, its caption, and any associated metadata.Pixeltable doesn’t copy image files—it stores references and metadata, automatically caching the files locally on access. The images stay in Backblaze. The Pixeltable Tables guide explains how to create tables with multimodal column types and import data from external sources.

5. Run transforms (embeddings, captions, OCR) inside Pixeltable

Define computed columns for embeddings, captions, or OCR results. Pixeltable’s computed columns run transformations lazily as data is queried or when you explicitly trigger computation.

For example, you can add CLIP embeddings using Pixeltable’s built-in Hugging Face integration, or generate AI captions using OpenAI’s vision API. Once defined, these columns compute incrementally—new images trigger automatic processing without reprocessing the entire dataset.

The Pixeltable API reference documents all available functions for common operations like embedding generation, image processing, and text analysis.

6. Query or filter the unified dataset

Use Pixeltable’s query interface to filter, sort, and slice your data. For example, find all images labeled “cat” with embeddings similar to a reference image. Or extract rows where captions mention “outdoor” and timestamps fall within a specific range.

7. Feed batches directly into PyTorch/Hugging Face

Export data from Pixeltable into PyTorch DataLoaders or Hugging Face Datasets format for training. Pixeltable handles batching, shuffling, and data access so your training loop stays clean.

The Pixeltable documentation covers various export formats and integrations with popular ML frameworks, allowing you to avoid intermediate export steps and maintain a streamlined workflow from data preparation to model training.

From fragmented storage to production-ready training data

Multimodal AI datasets don’t have to be a maintenance nightmare. By chaining together proven open-source tools—NiFi and Airbyte for migration, lakeFS for versioning, and Pixeltable for unified access—you can turn scattered files and metadata into queryable training assets.

Once data lands in Backblaze B2, this stack eliminates the custom glue code, brittle loaders, and alignment issues that typically slow down training workflows. Your team gets reproducible datasets, clean interfaces, and more time for model development instead of infrastructure firefighting.

Ready to get started? Check out the Backblaze B2 documentation to set up your object storage, and explore Pixeltable’s examples to see multimodal workflows in action.

The post A Developer’s Guide to Migrating Multimodal AI Training Data (and Putting It to Work) with Pixeltable appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

2025: That’s a Wrap and Here Are the Stats

Post Syndicated from Stephanie Doyle original https://www.backblaze.com/blog/2025-thats-a-wrap-and-here-are-the-stats/

A decorative image showing several server racks.

When most people think about year-end work, they think in terms of deadlines, retrospectives, and a well-earned break. Data centers have other ideas because, well, the internet still needs to work on holidays in order to power those digital fireplaces and Spotify playlists.

Backblaze runs year-round, around the clock, which means that even the holidays are business as usual in a data center. And many customers who use Backblaze to store their AI models, applications, media, and critical business data need that data storage to be more reliable than ever, especially around the holidays. Every drive swap, rack adjustment, alert investigation, and routine fix leaves a trace in our work tickets, and we’ve discussed in our Drive Stats reports how we use those work tickets to do things like define a failure. They’re also evidence of what it takes to keep an always-on service humming, even when the rest of the company is offline. 

So, as the year comes to a close, we wanted to shout out to our awesome data center, cloud ops, and on-call team members—we couldn’t do it without you. And here’s a little retrospective on what this past year looked like.

Total time spent working in each data center

Backblaze has four data regions and six data centers. Here’s the breakdown of where we spent our time this year, inclusive of everything from entropy-fighting maintenance tasks to all the normal network and performance upgrades that keep us ahead of changing data patterns to good ol’ scaling and expansion of our data center footprint:: 

In total across data centers, we spent 3,112.43 hours replacing hard drives. (If those hours don’t square up with the charts above, it’s because the total view includes other types of work, like upgrading our systems.) On average, it took about 0.74 hours per hard drive. 

Here’s a breakdown of the drives replaced by capacity: 

If you’re a Drive Stats fan, you may notice there are some funky drive sizes on there based on our other reporting data. (A 2TB drive? Where does that one even come from?) The drives above are inclusive of our whole fleet, including boot drives and non-production drives, and some of those are sized differently than based for whatever reason—history, job in the data center, etc.

Vault deployments

We also deploy new Vaults fairly regularly. This year, we added the following Vaults (per data center): 

And, here’s a breakdown of the number of Vaults broken down by drive size:

In total, we spent 1043.23 hours on Vault deployment which is about 31.61 hours on average per Vault.

Numbers, as always, tell the story

Taken together, the data shows every hour logged, every drive replaced, every Vault added, and every ticket closed. It adds up to a year’s worth of hands-on infrastructure care; in short, it’s the steady investment required to operate storage at scale.

Whether you’re on call monitoring your own systems, planning for growth in the year ahead, or fully offline over the holidays, your data is here for you. Cheers to another great year!

The post 2025: That’s a Wrap and Here Are the Stats appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Bookblaze 2025: Backblaze Employee Recommended Reads

Post Syndicated from Stephanie Doyle original https://www.backblaze.com/blog/bookblaze-2025-backblaze-employee-recommended-reads/

A decorative image showing several books on a holiday background.

Sure, we may be a global tech company who spends our days on the front lines of helping our customers solve their toughest data storage challenges, but that doesn’t mean we don’t ever power down the devices and curl up with a good book. Welcome to the third annual Bookblaze, Backblaze’s much-anticipated book guide where our team shares the stories, insights, and adventures that shaped their reading year. 

From thought-provoking nonfiction to immersive fiction and unexpected gems, these recommendations are curated by the people who read, think, and create here at Backblaze—offering you a cozy companion for winter nights, inspiration for your 2026 reading list, and maybe even the perfect gift idea along the way. Whether you’re reconnecting with old favorites or discovering your next great read, we hope this year’s picks spark joy, curiosity, and conversation.

Chris McGranahan, Director, Information Security Architecture

An image of the cover of The Story of CO2 Is the Story of Everything by Peter Brannen.

The Story of CO2 Is the Story of Everything, by Peter Brannen

It’s an exhaustive but entertaining explanation of how our world came to be the way it is, why CO2 is so important to it and how the path we’re currently on is likely to create a world that hasn’t existed in millions of years and never supported humans. And, if you want a fun fiction read, check out any of the Murderbot Diaries series by Martha Wells.

Maddie Presland, Product Marketing Manager

An image of the cover of the book Clytemnestra, by Costanza Casati.

Clytemnestra, by Costanza Casati

I love deeply flawed female protagonists. I also love the fact that myth retellings have been so popular for the last few years, and this year, I decided to tackle my hyper-specific TBR I was neglecting. (Editor’s note: For those of you not afflicted with chronic book collecting, TBR = to be read.) 

Clytemnestra tells the story of one of the most reviled women in Greek mythology. She’s cunning, ruthless, and quite possibly the original champion of playing the long game to seek revenge, as a key player in the Trojan War you’ve probably never heard of. And yet, you can’t help but root for her. It’s shocking that this is a debut novel because, though it can be a slow burn in parts, the characterization and completely immersive writing provides a different perspective of how the Trojan War unfolded for those left at home.

Bala Krishna Gangisetty, Sr. Product Manager

An image of the cover of the book Positive Intelligence, by Shirzad Chamine.

Positive Intelligence, by Shirzad Chamine

I appreciate how Positive Intelligence translates mindset and emotional intelligence into practical exercises for building mental fitness. The Saboteur framework makes it easy to spot negative thinking and shift toward a more productive mindset. It’s a great balance of psychology, neuroscience, and real-world application that supports personal and professional growth.

AJ Sedlak, Director, GTM and Marketing Operations

An image of the cover the book Essentialism: The Disciplined Pursuit of Less, by Greg McKeown.

Essentialism: The Disciplined Pursuit of Less, by Greg McKeown

In work and in life, we often struggle with saying “no”, even to ourselves. We take on more than we can effectively manage and execute. As a result, we’re burned out—frustrated by our ever-growing to-do lists and disappointed in the quality of what we do get done. This book helped me understand why doing less actually results in accomplishing more and better things. In addition, it gave me a sense of how to make this case to others—whether it’s about prioritization of work projects or helping a loved one who’s feeling overwhelmed.

Amy Kunde, Sr. Executive Assistant

An image of the cover of the book The Extraordinary Life of Sam Hell, by Robert Dugoni.

The Extraordinary Life of Sam Hell, by Robert Dugoni

Although there were some dark moments in the book, in general it was a feel good book of a boy coming of age through adulthood, paying his dues and then paying it forward.  The setting is right in the Backblaze neighborhood so it’s always interesting to picture the local intersections, and schools referenced in the novel.

Elisa Miller, Sr. Organizational Development Partner

An image of the cover of the book Parable of the Sower, by Octavia Butler.

Parable of the Sower, by Octavia Butler

Octavia Butler is a masterful sci fi writer who has woven a tale in the 1990s set to present time about a dystopian reality oddly similar to the one we are living/heading towards currently of lawlessness, greed, and the quest for survival. Focusing on the power of community, togetherness, and nature, this book was an epic (and scary) adventure into what happens when people gather together to fight the status quo while lifting one another up. It’s not for the faint of heart, but it really was a game changer for me to read, offering solutions beyond capitalism and towards empowerment of humanity, spirituality, and purpose. 

Molly Clancy, Sr. Manager, Content & Creative

An image of the cover of the book Project Hail Mary, by Andy Weir.

Project Hail Mary, by Andy Weir

It’s a buddy comedy, but also the fate of the human race is at stake. There’s lots of science to nerd out on if that’s your thing. And Andy Weir is a former software engineer, so you could kinda sorta say it’s “for work.”

Beth Grey, Sr. Risk & Regulatory Compliance Specialist

An image of the cover of the book The Happy Sleeper: The Science-Backed Guide to Helping Your Baby Get a Good Night's Sleep-Newborn to School Age, by Heather Turgeon, MFT, and Julie Wright, MFT.

The Happy Sleeper: The Science-Backed Guide to Helping Your Baby Get a Good Night’s Sleep-Newborn to School Age, by Heather Turgeon, MFT, and Julie Wright, MFT

Sleep training my child without having to resort to too much crying seemed daunting, but this book helped inform our process with evidence based guidance. I am happy to report that I have a great little sleeper because of it. This book will help any parent gain the skills and confidence to effectively sleep train their child.

Yev Pusin, Head of Communications and Community

An image of the cover of the book Dungeon Crawler Carl, by Matt Dinniman.

Dungeon Crawler Carl, by Matt Dinniman

This book series is absolute insanity, and if you are able to get the audiobook, you will not regret it. I even got my sister’s mother-in-law to listen to it on audio and she loved it. The premise is that it’s the end of the world, and Carl is sucked into a dungeon to fight for the entertainment of the universe at large—plus there’s a talking cat! What’s not to like? It’s a genre known as LitRPG (editor’s note: Literary role-playing game) which follows Carl and his friends’ progression as they work through the dungeon and try to topple the powers that be.

Nicole Gale, Sr. Marketing Operations Manager

An image of the cover of the book The Ballad of Songbirds and Snakes, by Suzanne Collins.

The Ballad of Songbirds and Snakes, by Suzanne Collins

The new “Hunger Games” book is the first prequel I’ve read in years that genuinely adds something meaningful to its original series. It pulled me right back into Panem, had me rewatching all the movies, and had me loving characters that I didn’t expect to get attached to. A fantastic return to a world I thought I already knew.

Stephanie Doyle, Writer and Content Operations Strategist

An image of the cover of the book Children of Time, by Adrian Tchaikovsky.

Children of Time, by Adrian Tchaikovsky

This series reminds me of old-school science fiction in all the best ways. Without giving too much away, a terraforming project is sabotaged, leading to unexpected outcomes for the targeted planet. Meanwhile, back on Earth, the world ends, and a race begins for the remainder of humanity to find a new home. Tchaikovsky’s brilliance thrives in the details of understanding systems, people, biology, engineering, and science, and each new revelation about what’s happening—in this new world with a new sentient species, and with the humans on their ever-devolving arc ship—stems from each of those details showing up in ways that feel both expected and unexpected at the same time.

The post Bookblaze 2025: Backblaze Employee Recommended Reads appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Scaling Generative AI Video Depends on Your Data Egress Strategy

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/scaling-generative-ai-video-depends-on-your-data-egress-strategy/

A decorative image showing several clouds.

The AI and cloud infrastructure industry talks endlessly about GPUs, model size, and compute capacity, but there’s an invisible Achilles heel that can quietly undermine even the most promising AI projects: data egress.

According to a new Dimensional Research survey, 95% of organizations experience unexpected cloud storage fees, often from retrieval, egress, or API transactions. These hidden costs are rarely visible in early budgets, but they can torpedo innovation as workloads scale, especially when video enters the mix. Raw footage, frame-level training data, model checkpoints, and final renders can add up to hundreds of terabytes every week, straining both budgets and infrastructure. 

Read the full report

We surveyed over 400 IT decision makers and one thing stood out. Surprise charges affect almost everyone. Learn what’s driving them—and how to avoid them.

Read the Full Report

Most generative AI video outputs today max out at 480p or 720p resolution. As demand grows for 1080p and 4K, storage and bandwidth requirements will multiply. Without a deliberate egress strategy, that growth becomes a silent tax on innovation. Over time, it restricts experimentation, reduces iteration speed, and undermines cost predictability.

The future of AI video belongs to teams that treat egress strategy as part of their innovation architecture and choose partners that let them move data freely between storage and compute, without penalty.

Inside the generative AI data pipeline

Modern AI systems no longer operate inside a single environment. Data is stored in one place, trained in another, and increasingly delivered at the edge. As workloads scale, the ability to move data efficiently becomes as important as compute capacity.

According to IDC, 88% of cloud buyers now deploy hybrid cloud environments, and 79% already use multiple providers. The Dimensional Research survey found that 99% of organizations struggle with limited flexibility and interoperability, highlighting how closed ecosystems are slowing progress just as multimodal AI demands more open, composable infrastructure.

To understand why egress matters so much for generative AI video, it helps to look at the AI data pipeline, which follows five continuous stages: 

  1. Data ingest and active archive: Collect and store raw images, video, audio, and metadata for future processing.
  2. Data processing: Clean, label, and transform data into usable training sets.
  3. Model experimentation and training: Run GPU-intensive model development and fine-tuning, save checkpoints and weights.
  4. Model deployment and inference: Apply trained models to new video, user queries, or edge devices to generate results.
  5. Monitoring: Track accuracy, latency, and system health to retrain and optimize continuously.
A chart that defines the five continuous stages of the data pipeline, including data ingest and archive, data processing, model experimentation and training, model deployment and inference, and monitoring.

Each stage has distinct storage and compute requirements, but data moves between them constantly. For AI video, those transfers can span regions and providers. When egress is slow or expensive, the entire pipeline backs up, delaying iteration and driving up cost.

When data can’t move, innovation can’t either

Keeping everything under one cloud provider once simplified management. At first glance, it still seems convenient to keep storage, compute, and archive all in one place. Within a single AWS region, egress is free. But as soon as data crosses regions or providers, the model breaks down.

Tiered pricing makes costs hard to forecast. Egress fees penalize movement. Resource contention slows performance, and interoperability gaps lock teams into static configurations. AI video workloads amplify the problem: training, inference, and storage often require different environments optimized for each stage. 

Dimensional Research’s data shows that 55% of organizations note egress costs as the single biggest barrier to switching cloud providers. Many stay with less efficient or more expensive infrastructure simply because the economics of mobility make innovation too costly. Moving just 1 PB of data out of AWS storage in the US East region costs about $53,800 per month—often enough to halt multi-cloud testing entirely.

The true cost, however, is in the experiments that are never run and the innovations that don’t get discovered because of a pricing structure that discourages exploration. 

Freedom of data movement is the new competitive edge

In generative AI, the pace of progress is set by how quickly teams can test, retrain, and redeploy new models. That agility requires data mobility.

As organizations adopt composable AI stacks that mix specialized compute, regional storage, and orchestration tools, success depends on how openly data flows between them. Teams that design for movement can scale faster, adapt to new technologies, and stay resilient as infrastructure changes.

For teams building generative AI video applications, the impact is especially pronounced. A studio fine-tuning a diffusion model might burst to GPU providers with available capacity, render high-resolution outputs, and archive them for reuse, all without rewriting code or paying to move the data each time.

Data mobility has become a measure of competitiveness. The faster teams can move information across environments, the faster they can innovate.

How to build an egress strategy that fuels innovation

A good egress strategy ensures that storage and compute stay aligned as workloads scale. It helps teams anticipate cost, performance, and interoperability issues before they turn into blockers.

Here are a few practical steps to get there:

  1. Map your data flows. Identify where data originates, how it moves between services, and which transfers happen most frequently.
  2. Quantify transfer and API transaction costs. Include both in your total cost of ownership models. Even small fees add up quickly at petabyte scale.
  3. Test portability. Run controlled migrations or bursts to secondary compute providers to expose hidden bottlenecks.
  4. Select for openness. Favor vendors with flat, transparent pricing, free or low-cost egress, and broad S3 compatibility.
  5. Plan for growth. Multimodal models and higher-resolution video outputs will multiply data transfer volumes. Design bandwidth and budget models accordingly.

Beyond controlling costs, the goal is to keep flexibility built into your architecture so your team can use the best tools for each stage of the AI pipeline, without being trapped by pricing friction or closed ecosystems.

The Backblaze difference: Open by design

Storage that supports innovation shouldn’t penalize movement. That’s why we created Backblaze B2 Overdrive to give teams with high-throughput, data-intensive workloads the flexibility they need to innovate. 

Overdrive is the right fit for AI video because of its:

  • Predictable economics: $15/TB/month with unlimited free egress (no penalties for moving data to the compute you need). 
  • Zero transaction fees: API calls don’t become a hidden tax as pipelines scale.
  • S3 compatibility and high throughput: Drop into existing pipelines without rewrites and keep large media workflows moving quickly across training, rendering, inference, and archive.

AI startup Decart put Backblaze B2 through its paces as it developed a real-time generative AI open world model, with millions of hours of training video data and multi-petabyte workloads daily.

What we really needed was a place where we could store an insane amount of data and, at the same time, download it to a few different GPU clusters around the world, and for all that to not cost an insane amount of money. That’s why we chose Backblaze.

—Dean Leitersdorf, Co-Founder and CEO, Decart

With Backblaze’s free egress model, they reduced AI operation costs by 75% while maintaining flexibility across compute environments. 

If you’re scaling generative AI video, Backblaze B2 Overdrive gives you the freedom to put data where it performs best, without egress penalties, transaction surprises, or architectural do-overs.

The post Scaling Generative AI Video Depends on Your Data Egress Strategy appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Building Multimodal AI Data Infrastructure with Pixeltable

Post Syndicated from Jeronimo De Leon original https://www.backblaze.com/blog/building-multimodal-ai-data-infrastructure-with-pixeltable/

A decorative image showing a chip with the word 'AI' and digital lines extending into the background.

We’re approaching a fascinating inflection point in AI development. Research from Epoch AI indicates that high-quality text data will be fully exhausted by 2026 to 2028. As recently as January, OpenAI co-founder Ilya Sutskever said at a conference that all the useful data online had already been used to train models. Over 35% of top websites now block AI scrapers. OpenAI is cutting deals with publishers like The Financial Times because freely available training data is running out.

So what comes next? Multimodal data: video, images, audio, sensor readings. Data that captures how the physical world actually operates, not just how we describe it in text.

Nvidia CEO Jensen Huang highlighted this shift when discussing Tesla’s AI advantage. He noted that the company has a “phenomenal position” because Tesla is collecting massive amounts of real-world data through its AI-enabled factories and autonomous vehicles.”

This real-world data, what some call “world data,” is multimodal at its core. It includes video from cameras capturing spatial relationships and motion, sensor telemetry recording physical interactions, images showing object states, and audio capturing environmental context. Video is particularly valuable because it captures temporal dynamics, depth perception, and how objects interact over time, insights that static text or images alone cannot provide.

Here’s the insight most organizations miss: you’re already generating this data.

Your organization is already producing multimodal data

Every single day, your organization produces massive amounts of multimodal data, including:

  • Zoom calls with video, audio, and screen shares
  • Security camera footage
  • Customer service interactions combining chat logs, voice recordings, website screen recordings and product images
  • Manufacturing sensors producing telemetry alongside quality inspection photos
  • Marketing teams creating videos, graphics, and campaign documents
  • Sales demos mixing presentations, product screenshots, and recorded conversations

And that’s just the short list.

The problem isn’t scarcity. It’s how multimodal data gets siloed, deleted, or stored in ways that make it unusable for AI applications. Video sits in one system and transcripts in another, with metadata scattered across databases. Most organizations treat this as operational exhaust rather than the strategic asset it represents.

Organizations that start systematically leveraging their multimodal data today will have capabilities tomorrow that generic models can never match.

The challenge: Multimodal infrastructure complexity

Building AI systems that work across images, video, audio, and text traditionally requires stitching together a fragmented technology stack. Videos live in object storage. Structured data sits in relational databases. Vector embeddings need specialized vector databases. Custom ETL pipelines handle transformations. Orchestration code coordinates everything. You need separate systems for caching, versioning, and lineage tracking.

This “data plumbing” consumes more engineering time than actual AI development. A straightforward workflow like building a searchable video archive with object detection and similarity search requires coordinating five or more systems and writing hundreds of lines of orchestration code.

The complexity creates a barrier that prevents most organizations from leveraging their multimodal data effectively, even when the underlying AI models are accessible through APIs. That’s the gap that Pixeltable solves.

How Pixeltable simplifies multimodal data workloads

Pixeltable replaces the fragmented multi-system architecture typically required for AI applications with a single declarative table interface. Instead of coordinating databases, file storage, vector databases, APIs, and orchestration tools separately, you work with tables where multimodal data lives alongside your transformations and AI operations.

The approach is straightforward. Store multimodal data in tables, define transformations as computed columns, and query everything together. Pixeltable handles the orchestration, caching, and model execution automatically.

Connect to data in-place 

Point Pixeltable at your existing object stores like AWS S3 or Backblaze B2 Cloud Storage without moving or duplicating data. Your files stay where they are, organized into queryable, versioned tables. No separate databases or vector stores needed.

Define workflows declaratively 

Transformations, model inference, and custom logic become Python computed columns. Extract frames from video, run object detection, generate embeddings, define it once and Pixeltable auto-orchestrates execution, manages dependencies, and handles incremental updates when new data arrives.

Query across everything

Leverage semantic search co-located with metadata. Raw data and AI-generated results in one interface. Build RAG systems with auto-synced embedding indexes that eliminate separate vector database management.

Focus on logic, not infrastructure

Full versioning for reproducibility. Automatic incremental processing means only necessary computations run when data changes. The same code works in development and production without rewrites.

For a practical example, explore our companion Github notebook Multimodal Data Processing with Pixeltable and Backblaze B2. It demonstrates how to extract and transform video frames using Pixeltable, then store the processed results in Backblaze B2 Cloud Storage with automatic URL generation.

Powering multimodal AI with Pixeltable and Backblaze B2

At Backblaze, we understand how essential multimodal data has become for AI development. Our collaboration with Pixeltable integrates B2 Cloud Storage directly into their open-source framework, giving organizations a simple and scalable foundation for managing complex AI workloads.

Pixeltable’s declarative design works seamlessly with Backblaze B2 across the entire AI data lifecycle. Whether you are processing video for model training, running inference on image streams, or building retrieval-augmented generation systems with multimodal embeddings, Backblaze B2 provides reliable S3 compatible storage that Pixeltable can reference directly without data duplication.

We are working closely with the Pixeltable team on a handful of initiatives to make multimodal workflows easier to deploy and scale. For those exploring this integration, we provide an example that demonstrates how Pixeltable and Backblaze B2 work together across the multimodal AI pipeline.

The data that fuels multimodal AI already exists across most organizations, from meeting recordings to customer interactions, video archives, and sensor logs. With Pixeltable and Backblaze B2, the infrastructure to harness that data effectively is now within reach.

Explore Pixeltable on GitHub or visit pixeltable.com to learn about declarative multimodal data infrastructure. For S3 compatible storage across your AI pipeline, check out Backblaze B2.

The post Building Multimodal AI Data Infrastructure with Pixeltable appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Holiday Gift Guide 2025

Post Syndicated from Yev original https://www.backblaze.com/blog/holiday-gift-guide-2025/

An illustration of a gift box.

It’s that time of year again where the holidays are barreling towards us at an incredible rate. With so many cyber sales and new things hitting the market, it’s the most wonderful time of year to read gift guides. To help, I’ve asked my fine companions at Backblaze to list out some of their favorite gift ideas for this year, and I’ve compiled them for you here. Enjoy the suggestions, and my rambling commentary!

Couch Cady

The couch outside of my office and the recliner are where I spend the majority of my at-home time. What better way to keep your drinks, snacks, and second screens handy than this caddy?

Cereal Cup

Have you ever put cereal and milk into a yeti mug and drank it after everything’s turned into a sugary mush? Me neither, but now you don’t have to—this cup allows you to maintain two great tastes that taste great together, but without them having to touch until you’re ready!

Slow Cooker Seasoning Blends

For the chef in your life—or for the aspiring chef that never quite understood what the word “seasoning” meant—this is a great seasoning blend. Let’s face it, if you’re eating their food, it’s a gift for you too!

Schmidt Brothers Stainless Steel 10-Piece Knife Block Set

Another one for the chef’s in your life. This knife block bundle looks good, by all accounts feels good, and also cuts good—which is great. By the way, does anyone in your life use pairing knives? It’s something I’m just now getting the hang of…fun!

Timeless Six Wine Exploration Bundle

I have this, I use this, and I love this. It’s likely been in gift-guides of yesteryear but it’s just that good. Whether you’re a single human like me who doesn’t want to open a whole bottle and just wants a glass from time to time, or you’re an aficionado wanting to taste his bottles before opening them for a fancy dinner, this pumps inert argon gas into your wine bottles without having to open the cork. Great stuff.

Graze olive oil in glass bottles

Popularized by Tiktok videos, this olive oil stands up to the hype and adds a good amount of actual flavor to your dishes. Whether you’re drizzling or frying, it’s a good recommendation!

Sustainably Raised Meat (for cooks or people who BBQ)

And speaking of frying, Butcherbox allows you to order sustainability sourced meats and have them delivered right to your door. It might be too late if you’re looking for a Thanksgiving bird, but you might need a few steaks eventually!

Terra Kaffe Demi automatic espresso machine

Espresso. Some pronounce it with an “x.” And while it does give you a caffeine boost in a hurry, there’s nothing express about it…except for getting a machine like this that can really speed up and boost your home coffee consumption.

Fancy Onsen Towels

Soft, cuddly, and rapidly drying—these towels are a treat. I got to use one a few months ago while visiting a friend of mine and I still think about them, seriously! It might actually be time to rotate my towels and these are at the top of the list.

Cordless Cleaning and Scrubbing Brush

Cleaning yourself with onsen towels is great, but what about cleaning the actual shower or bath? These allow you to get all the nooks and crannies between the tiles, and because they’re cordless you can also use them on your car rims. Do you ever wash those? You should!

Guardian Kids Bike and Guardian Adult Bike

What’s one of my top-10 favorite things? Assembling Ikea furniture while listening to music. But I also enjoy biking! This combines both as the adult and children bikes are shipped to you and you get to assemble them at home before taking them on the road! It keeps costs low, and satisfaction high!

Oura Ring 4

I have been wearing fitness trackers for a very long time, from smartwatches to fitbits to step-counters, and this is my favorite one so far! I love that I can quickly charge it every 4-5 days and it gives me great insights into activity and sleep, without having to wear something bulky to bed.

Patagonia Black Hole Duffel

I am often envious of people who travel with duffel bags because of all the stuff you can fit into them. I still use my old-timey rollaboard, but I do have one of these that I throw in the car with me when I hit the ski slopes. These are great, come with backpack straps, and also have a lot of clips where you can hook carabineers up to (which is a great way to bring shoes you don’t want to pack).

Bev Ledge

Airplanes have come a long way but unless you’re sitting in your own personal pod up front (must be nice), there never seems to be enough room for all your stuff! This ledge fits neatly onto your window sill and allows for you to get a little more utility out of your surroundings! Just…don’t get an aisle seat.

Trtl Travel Pillow

As the Wu-Tang Clan once sang, “protect ya neck.” This travel pillow helps do just that when you’re on the go. No one likes falling asleep on a plane and waking up to a stiff neck—this helps!

Wyze Solar Cam Pan

These are great for monitoring the outside of your home, but the real killer app comes from using the indoor ones as baby monitors. Seriously, my family has been using them for years in the kiddos’ rooms, and not only is the quality much better than a standard baby monitor, but the recording features make for some really cute videos, and there’s no range restrictions. It’s a win-win-win.

Bambu Lab X1C 3D Printer

3D printing has become very mainstream over the last few years, and this at-home unit with space for multiple filaments makes it incredibly easy to create your favorite designs.

Kindle

Books. You know them, you love them, you should probably read one of my favorites from the last 10 years (The 7 ½ Deaths of Evelyn Hardcastle) and any of the Kindles should help you do just that! I’m a book on tape guy now because I tend to walk a lot (and if you have Audible I highly recommend the Dungeon Crawler Carl series), but if you enjoy holding something in your hands, the paper white Kindles are fantastic.

Classic Diablo (or any “good old game” from GOG”)

Classic games are classic for a reason! The recommendation from our org was for Diablo on Good Old Games, but there are a ton of classics there to choose from. One of my favorite series: Quest for Glory. Version 4 my favorite as it dives into Eastern European folktale lore!

Voice Activated Transformer Robots

Transformers have always been popular, and these voice-activated robots are what I dreamed of when I was a kiddo. Now that I’m no longer a kiddo, I still kind of want one, because watching toys “build themselves” gives me real Toy Story vibes.

K-pop Demon Hunters Wooble kit

K-Pop Demon Hunters took the world by storm, and now you can turn it into a crafting activity for you or your kiddos! Wobbles are little crochet kits, and come with everything you need to make something cute and squishy, right at home!

Retroid Pocket G2

This little gaming handheld allows you to emulate the games of your youth. Whether you liked playing the Sega Game Gear or the Game Boy, you can get all your favorites in one place with these on-the-go systems.

Moondrop Space Travel Headphones

On the go or on the couch, good headphones are paramount. These are relatively shallow and offer noise cancelling technology to keep the outside world out while you’re listening to tunes, audiobooks, or podcasts!

Give the gift of Backblaze

An image of a gift box with the words "Give Backblaze Backup" overlaid

Of course you can always give the gift of Computer Backup. It makes a great gift and helps keep the data of your family and friends safe and sound. Peace of mind is a great gift.

Something you’ve had on your mind didn’t make our list? Tell us in the comments—we love hearing what people are excited about!

The post Holiday Gift Guide 2025 appeared first on Backblaze Blog | Cloud Storage & Cloud Backup