Feature Request: xlarchive retention by environment
PROBLEM
The xlarchive database has grown to a size where routine maintenance (backup, restore, encryption rotation) suffers unacceptable delays. Production releases (and optionally pre-production) must be retained at least 7 years for compliance, but the bulk of the database is non-production releases (Dev, Test, Test External, Test Hotfix) that carry no retention requirement and can be removed.
The existing archive cleanup only supports a fixed time-based cutoff -- it cannot distinguish production from non-production. We found no UI filter or API endpoint to isolate and delete archived releases by environment. Export is not suitable: production releases must remain in the database for easy access by non-technical colleagues.
REQUEST
1. Immediate cleanup
A supported method (API, script, or DB procedure) to selectively delete all non-production releases from xlarchive while keeping production (and optionally pre-production) intact and accessible via the UI. Please clarify risks/dependencies of removing xlarchive records -- or, if no supported method exists, a safe manual approach.
2. Archive lifecycle policies
Configurable retention per environment class, with automatic purge on expiry:
- Non-production (Dev, Test, Test External, Test Hotfix): 4 weeks, auto-purge
- Production (+ optional Pre-Production): 8 years, auto-purge
Requirements:
- Retention policy per environment class (prod / non-prod), configurable via UI and API
- Flexible units (days, weeks, months, years)
- Automatic purge on expiry, with an audit log of purge actions
- Optional: export-before-purge, dry-run/preview mode, grace-period notifications
RATIONALE
Without this, xlarchive grows indefinitely with releases that have no retention requirement, degrading maintenance operations and forcing manual, unsupported DB-level cleanup. A lifecycle feature fixes this permanently and enforces compliance retention automatically.
by: Florimond C. | 25 days ago | Administration
Comments
Thank you for the idea. We need to understand your actual setup:
1/ How many separate Release servers do you run - one per environment (Prod, Dev, Test, Test External, Test Hotfix), or one Release server with these organized as folders within it?
2/ For each Release server, is its Archive database a dedicated database of its own, or a schema shared with other Release servers' archive data? If neither of these matches, please let us know how you have it set up.
- If it's separate physical databases: this already gives you possibility to manage/clean up non-prod independently of Prod today - each Release server instance has its own maximumArchiveRetentionPeriod purge setting, scoped only to its own database. Have you already configured a shorter retention period on your non-prod instances, or are they still on default settings? If still default, this may be resolvable today with configuration.
- If it's a shared database with separate schemas: the same per-instance retention setting should still work correctly, provided each instance's database connection is properly scoped to only its own schema.
Thanks for looking into this. Answers below.
1/ Release servers: We run one Release server; all environment are all in the same folder for infrastructure reasons.
2/ Archive database: We run only one Release server, so we only have one single database.
Because production and non-production stages live in the same Release server (and folder) backed by one archive database, a single per-instance retention cutoff can't keep production for 7 years while purging non-production at 4 weeks: it would apply one cutoff to the entire database. Per-instance retention would only isolate prod from non-prod if each environment were its own server + database, which is not our layout.
That's why the request is for stage/environment-level (or any other arbitrary parameter) retention (part 2 of the original request) rather than an instance-level one.