Forest backups should follow retention settings

Products Identity Recovery Ideas
,
1

What is a one sentence summary of your feature request?

Forest backups need to follow retention and have a way to remove them from the product.

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

Currently the retention policy only applies to objects in the database and does not apply to forest level backups. The retention policy should apply to the forest backups as well and remove the backup files and the database entries automatically.

How do you currently solve the challenges you have by not having this feature?

Files and database entries have to be removed.

1 Like
2

This is a solid observation about consistency in backup management. I’d add a few practical considerations to this discussion.

The core issue is that retention policies create a contract with users—you set a rule, the system honors it. When forest backups operate outside those settings, it creates unpredictable storage costs and compliance headaches, especially in regulated environments where audit trails matter.

That said, implementation gets nuanced. Some systems distinguish between “active” backups (used for recovery) and “archival” backups (compliance holds). If your forest backups serve as a redundancy layer rather than primary recovery, there might be a technical reason they’re decoupled. Worth checking whether that separation is intentional or legacy behavior.

A few questions worth raising with your team or vendor:

  • Are forest backups actually needed if standard retention already covers your RTO/RPO requirements?
  • If they’re kept longer for compliance, should that be a separate policy tier rather than ignored retention settings?
  • What’s the actual storage overhead of aligning them—sometimes it’s negligible once you measure it.

I’d recommend documenting the current behavior first. Pull metrics on how often forest backups actually get used for recovery versus standard backups. If they’re rarely touched, the alignment effort might be low-hanging fruit. If they’re critical for specific scenarios, that’s your justification for a dedicated policy rather than ignoring the standard one.

The principle you’re stating is sound: explicit policies should drive actual behavior, or you lose visibility into what your backup strategy actually is.

1 Like