You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present, the docker container does an in-place upgrade, with no capability for backing things up (just in case).
We should probably support some kind of useful, optional, backup capability.
So far, my initial thinking is to have some environment variable to define a new mount point (PGAUTO_BACKUPDIR or similar), and if that's set to a valid value pointing at an empty directory then we use it.
For the backup type, I reckon we should just go with a "full data copy" approach rather than a pgdump. At least for now.
It should (in theory) be reasonably simple. We'd use that "backupdir" as part of the pg_upgrade file moving process, running the pg_upgrade without the --link option so things aren't upgraded in place.
That way, the backup gets done, and the new database ends up in the correct directory. The downsides are the (potentially significant) extra space that gets used, and the extra time the whole upgrade process will take.
Optimally, we'd probably recommend people use a 2nd bind mounted directory for that "backupdir", so it's not a backup that disappears when the container stops.
Thoughts? 😄
The text was updated successfully, but these errors were encountered:
justinclift
changed the title
Ideas on how to do an optional backup?
Ideas for how to do an optional backup?
Jul 27, 2023
I think it makes sense to have a backupdir option and maybe an auto recover option, so if the upgrade fails it restores the backup into the original location.
At present, the docker container does an in-place upgrade, with no capability for backing things up (just in case).
We should probably support some kind of useful, optional, backup capability.
So far, my initial thinking is to have some environment variable to define a new mount point (
PGAUTO_BACKUPDIR
or similar), and if that's set to a valid value pointing at an empty directory then we use it.For the backup type, I reckon we should just go with a "full data copy" approach rather than a pgdump. At least for now.
It should (in theory) be reasonably simple. We'd use that "backupdir" as part of the pg_upgrade file moving process, running the
pg_upgrade
without the--link
option so things aren't upgraded in place.That way, the backup gets done, and the new database ends up in the correct directory. The downsides are the (potentially significant) extra space that gets used, and the extra time the whole upgrade process will take.
Optimally, we'd probably recommend people use a 2nd bind mounted directory for that "backupdir", so it's not a backup that disappears when the container stops.
Thoughts? 😄
The text was updated successfully, but these errors were encountered: