ERR Operation against a key holding the wrong kind of value during Redis schema migration

Goal: Determine a reliable strategy to revert Redis data to its previous state after a failed schema change that triggers the "ERR Operation against a key holding the wrong kind of value" error.

Constraints: Redis MULTI/EXEC does not roll back; any preceding queued commands still execute on failure, and there is no built‑in snapshot/restore mechanism within a transaction. Manual backups (BGSAVE, RDB) add operational overhead and must be tested for large datasets, while idempotent migration scripts require careful design to avoid partial updates.

Questions: What are the trade‑offs between manual backup/restore and idempotent migration scripts for schema changes in Redis? How can applications detect and handle the wrong‑kind‑of‑value error to guarantee consistency without relying on transaction rollback? Is there a pattern using Redis Functions or modules that can provide atomic schema migration with automatic compensation on failure?