Hello,
I'm writing scripts to automate some PostgreSQL database restore tasks based on pg_back.
Here's what my process roughly looks like.
I've implemented a script that lists the snapshots present on Object Storage:
$ ./scripts/list_postgresql_dump_backup_snapshots.sh myproject 2025-04-15T14:34:02Z myproject 2025-04-15T16:47:46Z otherproject 2025-04-15T14:44:46Z foobar 2025-04-15T14:45:50Z ...
I then have another script that restores a specific instance of PostgreSQL:
$ ./scripts/restore_myproject_postgres.sh "2025-04-17T08:05:07Z"
However, I'm encountering a problem, the dates of a "snapshot" may be different:
$ tree /var/backups/postgresql/ └── myproject ├── hba_file_2025-04-17T08:05:07Z.out ├── hba_file_2025-04-17T08:05:07Z.out.age ├── ident_file_2025-04-17T08:05:07Z.out ├── ident_file_2025-04-17T08:05:07Z.out.age ├── pg_globals_2025-04-17T08:05:07Z.sql ├── pg_globals_2025-04-17T08:05:07Z.sql.age ├── pg_settings_2025-04-17T08:05:07Z.out ├── pg_settings_2025-04-17T08:05:07Z.out.age ├── postgres_2025-04-17T08:05:08Z.dump └── postgres_2025-04-17T08:05:08Z.dump.age
In this example, 2025-04-17T08:05:07Z is different from 2025-04-17T08:05:08Z.
Why this difference? Because the following functions execute time.Now() independently:
Potentially, all files can have a different datetime.
What I propose in this issue is to generate a datetime with time.Now() at the start of the run function and then use this value in the dump, dumpGlobals, dumpSettings and dumpConfigFiles functions.
Tradeoff: the datetime indicated in the postgres_....dump file name would no longer be the precise date when pg_dump was started. I don't think this is very important.
What do you think?
I'm thinking of submitting a Pull Request later today.
Best regards,
Stéphane
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4