Both pg_dump and pg_basebackup are supported ways to backup the database #221
Conversation
There are pros and cons to both logical and physical backups and in fact people should probably plan on doing both types of backups. Physical/pg_dump for table or database exports for testing, upgrades, and for disaster recovery. It's slower but generally smaller. Logical/pg_basebackup for cluster backups and versatility to restore from point in time or from standbys. It's also much faster. See also: https://www.enterprisedb.com/postgresql-database-backup-recovery-what-works-wal-pitr
There was a problem hiding this comment.
It looks like this may have been related to when we had multiple database for embedded ansible awx. That is no longer valid.
The admins will need to perform this when upgrading postgres versions. So discouraging them from doing a necessary operation is unwise.
Since this PR only removes an incorrect warning, I vote yes.
|
Could this have anything to do with HA? |
@bdunne Yes. I think it's more a question of how granular do you want your DR solution to be. Basebackup will capture all of the HA configuration along with region replication configuration and our data but also offer point in time recovery so it's far more extensive in terms of what it offers. But, it assumes you can rebuild the environment exactly as before with the same hostnames/ipaddresses and that you'll be using the basebackup backup on the same version. So, if you want a full DR solution, it's superior, but it's also more complicated because you have to be familiar with using basebackup and recovering to the specific time you want. I think that's outside the scope of what we can advise them on. pg_dump is pretty simplistic in that it's not a complete backup but it's easier to use and provide guidance on. I think both are valuable to use but far easier for us to give suggestions with pg_dump. |
Fixed - Fix sporadic test failure [#204] - Remove MIQ specific gem source [#209] - Double escape @ in realm to avoid shell interpretation [#211] - Move gem name loader to proper namespaced location [#208] - Separate kerberos from service principal name and use correctly [#215] - Add manageiq user to allowed_uids for sssd [#220] - Remove warning about using pg_dump [#221] - Fix specs where AwesomeSpawn private interface changed [#224] - Change the Name of the CA from something to ApplianceCA [#228] - Fix YAML.load_file failing on aliases [#234] Added - Make backward compatible changes to work with repmgr13 - version 5.2.1 [#192] - Support Ruby 3.0 [#206] - Support Ruby 3.1 [#227] - Allow rails 7 gems in gemspec [#226] Changed - Update to Highline 2.1.0 [#201] - Clean up test output (highline and stdout messages) [#210] Removed - Drop Ruby 2.7 [#223]
There are pros and cons to both logical and physical backups and in fact people should probably plan on doing both types of backups.
Physical/pg_dump for table or database exports for testing, upgrades, and for disaster recovery. It's slower but generally smaller.
Logical/pg_basebackup for cluster backups and versatility to restore from point in time or from standbys. It's also much faster.
See also:
https://www.enterprisedb.com/postgresql-database-backup-recovery-what-works-wal-pitr