Dependency Track backup strategies

[Lonzak]

I am right now investigating what a good data backup strategy for DT would look like. There are the following influencing factors:

1. Currently DT supports H2 (but not recommended for production use), MySQL, MSSQL and Postgres. In future this list will shrink to only postgres:

"Support for H2, Microsoft SQL Server, and MySQL will be dropped in Dependency-Track v5. From then onwards, the project will focus on PostgreSQL. When setting up a new instance of Dependency-Track v4.x, consider using PostgreSQL."

2. Although Postgres is a neat DB in our company MariaDB is standard and our admins have the know-how to backup, maintain and troubleshoot this database type. They won't / can't do it for Postgres. To use DT with MariaDB is off the table due to 1) and the manual steps involved. I could still use Postgres, however then I am responsible for the backup, the maintenance of the database what I am trying to avoid since I also do not have the knowledge...

So I would be interested how other users handle(d) this?

My thoughts so far:

1. Don't care about backup - if the system crashes or becomes unusable, set it up from scratch and the SBOMs will be uploaded automatically by the build pipeline.
   => This however has several drawbacks: The history would be gone, the settings and the vulnerability handling
2. Still use H2 and if DT v5 comes out solve the problem then
3. Use Postgres and do not backup the DB but the whole VM. But what is recommended here: Can I use the docker-compose Postgres? But probably the settings are not production ready?

Thanks your sharing your thoughts,
Lonzak