A Storage Vendor Replaces Its Rackspace Server With an Embedded Files.com Pipeline for Terabyte-Scale Diagnostics

A high-performance storage vendor builds the parallel file systems and data platforms that HPC and AI workloads run on across enterprise, government, and research.

Every one of those systems runs inside a customer's environment, not the vendor's. When one of them needs support, the evidence an engineer needs has to travel out of that environment first. At the vendor's scale, that evidence is heavy. A diagnostic bundle from a parallel file system can run to terabytes, and single log files reach hundreds of gigabytes. Before a support case can move, that data has to cross from a network the vendor does not control into the vendor's own support workflow.

Terabyte Diagnostics, Collected by Hand

For years, the receiving end of that crossing was a Rackspace server, and the work around it was manual. Customers sent logs however they could, and someone at the vendor had to receive each file, work out which customer and which case it belonged to, and attach it to the ticket. That handling sat in the critical path of every case that needed diagnostics: between a customer with a degraded storage system and the engineer who could fix it. And it had to hold for everyone who depended on the same intake, across technical support, professional services, and L3 engineering.

The conditions made it hard to fix. The intake had to survive unreliable customer networks that drop connections partway through enormous transfers. Some customer sites run firewalls that allow outbound traffic only to explicitly approved destinations. And bundle sizes vary sharply by product line, from terabyte-scale parallel file system logs down to small product-specific dumps. A hosted file server could store whatever arrived, but it offered nowhere near the configuration and protocol range those uploads needed, and it gave the vendor's engineers nothing to build on.

What the vendor needed was less a destination than a programmable intake layer. Uploads had to arrive already carrying their ticket number. The platform had to speak the protocols customer environments could actually use, complete transfers of hundreds of gigabytes over unreliable links, present an address a restrictive firewall could approve, and expose an API deep enough for the vendor's own engineers to build the upload path into the products themselves and wire the output into Salesforce and object storage.

The vendor selected Files.com to be that layer and retired the Rackspace server.

From a Click in the Product to a Linked Salesforce Case

In several of the vendor's products, collecting diagnostics is now a feature of the product itself. A customer opens a case and clicks "generate troubleshooting information." The product uploads the bundle directly into Files.com, stamped with the ticket number. No one at the vendor asks for the file, and no one at the customer has to decide where to send it.

From there, the pipeline runs on its own. Files.com renames each bundle into the timestamp-first order the vendor's engineering automation reads. Remote Server Mounts and a Files.com Automation triggered on file creation hand it to Wasabi or AWS S3, where its ticket number connects it to the Salesforce case. A scheduled files-cli sync retains a copy on an on-premises server, while support engineers retrieve the bundles from Files.com to work the case.

The vendor's own staff built all of it, from the upload path inside the products to the downstream wiring, using the Files.com REST API and Python SDK.

Reaching Customer Sites the Vendor Does Not Control

Not every upload comes from inside a product. The vendor also gives its customers Files.com Inbox upload links for sending logs and archives straight to the support team. The intake folders carry write-only permissions and a locked folder structure, so an uploader can add files to the intake path and do nothing else.

The whole intake runs on the vendor's own domain with dedicated IP addresses. That matters at sites where the firewall permits outbound traffic only to approved destinations: when one customer's firewall blocked files.com itself, the dedicated addresses kept that customer's logs flowing. For the heaviest transfers, the vendor pushes single files of hundreds of gigabytes through files-cli from customer and internal systems, with completion over unreliable networks an explicit requirement of the design.

What Support Stopped Doing by Hand

With the pipeline in production, the vendor replaced manual collection of customer diagnostics with an intake that runs itself.

• Case attachment is automatic. Bundles arrive stamped with their ticket number and land linked to the Salesforce case, so no one receives, sorts, or files a customer log by hand.
• Hundreds of individual systems feed the platform through automated uploads.
• The intake absorbed a year of growth without changing shape as monthly transfer volume climbed, with peak months in the tens of terabytes.
• Customers behind restrictive firewalls still deliver their logs over the vendor's own domain and dedicated IPs.

The pattern also compounds. Every product line writes into the same intake, whether its bundles are terabyte-scale file system logs or small product-specific dumps, so a new product or a new customer joins the pipeline by uploading to it. Growth in support volume arrives as more transfer, not more hand work.

The Case Opens With Its Evidence Attached

Today, one of the vendor's support engineers opens a case that already has its data. Diagnostic intake and case matching no longer add manual work before investigation can begin.

The change came from treating file intake as something a product can do rather than something a person does. The vendor did not put a file portal in front of its support team. It built a diagnostics pipeline into the products it ships, and Files.com is the intake layer those products write to.