Ir al contenido

Deliver your archive to your own bucket

Esta página aún no está disponible en tu idioma.

Blob export continuously delivers your team’s sealed archive into storage you own and control - an Amazon S3 bucket or an Azure Blob container. It runs alongside Comma’s own retention: your archive keeps living in Comma, and a second, verifiable copy lands in your bucket that your own auditors, e-discovery tools, and data pipelines can read directly.

This is the “bring your own bucket” path for firms that want the archive to physically reside in their own cloud tenancy - for data-residency, defense-in-depth, or downstream analytics.

Every sealed record for your team is written out as a line-delimited JSON envelope plus content-addressed object bytes:

  • Messages, reactions, edits/revisions, and poll votes - for business conversations only
  • Calls and voicemails (telephony compliance records)
  • Attachments and media, content-addressed by SHA-256
  • Journaled inbound email (the RFC822 original ships as a referenced object)
  • Captured site-scan / file-version content
  • Go-forward from activation. Delivery starts at the moment your destination is activated. Content sealed before activation is not back-filled in v1 (a historical backfill is a planned follow-up).
  • Deterministic and idempotent. Records are delivered in daily-partitioned batches under object keys derived from the data itself. A retry re-ships the same records under the same keys with byte-identical content, so a re-run is always safe.
  • Completeness you can prove. Each batch writes a manifest.json listing every data object with its SHA-256 and byte size, plus per-record-type counts. A zero-length _SUCCESS marker is written last - its presence means the batch is complete.
  • Export duplicates, never destroys. Blob export only ever writes a copy into your bucket. It does not delete or alter your Comma archive, and legal holds are unaffected.

Everything lands under an object-key prefix you choose (blank means the bucket/container root):

<prefix>dt=<YYYYMMDD>/batch-<batch_key>/records.jsonl.gz # gzipped JSON Lines, one record per line
<prefix>dt=<YYYYMMDD>/batch-<batch_key>/manifest.json # per-batch inventory + SHA-256s
<prefix>dt=<YYYYMMDD>/batch-<batch_key>/_SUCCESS # written LAST = batch complete
<prefix>attachments/<content_hash> # content-addressed bytes, deduped across batches

Each line of records.jsonl.gz is a self-describing envelope (schema: comma-blob-export/1) carrying the record type, content hash, archived-at timestamp, custodian identity, the canonical payload (inline, or referenced for large/raw payloads), and its attachments. Lines are recursively key-sorted so a redelivery is byte-identical.

In v1, destinations are provisioned by your Comma account team. There is no self-serve configuration screen yet - so your job is to prepare the bucket and a scoped credential, then hand the details to Comma:

  1. You create the bucket/container and a least-privilege credential (the guides below give you an exact script).
  2. You verify that credential works in the shape Comma needs (a one-command probe).
  3. You send Comma the connection details over a secure channel.
  4. Comma runs a one-time Verify & activate check (it writes, reads back, and deletes a single tiny probe object under your prefix) and turns on delivery.

Once active, a team admin sees a read-only Bucket delivery status line - provider, an Active badge, and the last delivery time - on the Retention, storage & records settings page. No credentials are ever shown there.

Pick your cloud and follow the exact steps - including a copy-paste setup script and a verification script:

Prefer a printable version to hand to your cloud admin? Each setup guide is also available as a PDF: