Cloud Storage vs Filestore for large-scale backup workloads: performance and cost trade-offs

We’re evaluating storage options for our enterprise backup solution on GCP and trying to decide between Cloud Storage and Filestore. Our backup workloads generate about 50TB monthly with retention periods of 1-7 years depending on data type.

I’m particularly interested in understanding the backup throughput differences and restore speed when we need to recover data quickly. We currently use on-premises NFS storage and are familiar with file-based workflows. Cloud Storage’s object model is appealing for cost, but I’m concerned about restore performance for large datasets. Has anyone done detailed cost modeling comparing these two for backup scenarios?

After running both solutions in production for over a year, here’s my comprehensive analysis of the backup throughput, restore speed, and cost modeling considerations:

Backup Throughput Comparison:

Cloud Storage wins decisively for backup throughput. With parallel uploads using gsutil -m or the Storage Transfer Service, we consistently achieve 6-8 GB/s aggregate throughput across our backup infrastructure. The key is launching multiple concurrent upload streams - each stream handles 150-250 MB/s depending on object size. For backup workloads with thousands of files, this parallelization is natural.

Filestore throughput is constrained by the tier you provision. Basic HDD provides 100 MB/s per TB (max 1.2 GB/s), while High Scale SSD can reach 1.2 GB/s per TB. For your 50TB monthly backup volume, you’d need expensive High Scale tiers to match Cloud Storage’s throughput, which defeats the purpose.

Restore Speed Reality:

Restore speed depends heavily on your recovery scenario. For full disaster recovery where you’re restoring terabytes, Cloud Storage’s parallel download capability (5-10 GB/s aggregate) significantly outperforms a single Filestore mount. However, for selective file restores where you need immediate NFS access, Filestore provides sub-second access versus Cloud Storage’s object retrieval latency.

Our solution: Use Cloud Storage for primary backups with Nearline/Archive lifecycle policies. For critical systems requiring fast recovery, maintain hot backups in Standard Cloud Storage (still cheaper than Filestore) or use a small Filestore instance as a restore staging area.

Cost Modeling Framework:

For 50TB/month with 1-7 year retention, here’s the cost breakdown:

  • Cloud Storage approach: Standard ($0.020/GB) for 30 days, Nearline ($0.010/GB) for 31-365 days, Archive ($0.0012/GB) beyond 1 year. Monthly cost at steady state (assuming 600TB total): ~$8,400/month.

  • Filestore approach: Basic HDD ($0.10/GB) for 600TB = $60,000/month. Even with deduplication reducing capacity by 50%, you’re still at $30,000/month.

The cost difference is 3-7x in favor of Cloud Storage, even accounting for egress costs during restores (you’ll pay $0.12/GB for egress, but only on restored data).

Recommendation:

For large-scale backup workloads, Cloud Storage with lifecycle management is the clear winner on both performance and cost. The object storage model requires some workflow adaptation from NFS, but the throughput gains and cost savings are substantial. Reserve Filestore only for specific use cases requiring true filesystem semantics or instant NFS restore capability.

For backup workloads, Cloud Storage is usually the better choice. The key is understanding throughput - you can easily saturate multi-gigabit connections with parallel uploads to Cloud Storage, while Filestore throughput is tied to the provisioned tier. For restore speed, both can be fast if you architect properly, but Cloud Storage’s parallel download capabilities often win for large-scale restores.

We migrated from Filestore to Cloud Storage for backups last year. The cost difference was significant - roughly 60% savings using Nearline storage class for our 30-90 day retention data and Archive for longer-term. Backup throughput actually improved because we could parallelize across multiple compute instances. The only gotcha was rewriting our backup scripts from NFS operations to gsutil commands.