Restore

$ databudgie [--strict] restore

The restore command will download files and restore them into the database. databudgie will iterate over the restore.tables and insert the CSV contents into the tables in order of appearance.

The column headers in the CSV will be used to match the contents of the file to the columns in the table. This allows for leaving columns with default values unset if you are restoring data to a different table than which it was copied from.

restore:
  url: postgresql://postgres:postgres@localhost:5432/postgres
  manifest: public.databudgie_manifest
  tables:
    public.product:
      location: s3://my-s3-bucket/databudgie/public.product
      strategy: use_latest_filename
      truncate: true
    public.sales:
      location: s3://my-s3-bucket/databudgie/public.sales
      strategy: use_latest_filename
      truncate: true

DDL

By default, databudgie assumes the target tables already exist and only executes the DDL creation commands if restore-side ddl options are enabled. Generally it would only make sense to enable ddl options if the backup-side ddl options are also enable, although the inverse is not necessarily true.

See the DDL config section for more details.

Note

DDL restoration for restore in particular is more challenging and prone to issues than backup. Due to foreign keys, indices, and references to other objects (like types) you’re more likely to encounter issues restoring from DDL.

While any restore-time ddl issues are considered bugs, if you’re performing a full-database restore it can sometimes be easier to use the vanilla tooling (pg_dump, migrations) to restore DDL rather than using the DDL functionality of databudgie.