It’s unclear which supplier is which in the above two-supplier case, but if Duplicati calls pg_dump for you, “integrated into the software”, change to pg_dump may mean you will wait for Duplicati to fix then release. This seems hugely slower (but maybe easier) than your fixing a script. Releases are many months apart.
I agree with general idea that documented interfaces are more stable. That’s why I pointed to PostgreSQL documentation. If you worry about software changes from Duplicati, I doubt it would remove script abilities although it did add exit code handling (e.g. so one can call off a backup if setup is wrong). Documentation:
https://github.com/duplicati/duplicati/blob/master/Duplicati/Library/Modules/Builtin/run-script-example.sh
and also in your Duplicati installation. There’s also a batch file example there, but no PowerShell example, however I don’t know which Microsoft SQL you have, but I’d prefer to defer details until you open new topic where specifics get discussed, and people who use these DBs (I don’t) might notice and pitch in. Teasers:
Install the SQL Server PowerShell module
Backup-SqlDatabase
BACKUP (Transact-SQL)
SQL Server Backup, Integrity Check, and Index and Statistics Maintenance
probably refers to the “let-VSS-do-it” plan as opposed to the script or SQL based plan. For more on VSS,
Does Duplicati support MySQL / MSSQL server database backups? has comments about both methods. Possibly you can follow up there instead of starting a new topic. Or search for a better existing topic on it.
Back Up and Restore of SQL Server Databases gets into some of the different concepts and methods… Specialized commercial software seems to exist. I don’t know if it’s simpler or expects an expert to use it. Pricing is very high, approaching $1000/year. For those, target market is probably a well-funded business.