Cold Storage

Cold storage is a second, lower-cost tier of object storage that automatically mirrors your warm Carolina Cloud Storage bucket. It is designed for data that you want to keep around indefinitely — raw sequencing reads, historical backups, finished project outputs — but don’t need to pull from on a minute-to-minute basis.

When to use it

Reach for cold storage when:

You’ve finished a pipeline and want the inputs/outputs archived off your active workspace.
You’re retaining data for compliance or reproducibility but rarely read it.
Your warm bucket is growing and you want a cheaper long-term home for files you’re not actively touching.

It is not a replacement for your warm bucket. Instances mount the warm bucket at ~/ccloud-s3/; cold storage is not mounted on instances and is not meant for live reads during compute.

Enabling cold storage

Cold storage is not provisioned by default. To turn it on for your account:

Once it’s enabled, a Cold Storage entry appears under Storage in the sidebar and you can browse your cold bucket from the dashboard.

Auto-sync from warm to cold

Once enabled, Carolina Cloud continuously syncs your warm bucket to your cold bucket in the background. You don’t copy files into cold storage manually — anything you put into ~/ccloud-s3/ (or your warm bucket via any other S3 client) shows up in cold storage automatically on the next sync pass.

Key layout is 1:1. If a file lives at s3://warm-bucket/projects/alpha/reads.fastq.gz, its cold copy lives at the same key in your cold bucket. No renaming, no path transforms — the cold bucket is a mirror.

This is deliberate: it keeps the mental model simple (one filesystem, replicated) and it’s what makes the deletion rules below work.

Deleting files: warm first, then cold

Because the sync only runs in one direction (warm → cold), you must delete from warm storage before you delete from cold. The API enforces this: a cold-delete request for a file that still exists in your warm bucket will be rejected with a 409 Conflict.

Why

If you could delete a cold file while its warm copy was still around, the next sync pass would just re-copy it into cold storage — your deletion would silently get undone. Rather than let that happen quietly, we refuse the delete up front.

The right order

Delete the file from your warm bucket. Use the Bucket Browser, rm ~/ccloud-s3/path/to/file from an instance, or any S3 client.
Then delete the file from cold storage. It’s now safe — nothing will re-sync it.

The reverse order doesn’t work and has no workaround. If you want a file gone, it needs to leave warm storage first so that cold has permission to let go of it.

What about files that only exist in cold?

This is a valid state — say you archived a project a year ago, then deleted the warm copy to save on warm storage costs. That cold-only file has no warm counterpart, so cold-deletes on it succeed immediately (there’s nothing to re-sync from).

Browsing cold storage

From the dashboard, click Cold Storage under Storage. You’ll see the same folder-style browser as the warm bucket browser, pointed at your cold bucket. You can:

Navigate folders
Download individual files via a short-lived presigned URL
Copy the full s3://… path of any object or folder
Delete files (subject to the warm-first rule above)

Performance and throttling

Cold storage lives behind a single shared account with per-request connection caps. If you hit the cap — usually only when scripting many operations in parallel — the API will return a 503 with geyser_busy. Back off for a moment and retry; for bulk work, keep concurrency low.

Pricing

Cold storage is billed at $1.55/TB/month, prorated hourly, with a 108 TB minimum per user once enabled. The minimum applies regardless of how much data is actually in your cold bucket. See Pricing & Billing for the full breakdown.