9.3.2
Table Of Contents
- Using VMware vFabric Postgres
- Contents
- Preface
- VMware Customizations for PostgreSQL
- Installing vFabric Postgres
- vFabric Postgres Client Tools and Libraries
- Managing vFabric Postgres
- Migrate PostgreSQL Data from Earlier Versions Into vFabric Postgres 9.3
- Migrate PostgreSQL Data Into vFabric Postgres
- Restarting the vFabric Postgres Service
- Connection to a vFabric Postgres Database
- Accounts and Services
- Safeguarding Data
- About vFabric Postgres Replication
- Create a Replication User Account
- Create a Replica Server
- Promote a Replica Database to Primary Database
- Monitoring Replication Status
- Using Perl and Python Language Extensions
- Viewing Performance Statistics
- Troubleshooting Guidelines
- Using the Graphical User Interface
- Index
n
The pg_rman utility does not support taking backups from streams using only a network connection.
The backup folder must be mounted locally. However, you can take snapshots of the Virtual Machine
Disk (VMDK) containing your backups and export them.
Incremental Backups
Incremental backups capture the changes to the database after the incremental backup is taken. Incremental
backups initially use less storage than external backup files and take just a few minutes regardless of
database size.
Incremental backups are stored in files called delta files or delta disks on the same data store as the
database.
The following are points to consider about using snapshot backups.
n
Because incremental backups reside on the same data store as the database, they do not protect against
data loss due to failure of the data storage.
n
As the database changes, the changes require more and more space on the virtual disk. That space is
generally more expensive than backup storage.
n
The recovery process from incremental backups is not faster than the recovery process from an external
backup.
Archive Backup
If archive backup is enabled, a write-ahead log (WAL) continuously records every change made to the
database while the database is running. In the event of a failure, you can replay the WAL to restore the
database to its state at a point in time within the retention period of the database backups.
The WAL logs are archived and are subject to a retention period that you set. The time range for archive
recovery is from the time of your oldest backup to the present. The oldest backup can be an external backup
or an incremental backup.
When using the virtual appliance archiving is enabled by default. The partition dedicated to WAL archives
is 2 GB of the 10 GB backup partition.
n
Because every change to the database is recorded, archive backups require additional storage.
Depending on how large your database is and how many transactions occur during the WAL archive
retention time, the amount of storage needed can be large.
Start with a conservative storage allocation. You cannot decrease the storage allocation, but you can
increase it. Monitor the size of the archive backup logs until you understand the workload and storage
needed, and adjust the storage amount.
You can specify whether to suspend the database or automatically increase the log retention period if
the archive backup runs out of space.
n
If you generate more archive files than the archive partition can sustain (2 GB of the 10 GB backup
partition by default) between two archive backups, you will not be able to recover your data (even from
old snapshots) as vFabric Postgres gives priority to the newest WAL files by deleting the oldest ones
when archiving WAL files from server.
n
Archive backups have a performance impact on the database. The impact depends on the size of the
database and the volume of database activity.
n
When you enable archive backups, vFabric Postgres creates a baseline external backup.
Using VMware vFabric Postgres
30 VMware, Inc.