Trilio Data provides an elegant backup and recovery solution for scaleout Cassandra in VMware & OpenStack environment with key highlights as follows: -Discovers topology changes for accurate point in time backups -Speeds recovery by an order of magnitude as it takes an environmental and cluster-wide snapshot -Eliminates maintenance of inherently error-prone script based backups
Will be at the Cassandra summit next week if any of you would like a demo. Regards, Sanjay 508-335-2306 _________________ Sanjay Baronia VP of Product & Solutions Management Trilio Data (c) 508-335-2306 sanjay.baro...@triliodata.com<mailto:sanjay.baro...@triliodata.com> From: Maciek Sakrejda <mac...@heroku.com<mailto:mac...@heroku.com>> Reply-To: Cassandra Maillist <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Date: Friday, September 18, 2015 at 2:09 PM To: Cassandra Maillist <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Subject: Re: What is your backup strategy for Cassandra? On Thu, Sep 17, 2015 at 7:46 PM, Marc Tamsky <mtam...@gmail.com<mailto:mtam...@gmail.com>> wrote: This seems like an apt time to quote [1]: > Remember that you get 1 point for making a backup and 10,000 points for > restoring one. Restoring from backups is my goal. The commonly recommended tools (tablesnap, cassandra_snapshotter) all seem to leave the restore operation as a pretty complicated exercise for the operator. Do any include a working way to restore, on a different host, all of node X's data from backups to the correct directories, such that the restored files are in the proper places and the node restart method [2] "just works"? As someone getting started with Cassandra, I'm very much interested in this as well. It seems that for the most part, folks seem to rely on replication and node replacement to recover from failures, and perhaps this is a testament for how well this works, but as long as we're hauling out aphorisms, "RAID is not a backup" seems to (partially) apply here too. I'd love to hear more about how the community does restores, too. This isn't complaining about shoddy tooling: this is trying to understand--and hopefully, in time, improve--the status quo re: disaster recovery. E.g., given that tableslurp operates on a single table at a time, do people normally just restore single tables? Is that used when there's filesystem or disk corruption? Bugs? Other issues? Looking forward to learning more. Thanks, Maciek
