[Apps] Make sure backup and restore covers deleted datasets

Thank you for submitting this feature request! To better accommodate and gauge community interest for future versions of TrueNAS we have moved the submission process to our TrueNAS Community Forums. If this feature is still important and relevant for consideration, please refer to the links below on how to submit it for community voting and TrueNAS roadmap review.

Feature Requests Forum:
https://forums.truenas.com/c/features/12

Feature Requests FAQ:
https://forums.truenas.com/t/about-the-feature-requests-category-readme-first/8802

PV/PVC is actually for real userdata, even more so: statefull sets (almost always used for databases) depend on it for their per-pod VCTs.

Thats how they are used everywhere, from all the big CNCF projects, to bitnami/vmware.

The difference with hostPath is the fact they are managed by kubernetes, capable of creating and destroying them on demand.

The reason this causes dataloss on App pvc deletion is the deliberate choice, by iX Systems, to disable retention to prevent an endless growing amount of PVs.

This would generally be “okey”, however the design choice of making your own API for rollbacks, backups and restores (that does not take this into account) and the lack of compatibility to with industry standard backup solutions for kubernetes (restore wont play nicely with the apps system), leads to a situation where usersare getting pvc related dataloss but do not have much options to fix it, unless they executed our “local replication backup strategy”.

As far as im aware, the same issue above is also present with “iXVolumes”, as that, basically, emulates a PVC in these regards.

So:
It looks like your making calls here based on a fundemental misunderstanding what PVCs are and are-for.

I don't care what is your personal opinion here from the moment you start making false accusations.

There is no data loss issue here. There is no bug in the code. There are things that could be done to prevent "data loss" due to bug on your part? Sure. Is it a bug? No, by definition it is not. So watch your tongue when you're accusing iXsystems of deliberately looking away when it comes to not fixing bugs with respect to data loss. This will not be tolerated.

The most important of all, users real data live in datasets in the pool and that are used via hostPath, not PV/PVCs that go away when you delete an App.

If you're being reckless developing Apps that are touching said hostPaths, thats entirely on you and you have no right to come accuse us of anything.

I don't think personal attacks are the solution here. The issue here is the dataloss suffered by users as a result of the (in)action on this ticket, not my person or your person.
As far as i'm aware, I still have the freedom to draw my own conclusions (nor did I say you literally said anything).

But yes, moving a dataloss issue to a suggestion, does mean you don't actually value its severity, otherwise it would've been given a status (bug, feature etc) that puts it on the work-queue, instead of suggestions that require a decision/vote/both before even being considered for development.

don't put words in my mouth unless you're looking to get banned here too.