Re: where should I stick that backup?
От | Jose Luis Tallon |
---|---|
Тема | Re: where should I stick that backup? |
Дата | |
Msg-id | 8544ff14-2387-f690-d530-c83e15487f2d@adv-solutions.net обсуждение исходный текст |
Ответ на | Re: where should I stick that backup? (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On 10/4/20 21:38, Andres Freund wrote: > Hi, > > On 2020-04-10 12:20:01 -0400, Robert Haas wrote: >> - We're only talking about writing a handful of tar files, and that's >> in the context of a full-database backup, which is a much >> heavier-weight operation than a query. >> - There is not really any state that needs to be maintained across calls. >> - The expected result is that a file gets written someplace, which is >> not an in-memory data structure but something that gets written to a >> place outside of PostgreSQL. > Wouldn't there be state like a S3/ssh/https/... connection? ...to try and save opening a new connection in the context of a (potentially) multi-TB backup? :S > And perhaps > a 'backup_id' in the backup metadata DB that'd one would want to update > at the end? This is, indeed, material for external tools. Each cater for a particular set of end-user requirements. We got many examples already, with most even co-authored by this list's regulars... and IMHO none is suitable for ALL use-cases. BUT I agree that providing better tools with Postgres itself, ready to use --- that is, uncomment the default "archive_command" and get going for a very basic starting point --- is a huge advancement in the right direction. More importantly (IMO): including the call to "pgfile" or equivalent quite clearly signals any inadvertent user that there is more to safely archiving WAL segments than just doing "cp -a" blindly and hoping that the tool magically does all required steps [needed to ensure data safety in this case, rather than the usual behaviour]. It's probably more effective than just ammending the existing comments to point users to a (new?) section within the documentation. This comment is from experience: I've lost count of how many times I have had to "fix" the default command for WAL archiving --- precisely because it had been blindly copied from the default without further thinking of the implications should there happen any (deviation-from-expected-behaviour) during WAL archiving .... only to be noticed at (attempted) recovery time :\ HTH. Thanks, J.L.
В списке pgsql-hackers по дате отправления: