The edit was working. Then you tried something, and something else, and now it is worse in a way you cannot precisely undo because the changes were spread across twenty actions.

Why undo does not solve this

Undo is a stack of recent actions. It is excellent at the last thing you did and progressively worse the further back you go, for two reasons.

It runs out. Fifty levels of undo sounds like a lot until you realise that dragging a clip is several actions and an hour of editing is hundreds.

An editing timeline: video clips, a zoom keyframe and an audio track below.

It does not survive a restart. Close the app and the stack is gone, which is exactly when you tend to realise the earlier version was better.

Undo is for mistakes. It is not for decisions.

What snapshots are

A snapshot is a saved copy of the whole project state at a point in time. Unlike autosave, which holds only the latest, snapshots hold several past ones.

Because a project is a small list of instructions rather than a video, keeping several is cheap. Zella keeps six per project, pruning the oldest as new ones arrive.

Six is a deliberate number. Enough to walk back through a working session, few enough that choosing between them is a glance rather than an investigation. Thirty snapshots sounds better and is worse, because the cost of a version history is the time spent identifying which one you want.

Using them

Open the project's version list and pick one. Restoring is not destructive in the sense that matters: you are moving to an earlier state, not deleting the later work from history.

The awkward part is identifying the right one, and it is worth being honest that timestamps alone are a poor index. "Two hours ago" does not tell you whether that was before or after you rebuilt the middle section.

The habit that makes this work

Before any large change, note where you are.

Not a formal process. Just: about to try something big, current time is 14:20, the version at 14:20 is the one that was working. Ten seconds of attention that turns "somewhere in the last six" into "that one".

The changes worth doing this for are the ones that touch many things at once: applying a template, restructuring the order of sections, a colour pass across every clip, a re-cut of the whole middle.

The alternative that is often better

For genuinely experimental work, duplicate the project rather than relying on snapshots.

A duplicate gives you two named things you can compare side by side, which is much better than a linear history when you are not sure which direction is right. Snapshots answer "get me back". Duplicates answer "which of these is better", and those are different questions.

Snapshots are the safety net. Duplicates are the workbench.

What snapshots cannot do

They do not save your media. A snapshot is a list of instructions pointing at clips. Delete a clip and every snapshot referencing it has the same hole.

They do not survive deleting the project. Snapshots live with the project, so removing the project removes them.

They are not backups. They protect against your own edits, not against disk failure. If a video matters, the exported file needs to exist somewhere else, which is the same argument as in recovering an unsaved project.

A working practice

  1. Rough cut, then export it. That file is your true floor.
  2. Note the time before any big change.
  3. Duplicate the project before anything genuinely experimental.
  4. Let snapshots handle everything in between.

Most of the value is in step one, which costs five minutes and makes every subsequent disaster survivable. The rest is refinement.

Why this is not just paranoia

The version you want back is almost never lost to a crash. It is lost to a sequence of individually reasonable decisions that added up to something worse, and to the fact that you cannot see that until you have gone too far to undo.

That is a normal part of editing rather than a failure. The tooling just needs to make going back cheap enough that you are willing to experiment in the first place.

Apple's Final Cut Pro guide takes the same position with library backups, which it writes automatically on a schedule for exactly this reason.

Common questions

Why is undo not enough? It runs out, and it does not survive closing the app, which is exactly when you tend to realise the earlier version was better. Undo is for mistakes, not decisions.

How many versions are kept? Six per project in Zella. Enough to walk back through a session, few enough that choosing between them is a glance rather than an investigation.

Should I duplicate the project instead? For genuinely experimental work, yes. Snapshots answer "get me back", duplicates answer "which of these is better", and those are different questions.