# 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).