I think we need to have documentation about the snapshots, what they are and when / how they are used.
https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Operations_Network/3.2/html/Admin_and_Config/storage-backup-restore.html mentions snapshots briefly and also explains that snapshots are taken nightly, but stops here. We need to add information, that they could e.g. be deleted after stored on magnetic tape and/or how long to keep them around.
+++ This bug was initially created as a clone of Bug #1074633 +++
+++ This bug was initially created as a clone of Bug #1074632 +++
Description of problem:
Snapshots are generated weekly during scheduled maintenance and when nodes are (un)deployed. A snapshot consists of hard links to SSTable files; consequently, it takes up little disk space. But when an SSTable is deleted during compaction, space will not be reclaimed if the SSTable is included in a snapshot. This can add up over time. There is currently nothing in place for managing snapshots. Here are a few possible options,
1) Move snapshots older than X to a specified location
2) Move all snapshots to a specified location
3) Delete snapshots older than X
4) Move N snapshots (from oldest to youngest) to a specified location
5) Delete N snapshots (from oldest to youngest) to a specified location
This could be done as a reoccurring operation. We could also introduce some new metrics to monitor snapshot disk usage similar to what we already have for the data directories. If the disk usage exceeds a threshold, we can fire an alert and perform one of the above actions. This is another good step we should take for providing storage node disk management.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
(In reply to Heiko W. Rupp from comment #0)
> I think we need to have documentation about the snapshots, what they are and
> when / how they are used.
This was already done in the https://bugzilla.redhat.com/show_bug.cgi?id=1098071.
Thanks bkramer - I will close this one as dup then.
*** This bug has been marked as a duplicate of bug 1098071 ***