Doc Text:
|
Cause:
engine-backup used pg_dump's default, which is to dump (also) ownership of objects and grants on them to other users.
Consequence:
If the dump included grants to users that existed on the backed up database, but do not exist on the database we restore to, restore will fail.
Fix:
engine-backup now does not backup or (try to) restore any ownership/grants, so only the defaults apply (each db user owns the objects in its schema, and no other user has access to them).
Result:
restore now succeeds even if the database that was backed up had extra users with grants on one or more of the applications' objects. These are not restored, and the user should manually reconfigure these if relevant.
Note to doc team:
In 3.3 (only), dwh setup asked whether to create a read-only db user allowing remote access to the dwh database.
In 3.4 and later, we did not have similar functionality.
In 3.2, we also didn't have it, but we did have instructions [1] about how to do that manually. I now see that we also have them in 3.5 [2].
We might want to write something similar for 3.4+, perhaps as a KB article.
Note that 3.4 requires a bit more manual configuration than 3.5 - 3.5 configures postgresql.conf 'listen_address=*', which 3.4 does not.
In any case, as explained above, such users, whether created manually or by 3.3's dwh-setup (which was later upgraded), are not backed up or restored by engine-backup.
[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Allowing_Read_Only_Access_to_the_History_Database.html
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-History_Database.html#Allowing_Read_Only_Access_to_the_History_Database
|