[ 
https://issues.apache.org/jira/browse/CASSANDRA-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140247#comment-13140247
 ] 

T Jake Luciani commented on CASSANDRA-3428:
-------------------------------------------

bq. the snapshot files plus incrementals from after the last full snapshot (up 
to point-in-time, if desired) give you exactly what you want, no more, no less.


Maybe I'm thinking about this wrong but If I was going to backup data in 
cassandra I would never run nodetool snapshot.  I would only enable incremental 
backup and remote backup the sstable and remove what's been backed up. 
I could then get to any point in time.  

You are saying I should cron snapshot the cluster then keep the incremental 
between..  I think with the feature I'm suggesting this wouldn't be necessary 
and IMO be less data to backup in the end.


                
> add constituent tracking to sstables
> ------------------------------------
>
>                 Key: CASSANDRA-3428
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3428
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: T Jake Luciani
>              Labels: compaction
>             Fix For: 1.1
>
>
> Compaction merges older sstables into newer versions of the data.
> When snapshotting sstables (esp incrementally) it would be very useful to 
> know what older sstables are no longer needed because they are now 
> represented in a newer version.
> This patch should add the list of sstables that made up each new sstable and 
> store this info in the -Statistics file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to