Create automated process to truncate all the processed_crashes and raw_crashes tables older than 2 weeks.

That sounds problematic if we want to use them for more intricate analysis. We'd need at least 6 months of data available for that, probably. Same if we use them to power metadata tabs of crash reports etc.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #1) > That sounds problematic if we want to use them for more intricate analysis. > We'd need at least 6 months of data available for that, probably. Same if we > use them to power metadata tabs of crash reports etc. Metadata will be driven by S3 crashstorage going forward. Looking forward, we should look at how longer term analysis needs relate to the other work being done to decommmisioning crash-analysis. The size of the database is simply too large (more than 2TB) with 6 months of processed and raw crashes to be supportable in S3 and directly connected to our production instance of crash-stats.

6 months of data will be available from the api, but it may not all be available in postgres via direct access. This is already the case, postgres disk space constraints have prevented us from keeping a full 6 months for a while now.

Commits pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/da687ec9b4a37becedd2213baa72cad14afc4813 Fixes bug 1117911 crontabber to truncate raw/processed crash partitions >2 weeks https://github.com/mozilla/socorro/commit/3f90827d8249d20bb874038cb47a1608ce6efecf Migration for bug 1117911 https://github.com/mozilla/socorro/commit/b9de3c01e15fa66b0ef466b156d1951a7ce6c244 Merge pull request #2571 from selenamarie/bug1117911-trunc-json-crashes-2weeks Fixes bug 1117911 crontabber to truncate raw/processed crash partitions >2 weeks