When a snapshot is taken, it includes a "schema.cql" file. That should be sufficient to restore whatever you need to restore. I'd argue that neither automatically resurrecting a dropped table nor silently failing to restore it is a good behavior, so it's not unreasonable to have the user re-create the table then choose if they want to re-drop it.
On Tue, Feb 19, 2019 at 7:28 AM Hannu Kröger <hkro...@gmail.com> wrote: > Hi, > > I would like to bring this issue to your attention. > > Link to the ticket: > https://issues.apache.org/jira/browse/CASSANDRA-14336 > > Basically if a table contains dropped columns and you try to restore a > snapshot to a new cluster, that will fail because of an error like > "java.lang.RuntimeException: Unknown column XXX during deserialization”. > > I feel this is quite serious problem for backup and restore functionality > of Cassandra. You cannot restore a backup to a new cluster if columns have > been dropped. > > There have been other similar tickets that have been apparently closed but > based on my test with 3.11.4, the issue still persists. > > Best Regards, > Hannu Kröger >
