Rolling back to the previous image does not restore writes made after deployment. They live in the container or the volume, never in the image.
A deployment breaks production. You roll back to the previous image, the service comes up, and the data entered between the two deployments is gone. The rollback did its job. The problem was elsewhere.
An image is frozen, writes are not
A container image is immutable. It holds the code and config at build time, nothing else. Everything written after start, uploaded files, a local database, cache, lives in the container write layer, not in the image.
Rolling back to image N-1 spins up a fresh container from a frozen state. The writes from container N are nowhere in that image. They do not come back.
Recover, then fix the cause
If the old container was not deleted, its data is still in its write layer, on the orphaned container. You can inspect it and copy the files out. If a volume was mounted, the data stayed there and survives the rollback.
The root cause is filesystem-only storage: writing durable data inside the container. Durable data belongs in a mounted volume or an external service, a database or object storage. The image and container become disposable again.
The principle: a rollback restores code, never data. If a piece of data must survive a deployment, it must not live inside the container.