# Backup and restore

## Pod indexes: collections

1. **Create a collection** from the index. It is a static copy; writes after the snapshot are not included.
2. **Name collections by date and purpose** (`prod-2026-09-26-pre-migration`) so restore picks the right one under pressure.
3. **Restore** by creating a new pod index from the collection. Verify stats and sample queries before cutting traffic.
4. **Retain sensibly.** Collections cost storage; keep the last N plus pre-change snapshots, not everything forever.

## Serverless indexes

Collections are a pod concept. For serverless: maintain the source data outside Pinecone (you should anyway) and re-import, or use the documented export path to materialize a copy. The return-all-vectors guidance (list ids plus fetch in batches) is the manual fallback for small indexes.

## When to back up

- Before migrations (pod to serverless especially).
- Before bulk deletes or re-embeds.
- On a schedule for production indexes, with restores tested, not just created.

## Traps

1. A backup you have never restored is a hope, not a backup. Test-restore to a scratch index quarterly.
2. Backing up the index but not the embedding model version and preprocessing code: a restore without the matching pipeline cannot be rebuilt or extended.
3. Deleting the source index the moment the collection exists: verify the collection is complete first (stats, sample fetch).