POSTGRES SQL backup setup question

Hi Ladislav,

For PostgreSQL, you need Commvault File System Core, File System Agent, and PostgreSQL Agent.
https://documentation.commvault.com/v11/essential/getting_started_with_postgresql.html
 

You will then have two methods of backing up PostgreSQL instances, by using the DumpBasedBackupSet, which uses pg_dump, or by using FileSystemBasedBackupSet, which leverages file system backups of the PostgreSQL Data Directory, and then backup up PG WAL files, which need to be enabled on the DB level.

Both have their own advantages and use cases. Let me know if you have any question on that.

Kind regards,

Alex

I assume your network looks like this.
CS and MA → Proxy Gateway ← Client.

The only port open above is 8403 on the Proxy.
https://documentation.commvault.com/2023e/expert/network_gateway_in_perimeter_network.html

Create two groups, Proxied_Clients and Proxies. Then go to topologies, either in the Commcell Console, or Manage → Network → Network Topologies and create a new Network Gateway Topology.

The top group should be Proxied_Clients, the middle group should be Proxies, and the third should be MyCommServe Computer and Media Agents.



When Push Installing via a Remote Software Cache, the remote cache client, in this case I believe your FREL, will need to be able to connect to the target client via SSH for the original FS Core install.
root@frel# /opt/commvault/Base/cvping client 22

This should work. And when you push install to the client, you need to add the client to the Proxied_Clients group during the push install wizard.

Then, you need the following commands to work.
root@client# /opt/commvault/Base/cvping frel 8403

user@CS> ‘C:\Program Files\Commvault\ContentStore\Base\cvping frel 8403

user@MA> ‘C:\Program Files\Commvault\ContentStore\Base\cvping frel 8403
 

You can view the Port requirements here.
https://documentation.commvault.com/v11/essential/port_requirements_for_commvault.html


For PostgreSQL communication, everything happens locally on the client, on Unix Sockets, which means, if you have any custom pg_hba.conf settings, you need to add a local md5 connection for the CV user.

UPDATE: We have managed to install the Core package and the client is “ready” in the commserve, but we are unable to push the FS and postgres packages from the commserve. The installation just fails after 10 minutes of attempting, so there is also some trouble..we have to look at it deeper.

I made a package on FREL for FS core and postgres agent. Copied to the client and installed it. Then I tried to push FS agent but the push hanged.. the strange thing is that the agent from the client side can be listed with commvault list and its there. On the other hand the check readiness fails for the client. I am confused now as form the client side everything looks good, processes are up, but from the commserve I am unable to restart its services or check its readiness. From the commserve I can see installed softwares are FS core and postgres. It makes no sense at all. I will try to setup the postgres backup with the DB team and we will see if it will work or not.

 Yes, its strange, but from the client it looks ok.

commvault status

 Version = 11.32.29
 Media Revision = 1191
Cvd Port Number = 8403
[ Package ]
 1002/CVGxBase = File System Core
 1101/CVGxIDA = File System
 1209/CVGxPostGres = PostGres
[ Physical Machine/Cluster Groups ]
 Name = dxy1
  - Client Hostname = dxy1.com
  - Job Results Directory = /opt/commvault/iDataAgent/jobResults

[root@dxy1]# ps -ef | grep comm
root     1623028       1  0 Mar12 ?        00:00:02 /opt/commvault/Base/cvlaunchd
root     1623029       1  0 Mar12 ?        00:03:06 /opt/commvault/Base/cvd
root     1623030       1  0 Mar12 ?        00:00:07 /opt/commvault/Base/cvfwd
root     1623032       1  0 Mar12 ?        00:00:31 /opt/commvault/Base/ClMgrS

I have checked from Comcell java and its showing all 4 modules you listed.

[redacted data]
 

Hi, yes I missed that. I couldnt find the delete button or anything like that :/

Support helped me to remove the message :) I will let you know the output from your answer. Thank you so much for your help so far. :)

Hello

