There are several different questions involved here so I'll try and pick them apart to provide answers.
We are currently on vSphere 5.5 ion Windows with SQl backend and plan to move to vSphere 6.5 appliance (vCHA) 6.5U1c. We currently rely on SQL to perform our backups which also has transaction logs so vCenter DB is backed up regularly every 15 minutes.
I'd like to have something similar in place for when we move across to vPostgres but my colleague feels a once a day backup of the VM is sufficient and I realise it all boils down to how risk savy you are and also how you see things. I personally feel taking a backup of your database for vCenter (as well as SRM and vROPS when we move to vPostgres for that) is not enough. After all, we can potentially lose a great deal of information in a day including perf stats, permissions changes, VM changes etc. and we would not be in a position to even work out what change took place because I work in a very large organisation with 10 vCenter servers, 3,500 virtual machines, more than 190 hosts and more than 7,000 staff.
I would like to know the opinion out there so I can accept defeat and agree or put a strong argument for more regular backups. One of my remaining tasks is to also ensure Commvault can actually provide what we need as we are currently on v10 with the plan to upgrade to v11 soon. For starters, CommVault v10 is not particularly good at restoring files for system state although I realise this is another topic altogether.
Since you're using CommVault right now with vCenter 5.5 on Windows, you're probably using the iDA on maybe the SQL side and possibly the vCenter Server side as well. When you upgrade to 6.5 on the vCSA, your identity is pulled it and external SQL is converted to internal vPostgres. This you already know. When that occurs, there is no supported mechanism to install any backup-related agents inside the appliance and nor should you. When vPostgres writes data it does so first to redo logs before being committed into the database. Because of this, VADP-based backups of the entire appliance is the preferred mechanism to protect the vCSA. If a restore were to be necessary, restoring the entire appliance allows vPostgres to replay those logs into the database after the last checkpoint occurred, so it's not even necessary to periodically back up vPostgres. If you wanted to backup the vCSA using an incremental schedule multiple times a day, that would be fine to avoid an RPO of 24 hours if that's too long.
Another ability provided by vCSA 6.5 is the file-based backup built-in to the VAMI over port 5480.
As you can see, there are several options as far as protocols supported, and use of this file-based backup also dumps the database. While there is no scheduler built-in, there are several scripts and posts out there where folks have created this internally.
Bottom line, when you migrate to vCSA, back up the appliance regularly using VADP and supplement that using file-based backups if you wish. Both are supported and both allow restoration of the entire state of the appliance.
Also, what systems are people actually to back things up? There is a KB that VMWare provides but having spoken to them they told me sysAdmin is the way to go. A general level ticket was logged but the support was not too good.
Are you asking about what backup applications are most people using? If not, please clarify.
Also, what about scheduled backups for the external PSCs? We will have two at each site and I realize this is can also be backed up manually but scheduling backups is not so easy if you were previously on Windows and not familiar with Cron etc.I realize we have resiliency and with a load balancer this can be be automated but backups are still important.
External PSCs can also be backed up at the appliance level and restored if necessary. However, if you already have replication going on, this doesn't give you much as you can easily bring up a new PSC and join it to have it get a replicated state from the surviving PSC. If you wish to only back up one, that would work. Best practice would be to use DRS and sDRS anti-affinity rules to separate the PSCs so failure of compute or storage does not render both unavailable.