Frequently Asked Questions¶
How can I avoid destroying a database?¶
If you’d like to avoid accidentally restoring a production database, for example,
set settings.PGCLONE_ALLOW_RESTORE
to False
.
Hooks can also be used to fail the dump or restore process. For example, one could fail a dump in a hook if the hook notices that it’s data that isn’t anonymized.
If storage or lengthier restore times are not a concern, you can also configure Reversible Restores to happen by default, allowing you to restore back to the previous version if it was a mistake.
pg_restore
shows errors but succeeded. What happened?¶
When running python manage.py pgclone restore
, you may see some error output from
pg_restore
. Some errors are legitimate and affect the database from being restored, while
others may be benign. For example, RDS restores often report errors that are meaningless and
simply cannot be suppressed.
Migrations run by default during restores unless the pre-swap hooks are overridden. Successful
migrations are usually a good way to ensure a pg_restore
was actually successful. We’re still
working on better ways to address this issue.
How do I migrate to version 2.0?¶
Version 2 changes the configuration hierarchy and dump key formats. Keep the following in mind when migrating from version 1:
settings.PGCLONE_DUMP_CONFIGS
andsettings.PGCLONE_RESTORE_CONFIGS
were merged intosettings.PGCLONE_CONFIGS
. Configs closely map to the options allowed by all the commands. See Configurations.Dump keys are now in the format of
<instance>/<database>/<config>/<timestamp>.dump
. If you’d like to use old dumps, setsettings.PGCLONE_VALIDATE_DUMP_KEYS
toFalse
. Old dump keys aren’t compatible with the--instances
,--configs
, or--databases
options forls
.Users no longer need to install and configure
django-pgconnection
forsettings.DATABASES
. You can remove this dependency and no longer wrap the database settings.