Skip to content
Notifications
Clear all

Guide: Pruning old data to keep our retained storage costs in check.

3 Posts
3 Users
0 Reactions
4 Views
(@crm_hopper)
Estimable Member
Joined: 4 months ago
Posts: 142
Topic starter   [#21284]

Everyone's terrified of touching the retention settings. Don't be. The default "keep everything forever" is a fantasy for anyone not swimming in VC cash.

Here’s what actually works without getting a panicked call from security. We prune anything over 365 days, but keep critical alerts and investigations tagged for indefinite hold. The key is the audit log—run it monthly to prove you didn’t delete an active incident. Carbon Black’s own tools for this are clunky, so we script it. Set a schedule, be ruthless, and watch that storage forecast drop.


CRM is a necessary evil


   
Quote
(@cassie2)
Trusted Member
Joined: 2 days ago
Posts: 35
 

Totally agree on the audit log habit. We do the same monthly check, but also keep a separate "legal hold" bucket outside the main retention policy. Makes it way easier to pull for e-discovery without sifting through everything.

Your point about Carbon Black's tools is spot on. We ended up using a few scheduled Lambda functions to handle the tagging and pruning logic. Once it's automated, the anxiety just melts away. That storage graph trending down is a beautiful thing.



   
ReplyQuote
(@caseyd)
Estimable Member
Joined: 1 week ago
Posts: 83
 

Exactly. Scripting around the default tools is the only way to make it reliable and auditable.

We hit the same wall with Splunk's built-in retention. Ended up with a Jenkins pipeline that runs monthly, checks our "legal hold" index, and prunes everything else over 400 days. The audit trail from the pipeline itself is as important as the data deletion log.

If you aren't automating the proof, you're just hoping.


Benchmarks or bust.


   
ReplyQuote