vPostgres Database Backup in vCSA 5.5

With the new vSphere 5.5 release, the VMware vCenter Appliance (vCSA) has grown up to be a viable alternative to the traditional Microsoft Windows based vCenter deployment scenario. The new vCSA version supports up to 100 hosts and 3000 (with an external Oracle database the values change to 1000/10000) virtual machines, a big improvement from 5 hosts and 50 virtual machines in the previous version.

Sadly, the only external database option available for vCSA 5.5 is Oracle, which means there is still no external Microsoft SQL Server support. For those clients who don´t have an existing Oracle infrastructure, this might be a problem especially with regards to backup of the vCSA database.

The internal database in vCSA is a modified version of Postgres, that VMware has called vPostgres. Thankfully this also includes the native Postgres command to create database dumps, pg_dump.

In order to create a database dump of the vPostgres database, the following command needs to be run by opening a SSH connection to the vCSA:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
~ # /opt/vmware/vpostgres/1.0/bin/pg_dump EMB_DB_INSTANCE -U EMB_DB_USER -Fp -c > VCDBBackupFile

EMB_DB_INSTANCE and EMB_DB_USER are to be replaced with values from the /etc/vmware-vpx/embedded_db.cfg file

In my case, the exact command would be:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
~ # /opt/vmware/vpostgres/1.0/bin/pg_dump VCDB -U vc -Fp -c > /tmp/VCDBBackupFile

Note that EMB_DB_INSTANCE is replaced with VCDB and EMB_DB_USER is replaced by vc in the command above. Both values come from /etc/vmware-vpx/embedded_db.cfg

Off it goes, and creates a dump file in /tmp. So far so good, we have a database dump but how to we automate it?

Add a new file in /etc/cron.daily/ (for instance, use /etc/cron.hourly/ if that fits your RPO) called vcdbbackup.sh with the following content:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
/opt/vmware/vpostgres/1.0/bin/pg_dump VCDB -U vc -Fp -c > /tmp/VCDBBackupFile

Then we need to make the cron script executable by running:
[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
chmod u+x /etc/cron.daily/vcdbbackup.sh

And you should be ready to go! Of course, you should probably create the backup files somewhere else than in /tmp, and even mount a file share from another server in your environment and place the dump file there for safe keeping and further backup in your existing scheme. In addition to this, you can add other variables to the script like datestamping the file etc, but for now this is what I have done.

By doing backups of the vCSA in this manner, you can have a standby vCSA laying around in case of a primary vCSA failure. If that happens, fire up the standby one, ssh to it and restore the vPostgres dump. I won’t go into details on that right now, but the command for restoring looks like this:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]

Feature Request
What VMware should do for the next version of the vCSA is to add external Microsoft SQL Server support, but if that´s off the table for some reason, at least let us manage database dumps via the vCSA admin interface? Please create pre-defined scripts and crontabs, and let us manage those. It might not be as good as external database support, when it comes to backup, but a little goes a long way in protecting this valuable resource in your infrastructure.


Backing up and restoring the vCenter Server Appliance (vPostgres) database (2034505)


  1. when restoring would you use the PGPASSWORD of the hypothetically failed vCSA, or the PGPASSWORD of the vCSA you are restoring to?

    1. That would be the new password for the new instance. The password is used for the connection to the database you are restoring to, so it would have to be the new password.

  2. I thought this would be helpful, my script contains a mapping to a windows share, and appends the date to it. Before script, make a directory to mount the share to (mkdir /mnt/backups for example)

    now=$(date +”%F_%H_%M_%S”)
    mount -t cifs //server/share -o username=user,password=pass /mnt/backups
    /opt/vmware/vpostgres/1.0/bin/pg_dump VCDB -U vc -Fp -c > vmwarebackup$now

    then on the windows server, setup a batch file to run with task scheduler to delete backups older than 30 days:

    ROBOCOPY e:\backup e:\backuptemp /move /minage:30
    del e:\backuptemp\*.* /q
    rmdir e:\backuptemp /q

  3. I had some issues with Erik’s script. First..I can’t mount a CIFs share with my 5.5 U1 appliance. I kept getting an error suggesting I look at /sbin/mount.cifs but there is no such thing…only for NFS!! I had try this with NFS and it seems to function appropriately. Second…the quotes in the now variable didn’t show up right when my Windows box looked at the DB file. I mounted the NFS share in /etc/fstab

    I went with this:

    #now=$(date +%F_%H_%M_%S)
    service vmware-vpxd stop
    echo Sleeping for 15 seconds
    sleep 15
    echo Beginning backup
    now=$(date +%F_%H_%M_%S)
    /opt/vmware/vpostgres/1.0/bin/pg_dump VCDB -U vc -Fp -c ]]> /mnt/backups/backup/vmwarebackup$now
    echo Backup complete…starting services
    service vmware-vpxd start
    echo Sleeping for 15 seconds
    sleep 15

    Everything seems to work great! I only threw the sleep commands in for fun just so I could watch things easily during testing.

  4. Fantastic post, thank you !

    VMware knowledge base article 2034505 recommend stopping vpxd service before backing up. I suppose to prevent backing up the database in an inconsistent state (while vcenter operations are running).

    However the official PostgreSQL documentation precises :

    My questions are:
    •Do I need to stop VMWare Composer and vpxd services prior to backing up the DB ?
    •If not can I use cpio to back it up without stopping the services ? how ?

    FYI, I posted on :

    1. An old comment but worth a reply.

      I don’t believe you need to stop the vpxd service when backing up the vPostgreSQL DB as the pg_dump feature in postgres allows for consistent backups while still in use. As you mentioned by the doco.

Leave a Reply