Nightly restic backup takes nine hours and the repo grew 400GB in a month Backups

For the nine hours, check whether you are running forget with prune in the same window. Prune on a large remote repository is enormously slower than the backup itself and it is easy to have scheduled them together. Splitting prune to weekly took my nightly job from six hours to 40 minutes.

Time the phases so you know what is slow: scanning for changes, uploading, or the index work at the end. If scanning dominates, the metadata cache on the client is probably being lost between runs, which happens a lot inside containers with no persistent volume for the cache directory.

The database dumps, near certainly. A full dump written as a fresh file every night deduplicates badly because compression changes the byte layout of the whole file even when 99 percent of the data is identical. If they are compressed dumps, that is your 400GB. Two fixes: dump uncompressed and let restic handle the compression and dedup, or use a format that produces stable output. People are always surprised how much a 10GB nightly dump costs over a month.

Whatever you change, do a restore test afterwards. A backup you have never restored is a hypothesis.

One financial note since you are on object storage: check whether your provider charges per API request. A nightly job on millions of small files can cost more in requests than in storage, and it does not show up until the bill.