Skip to main content

Database backups

You can use the Database Backups app to create and restore database backups of non-production and production planets.

Note:

Access to this application can be managed by:

Backup types

There are three types of database backups:

  • Permanent

    Permanent backups are created manually and retained until you delete them.

  • Temporary

    Temporary backups are created manually and removed automatically after the retention period ends.

  • Scheduled

    Scheduled backups are created automatically and then removed after the retention period ends.

Note:

After a backup is created, you can't change the backup type.

Backup mechanisms

You can back up your databases using one of the following mechanisms:

pg_dumpSnapshot
AvailabilityDefault for every planet.Only for planets assigned to an individual AWS Aurora Postgres cluster (snapshot-enabled).
Stability while restoring a databaseStable for databases smaller than 500 GB.Stable for all databases.
Backup timeDepends on the size of the database.Fixed, less than 10 minutes.
Restore time- Depends on the size of the database.
- It has no influence on the deployment time which depends on your individual InsuranceSuite configuration.
- Fixed, 30–50 minutes.
- It has no influence on the deployment time which depends on your individual InsuranceSuite configuration.
Number of parallel restores- For databases smaller than 500 GB, you can restore many backups in one RDS cluster.
- For databases larger than 500 GB, you can restore only one backup in one RDS cluster.
No restrictions. You can restore many snapshots at once.
Planet to restoreAny planet within a star system.Only planets that are snapshot-enabled.

Retention period

The retention period determines for how many days your database backups are kept.

The following rules apply:

  • By default, the maximum retention period is 14 days.
  • To modify the maximum length of this period or configure different values for each star system, contact Guidewire. The maximum length of the retention period that you can request is 365 days.
  • You can define the length of the retention period when creating a temporary or scheduled backup.
  • You can't change the length of the retention period for an already existing backup.

Database settings

You can check the following database settings:

To check the database settings for a planet:

  1. Select a star system.
  2. From Apps , select Planets or select it from your pinned apps.
  3. Select a planet.
  4. From Applications and add-ons, select InsuranceSuite.
  5. Go to Settings.

Database settings in the Settings tab.

Block database drop for a planet

Note:

By default, the Block database drop option is set to:

  • Off for development and pre-production planets.
  • On for production planets.

When the Block database drop option is set to Off, the database is deleted during the following activities:

  • Deployment of InsuranceSuite apps.

    For deploying InsuranceSuite apps, a Drop database checkbox is displayed, so you can choose if you want to deploy with or without dropping the database. If you choose to drop the database, the existing database is deleted and a new database is created immediately.

  • Undeployment of InsuranceSuite apps.

  • Deleting of InsuranceSuite apps.

When the Block database drop option is set to On:

  • You can't delete or undeploy InsuranceSuite apps.

  • You can only deploy InsuranceSuite apps without dropping the database.

Tip:

To change the setting for Block database drop, edit the infrastructure settings.

RDS cluster assignment

Every planet is assigned to an AWS Postgres Aurora cluster. The following rules apply:

  • By default, planets share a common cluster.

    More planets can be added to this cluster.
    For such planets, the only possible backup mechanism is pg_dump.

  • Snapshot-enabled planets have individual assignments to clusters.

    A snapshot-enabled planet is the only planet assigned to a cluster. To guarantee that a planet is snapshot-enabled at all times, the RDS cluster should be dedicated. For dedicated clusters, no other planet can be assigned.

    For details, see:

You can check the reason for which a planet was assigned to a dedicated cluster. Dedicated cluster assignment can have one of the following reasons:

  • Add-on

    For InsuranceSuite add-ons, such as Solr (Advanced Search).

  • Dry run

    For testing apps against a backup of the production database.

  • Performance

    For performance testing.

  • Production

    This is a production planet.

Database settings with the assigned cluster, and the Dedicated and the Reason fields highlighted.

Check snapshot status

To check if your planet is snapshot-enabled:

  1. Select a star system.

  2. From Apps , select Planets or select it from your pinned apps.

  3. Select a planet.

  4. From Applications and add-ons, select InsuranceSuite.

  5. Select Settings and go to the Database settings tile.

  6. Check the status in RDS cluster assignment and Snapshot mechanism.

    If your planet is snapshot-enabled, the RDS cluster assignment shows the name of the assigned cluster and the Snapshot mechanism is Enabled.

    RDS cluster assignment and Snapshot mechanism status highlighted.

Make a planet snapshot-enabled

A planet is snapshot-enabled when it's assigned to a dedicated RDS cluster. To get a dedicated RDS cluster, submit a case in Guidewire Community.

Important:

A dedicated RDS reduces the Credit amount from your annual Credit subscription. For more information about the cost of dedicated RDS clusters, see additional materials on Guidewire Cloud - Platform Packaging and Pricing.

Data deletion

By deleting a backup or dropping a database during a deployment, you ensure that the data is no longer available.

Note:

Deleting a backup doesn't guarantee complete deletion of data from Cloud Platform infrastructure. To ensure recoverability, Guidewire might store internal backups for up to 35 days.

When you restore a snapshot backup, the recoverability period resets from 35 to 2 days for the whole RDS cluster. Then each day, the recoverability period increases by 1, up to 35 days again. This process repeats each time when you restore a snapshot backup.