I did as you wrote. Copied the FW congig from the comcell console and added the commserve to /etc/hosts. Also edited the properties to use the commserve hostname. In the log I can see this error now in the fw.log on the client.

3179128 308278 03/14 10:40:27 ######## ########
3179128 308278 03/14 10:40:27 ######## ######## ERROR: cvfwd_process_tunnel_ports(): Unable to bind IPv4 socket for listening to tunnel connections on port 8403: Address already in use
3179128 308278 03/14 10:40:27 ######## ######## ERROR: cvfwd_process_tunnel_ports(): Will retry in 60s
3179128 308278 03/14 10:40:33 PT:00002 CN:00012 [local->COMMSERV:8400] Successfully completed client connection {06bdf3c2-69e4-be07-ee75-} via proxy COMWISP
3179128 308278 03/14 10:40:33 PT:00001 CN:00013 [local->COMMSERV:8400] Successfully completed client connection {049c81b8-8570-6a1e-6dc5-} via proxy COMWISP2
3179128 308278 03/14 10:40:45 ######## ######## Reporting the client ONLINE
3179128 308278 03/14 10:40:45 ######## ######## CS is ONLINE
3179128 308278 03/14 10:41:28 ######## ######## Trying to bind to tunnel ports again
3179128 308278 03/14 10:41:28 ######## ######## ERROR: cvfwd_process_tunnel_ports(): Unable to bind IPv4 socket for listening to tunnel connections on port 8403: Address already in use
3179128 308278 03/14 10:41:28 ######## ######## ERROR: cvfwd_process_tunnel_ports(): Will retry in 60s
3179128 308278 03/14 10:42:27 ######## ######## Trying to bind to tunnel ports again
3179128 308278 03/14 10:42:27 ######## ######## ERROR: cvfwd_process_tunnel_ports(): Unable to bind IPv4 socket for listening to tunnel connections on port 8403: Address already in use

The ‘fail to bind’ port is normal when you restart the service, because there is already another cvfwd and cvd hogging 8403 and 8400. In a second terminal, you can ‘netstat -tulnp | grep 84’ or ‘ss -tulnp | grep 84’ to see the bound ports and the processes that are using them. Maybe you can even do something like `watch -n 1 ‘netstat -tulnp | grep 84’` to not have to repeatedly run the command manually.

You do not have to do it, but if you notice other processes binding on 8400 and 8403, that would not be good. I am pretty sure it is just the previous PID of Commvault.

Sometimes the error for failing to bind on the IP address is when /etc/hosts does not contain the loopback entry ‘127.0.0.1 localhost’. Commvault uses ‘localhost’ when binding, and with it absent, you might get weird behavior. Typically you see no connections until localhost is resolved, but sometimes Commvault might manage to bind on some address and have intermittent connectivity.

From the next set of logs, something seems a bit wrong to me. 

I missed it when you initially configured it, but now it makes more sense.

CVD should be 8400, not 8403, and CVFWD should be 8403. I suspect CVFWD fails to bind 8403 because CVD is binding it. I would reinstall Commvault and not configure any custom ports, just leave the port empty when asked for it.

Otherwise, you can edit a few ports manually here and there, with the CV Services stopped, ‘commvault stop’. I would suggest you reinstall, but you can try changing the ports. The reason for reinstalling is that it is possible the CommServe might not get updated with the new registered ports for the client.


grep nCVDPORT /etc/CommVaultRegistry/Galaxy/Instance001/Session/.properties
grep nCVFWD_TUNNEL_PORT4 /etc/CommVaultRegistry/Galaxy/Instance001/Runtime/.properties
grep PORT /etc/CommVaultRegistry/Galaxy/Instance001/Firewall/.properties
grep tunnel_ports /opt/commvault/Base/FwConfig.txt

The nCVDPORT should be 8400 in Session, and nCVFWD_TUNNEL_PORT4 8403 in Runtime. 8403 for tunnel_ports in FwConfig.txt. The PORT in Firewall registry might not show you anything, like 8403, you might only get BOOLEAN values when you grep for PORT in Firewall/.properties.