**TL;DR:** Pod indexes back up to collections: static, restorable copies. Serverless uses export or re-import instead. Backup and restore Pod indexes: collections 1. Create a collection from the index.

## The fix

**TL;DR:** Pod indexes back up to collections: static, restorable copies. Serverless uses export or re-import instead. Backup and restore Pod indexes: collections 1. Create a collection from the index.

## The fix

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.

5. Before migrations (pod to serverless especially).

6. Before bulk deletes or re-embeds.

7. On a schedule for production indexes, with restores tested, not just created.

8. A backup you have never restored is a hope, not a backup. Test-restore to a scratch index quarterly.

9. Backing up the index but not the embedding model version and preprocessing code: a restore without the matching pipeline cannot be rebuilt or extended.

10. Deleting the source index the moment the collection exists: verify the collection is complete first (stats, sample fetch).

## When to use this

- This covers exactly what the title says: Pinecone workflow.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Pinecone; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.