Hi Jens, Looks like what you need is an "any point in time" recovery solution. I suggest that you go back to the snapshot that you issued that was closest to "20161102" and restore that snapshot using the bulk loader to a new table called "users_20161102". If you need to recover precisely to a particular timestamp, you might have to parse every row in the SSTable and filter out some rows.
Btw, we at Datos IO are working on exactly this solution. We have built a data protection software for scale-out databases called RecoverX. We also support Cassandra. One of the features that RecoverX supports is a repair free recovery/restore that allows you to go back any point in time. If you need more information, visit our website datos.io or drop us a note at i...@datos.io, joe.schwa...@datos.io. Hope this helps. Full disclaimer: I am an engineer at Datos.io. Regards, Rajath ------------------------ Rajath Subramanyam On Wed, Nov 2, 2016 at 3:10 PM, Jens Rantil <jens.ran...@tink.se> wrote: > Bryan, > > On Wed, Nov 2, 2016 at 11:38 AM, Bryan Cheng <br...@blockcypher.com> > wrote: > >> do you mean restoring the cluster to that state, or just exposing that >> state for reference while keeping the (corrupt) current state in the live >> cluster? > > > I mean "exposing that state for reference while keeping the (corrupt) > current state in the live cluster". > > Cheers, > Jens > > -- > Jens Rantil > Backend engineer > Tink AB > > Email: jens.ran...@tink.se > Phone: +46 708 84 18 32 > Web: www.tink.se > > Facebook <https://www.facebook.com/#!/tink.se> Linkedin > <http://www.linkedin.com/company/2735919?trk=vsrp_companies_res_photo&trkInfo=VSRPsearchId%3A1057023381369207406670%2CVSRPtargetId%3A2735919%2CVSRPcmpt%3Aprimary> > Twitter <https://twitter.com/tink> >
