[
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