Database backups and recovery

A backup gives you an earlier copy of the database. Point-in-time recovery adds the ability to recover to a supported time between backups, using retained transaction history. Neither helps if you choose a point after the mistake you are trying to undo.

Fluffy enables automated backups for managed Cloud SQL instances. The configuration you can add is point-in-time recovery. It belongs to the database server's provider policy in the workspace, not to a runtime grant or an individual table.

#Understand recovery points

Imagine a backup completed at 02:00, your application wrote new records at 09:00, and a faulty operation deleted them at 12:00. Restoring the backup loses the later writes. Recovering to just before the deletion can preserve them, if the required history is available.

Use the controls below to compare the outcomes. The times are illustrative; they are not Fluffy's backup schedule or a promise about a real instance's recovery window.

# fluffy-chainsaw.workspace.yaml
resourceTypes:
  databaseServers:
    postgres:
      product: gcp.cloud-sql.postgres
      addons:
        gcp:
          availabilityType: ZONAL
          pointInTimeRecovery: false

#Availability is a separate concern

High availability helps an application keep running through infrastructure failures. Recovery helps reconstruct earlier data. An accidental SQL deletion can affect the data on an otherwise healthy, highly available database.

For Fluffy's managed Cloud SQL product, REGIONAL availability requires point-in-time recovery enabled. This is a checked configuration constraint, not just a recommendation. ZONAL is valid with recovery enabled or disabled.

#The policy belongs to a server

All logical databases under one server share the Cloud SQL instance. A shared workspace resource type can also supply several servers. Editing that type can therefore affect more than the one database you were thinking about.

Use a separate type for a different recovery policy, or a supported environment override when the difference belongs to an environment. Preview the selected application/environment to see which instance will change.

#Configure point-in-time recovery

#Set the workspace policy

In fluffy-chainsaw.workspace.yaml, add the recovery addon to the database server type selected by your application:

resourceTypes:
  databaseServers:
    postgres:
      product: gcp.cloud-sql.postgres
      addons:
        gcp:
          availabilityType: ZONAL
          pointInTimeRecovery: true

This is an excerpt. Keep the type's existing sizes and other policy. If your server selects a differently named type, edit that type instead of adding an unused postgres type.

An environment can select the type through its database server defaults:

environments:
  prod:
    databaseServers:
      defaults:
        type: postgres
        provider: application

The application provider must already identify the intended GCP project and region. A server with an explicit type or more specific environment policy may resolve differently; inspect the resulting plan.

#Preview and apply

For an application named example-app and a configured prod environment:

fluffy-chainsaw deploy --application example-app --environment prod --check
fluffy-chainsaw deploy --application example-app --environment prod

The first command produces a non-mutating preview. Inspect it before running the second. A policy edit or successful preview does not enable recovery on a live instance. See Deployment for provider credentials and the complete deployment workflow.

#Verify protection before relying on it

Inspect the exact Cloud SQL instance from the accepted deployment. Confirm its automated-backup and point-in-time recovery settings, look for a successful backup, and inspect the provider's available recovery interval. Enabling a setting does not instantly create a complete historical recovery window.

Record the instance identity and practice a restore to an isolated destination. Check representative rows and application invariants in the recovered data. Decide how the application will connect to the recovered destination before an incident forces that decision.

Cloud SQL owns backup scheduling, retention, restore operations, and their provider costs. Fluffy's current addon does not expose custom backup schedules, retained-backup counts, or transaction-log retention. Use the Cloud SQL backup documentation for those provider settings.

#Restore a database

Cloud SQL point-in-time recovery creates a new instance. Choose the source instance and a timestamp inside its available recovery window. The provider's clone flow lets you select an earlier point in time; follow Google's recovery procedure for the current Console or CLI steps.

After the provider finishes, verify the recovered data and application compatibility before cutover. Fluffy does not automatically adopt the restored instance or redirect the existing deployment to it. Do not replace resource identities by editing checkpoint files. Plan any ownership/binding and connection changes through the supported deployment model, then verify the application against the intended instance.

A recovery point after the faulty operation reproduces that faulty state. A point before legitimate recent writes excludes those writes. Choosing the timestamp is a data decision as well as an infrastructure operation.

#Reference: supported policy and defaults

#Rejected configuration

availabilityType accepts only ZONAL or REGIONAL. Cloud SQL availability and recovery addons cannot be attached to an unrelated product such as object storage. An invented application backup, backupEnabled, or retentionDays field is not a supported way to configure database recovery.

backupEnabled is an internal planned-state field, not an authored manifest setting. Do not copy internal state fields into the application manifest.

#Existing servers

For an existing: true server, its owner manages backups and recovery. Referencing it does not transfer its lifecycle to Fluffy. Inspect that instance's actual policy rather than assuming the managed-instance defaults apply.

#Things this feature does not do

PITR does not recover history outside the provider's retained window, authorize a user to read application data, roll back an application's deployment, or reproduce external side effects such as emails or payments. Coordinate those application effects separately when choosing and validating a recovery point.

Premium's optional hosted backup of Resource Access records is a different feature. It does not back up your PostgreSQL tables.

Return to Databases for runtime access and migration configuration, or run the complete database example.