We also run a nightly "nodetool snapshot" on all nodes, and use duplicity
to sync the snapshot to S3, keeping 7 days' worth of backups.
Since duplicity tracks incremental changes this gives you the benefit of
point-in-time snapshots without duplicating sstables that are common across
multiple back
On Wed, Jul 23, 2014 at 4:12 PM, Hao Cheng wrote:
> 3. Using a backup system, either manually via rsync or through something
> like Priam, to directly push backups of the data on ephemeral storage to S3.
>
https://github.com/JeremyGrosser/tablesnap
=Rob
On Thu, Jul 24, 2014 at 12:47 PM, Hao Cheng wrote:
> Thanks for your response!
>
> We're planning using the r3.large instances, they seem to offer the best
> price/performance for our application (the cheapest way to get both 15GB of
> RAM and SSD storage). Unfortunately cost wise we can't justif
Thanks for your response!
We're planning using the r3.large instances, they seem to offer the best
price/performance for our application (the cheapest way to get both 15GB of
RAM and SSD storage). Unfortunately cost wise we can't justify having
beefier instances with satisfactory cluster sizes at
On Thu, Jul 24, 2014 at 12:12 AM, Hao Cheng wrote:
> Hello,
>
> Based on what I've read in the archives here and on the documentation on
> Datastax and the Cassandra Community, EBS volumes, even provisioned IOPS
> with EBS optimized instances, are not recommended due to inconsistent
> performance
