Known Issues in Greenplum Database Related to Backup and Restore

Post date: Jan 24, 2014 2:2:22 AM

Greenplum Database Version 3.0

1. Issue (21838)

When restoring sets of tables with the Greenplum Database utility gpdbrestore, the table schemas must be defined in the database. If a table’s

schema is not defined in the database, the table is not restored. When performing a full restore, the database schemas are created when the tables

are restored.

Workaround: Before restoring a set of tables, create the schemas for the tables in the database.

2. Issue (20822)

Special characters such as !, $, #, and @ cannot be used in the password for the Data Domain Boost user when specifying the Data Domain Boost credentials with the gpcrondump options --ddboost-host and --ddboost-user.

3. Issue (19493, 19464, 19426)

The gpcrondump and gpdbrestore utilities do not handle errors returned by DD Boost or Data Domain correctly.

These are two examples:

1. If invalid Data Domain credentials are specified when setting the Data Domain Boost credentials with the gpcrondump utility, the error message does not indicate that invalid credentials were specified.

2. Restoring a Greenplum database from a Data Domain system with gpdbrestore and the --ddboost option indicates success even though segment failures occurred during the restore. Workaround: The errors are logged in the master and segment server backup or restore status and report files. Scan the status and report files to check for error messages.

4. Issue (19278)

When performing a selective restore of a partitioned table from a full backup with gpdbrestore, the data from leaf partitions are not restored.

Workaround: When doing a selective restore from a full backup, specify the individual leaf partitions of the partitioned tables that are being restored.

Alternatively, perform a full backup, not a selective backup.

5. Issue (15692, 17192)

Greenplum Database’s implementation of RSA lock box for Data Domain Boost changes backup and restore requirements for customers running SUSE.

The current implementation of the RSA lock box for Data Domain Boost login credential encryption only supports customers running on Red Hat Enterprise

Linux.

Workaround: If you run Greenplum Database on SUSE, use NFS as your backup solution. See the Greenplum Database System Administrator Guide for information

on setting up a NFS backup.

6. Issue (18850)

Data Domain Boost credentials cannot be set up in some environments due to the absence of certain libraries (for example, libstdc++) expected to reside on the

platform.

Workaround: Install the missing libraries manually on the system.

7. Issue (18851)

When performing a data-only restore of a particular table, it is possible to introduce data into Greenplum Database that contradicts the distribution policy of that table.

In such cases, subsequent queries may return unexpected and incorrect results. To avoid this scenario, we suggest you carefully consider the table schema when

performing a restore.

8. Issue (14640)

gpdbrestore outputting incorrect non-zero error message. When performing single table restore, gpdbrestore gives warning messages about

non-zero tables however prints out zero rows.

9. Issue (17285)

NFS backup with gpcrondump -c can fail. In circumstances where you haven't backed up to a local disk before, backups to NFS using gpcrondump with the -c option can fail. On fresh systems where a backup has not been previously invoked there are no dump files to cleanup and the -c flag will have no effect.

Workaround: Do not run gpcrondump with the -c option the first time a backup is invoked from a system.

10. Issue (16519)

Limited data restore functionality and/or restore performance issues can occur when restoring tables from a full database backup where the default backup

directory was not used. In order to restore from backup files not located in the default directory you can use the -R to point to another host and directory. This is not possible however, if you want to point to a different directory on the same host (NFS for example).

Workaround: Define a symbolic link from the default dump directory to the directory used for backup, as shown in the following example:

1. Perform a full Database Backup to a specific NFS directory:

$ gpcrondump -x <db_name> -z -u /backup/DCA-93 -a

2. Create a file listing the segment servers:

$ vi /home/gpadmin/segments

sdw1

sdw2

sdw3

….

3. Remove the relevant date folder from db_dumps directories on the master and

segments:

$ rm -r /data/master/gpseg-1/db_dumps/20120619

$ gpssh -f segments 'rm -r

/data1/primary/gpseg*/db_dumps/20120619'

$ gpssh -f segments 'rm -r

/data2/primary/gpseg*/db_dumps/20120619'

4. Create a symbolic link between the master and segment directories and the

directory to which you backed up in step 1. Only the master and sdw1 was

shown here, write a script for the remaining segments:

$ ln -s /backup/DCA-93/db_dumps/20120619

/data/master/gpseg-1/db_dumps/20120619