Guides

Recovery without Tessera

How to retrieve your data if Tessera is unavailable, unwilling, or permanently gone — and what you need to keep on hand for that to work.

Tessera is not in the data path. That is an architectural fact with a useful consequence: given the placement record for an object, a client can retrieve and reconstruct it from providers with no involvement from us at all.

This page explains how to keep yourself in that position. We would rather you were able to leave than dependent on us being solvent.

What you need

Three things, all of which you can obtain today through the API:

The object record — GET /objects/{key}: the slab list with offsets and lengths, and the wrapped data key.
The slab records — GET /slabs/{id} for each referenced slab: minShards, the encryption parameter, and for each shard its provider public key, network address, and sector root.
Your key material — whatever unwraps encryptedDataKey. This has always been yours and we have never held it.

With those, retrieval is: connect to any 10 of the 15 providers named in the slab, request the sectors by root, verify each against its root, run Reed–Solomon reconstruction, concatenate the slab segments in order, decrypt.

Exporting your placement records

There is no single-call export endpoint yet, so an export is a walk over two endpoints:

async function exportPlacement() {
  const manifest: Record<string, unknown> = {}
  const seenSlabs = new Set<string>()

  let after: string | undefined
  for (;;) {
    const qs = new URLSearchParams({ limit: '100', ...(after ? { after } : {}) })
    const events = await call('GET', `/objects?${qs}`)
    if (!events.length) break

    for (const ev of events) {
      if (ev.deleted) {
        delete manifest[ev.key]
        continue
      }
      manifest[ev.key] = ev.object
      for (const s of ev.object.slabs) seenSlabs.add(s.id)
    }
    after = events[events.length - 1].updatedAt
  }

  const slabs: Record<string, unknown> = {}
  for (const id of seenSlabs) {
    slabs[id] = await call('GET', `/slabs/${id}`)
  }

  return { exportedAt: new Date().toISOString(), objects: manifest, slabs }
}

Mind the rate limit on a large export

30 requests per minute per credential, and a full export is one request per slab. For a large account, run the export as a background job with backoff and checkpointing rather than a single pass. Respect Retry-After on 429.

Store the result with your own backups — the same discipline you would apply to a database dump. It is small, it compresses well, and it contains no plaintext.

Export after writes, not on a timer alone

Placement changes when repair moves a shard to a new provider, so an old export can name providers that no longer hold your shards. Reconstruction still succeeds as long as 10 of the named providers are current, but the safer pattern is to export after each batch of writes and refresh periodically. The provider addresses are the part that goes stale, not the roots.

The prepaid window

Storage contracts are funded roughly 12 weeks ahead of need. We deliberately overpay: it costs us margin and buys a property we consider worth more than the margin.

If Tessera stopped operating tomorrow and nobody renewed anything, your shards would remain stored and retrievable for at least 60 days, because the providers have already been paid to hold them. Nothing needs to happen for that to be true, and nobody needs to be reachable.

Why this is a floor and not a promise

60 days is the conservative published figure, not a service commitment we might reinterpret later. It follows from contract terms already funded on the network. A promise depends on the promiser existing; this does not.

Reconstruction without our client

Nothing about retrieval is proprietary. Providers speak an open protocol, sectors are addressed by Merkle root, and the erasure coding is standard Reed–Solomon over GF(2^8). A competent engineer with your export and the protocol specification can rebuild your data using open-source libraries and no cooperation from us.

That is the point. Our moat is provider curation, contract management, and repair — the work that is tedious to do well. It is not, and should not be, control over your ability to read your own data.

What you would lose

To be balanced about it, if we vanished you would lose real things:

Repair. Shard loss would stop being fixed, so redundancy would decay from 15 toward 10 and eventually below it. This is the clock that matters, and it is slower than the payment clock.
Renewal. Contracts would expire at the end of their funded term, which is where the 60-day floor comes from.
Provider curation. No further vetting, no replacement of underperforming providers.
The convenient lookup path. Your export becomes the only copy of your placement record, which is exactly why you should hold one.

Your data would be recoverable, not maintained. The correct action in that scenario is to retrieve everything and re-store it elsewhere, promptly — not to treat the window as indefinite.

A recovery drill worth running

Do this once, on purpose, before you need to:

Export placement records for a handful of objects.
Write a retrieval script that uses only the export — no calls to our API at all.
Confirm it reconstructs and decrypts correctly.
Store the script alongside the export, with its dependencies pinned.

An untested recovery path is a hypothesis. Testing it takes an afternoon and converts your dependency on us from structural to merely convenient.