I was responsible for deleting/re-inatalling the cert. I was attempting to get Shibboleth (a federated authentication service that also uses the cert) running and didn’t realize that PG relied on it.
The dumpAll file wasn’t actually deleted but was empty. I’ll look into that mystery once I get the database back in place. -Shawn > On Feb 15, 2017, at 9:01 AM, Adrian Klaver <adrian.kla...@aklaver.com> wrote: > > On 02/15/2017 08:35 AM, Shawn Thomas wrote: >> Yes, that’s the correct sequence of scripts. And no there’s not anything >> really helpful in the system logs. >> >> I’m thinking that at this point I need to approach this problem as more of a >> disaster recovery. There was a full pg_dumpall file that was deleted and >> cannot be recovered so I need to recover the data from the >> /var/lib/postgresql/9.4/main directory. I believe this is called a file >> level recovery. I assume I need to use a fully functional, same version PG >> (on another machine?) to create a full dump of the data directory. Once I >> have this I can re-install Postgres on the initial server and read the >> databases back into it. > > I have to believe that if you cannot get the server to start then the data > directory is no shape to recover from. And if the data directory is good and > it is the program files that are corrupted then it would be a matter of > reinstalling Postgres. In either case the most important thing to do would be > to make a copy of the data directory before you do anything else. > > What exactly happened that caused the ssl cert and the pg_dumpall file to > deleted? > > In other words what else got deleted? > >> >> Any advice on how to best go about this? The official documentation seems a >> bit thin: >> >> https://www.postgresql.org/docs/9.4/static/backup-file.html >> >> I’ve only worked with normal (pg_dump, pg_dumpall) backups in the past. >> >> -Shawn >> >>> On Feb 15, 2017, at 6:35 AM, Adrian Klaver <adrian.kla...@aklaver.com> >>> wrote: >>> >>> On 02/14/2017 08:47 PM, Shawn Thomas wrote: >>>> No it doesn’t matter if run with sudo, postgres or even root. Debian >>>> actually wraps the command and executes some some initial scripts with >>>> different privileges but ends up making sure that Postgres ends up >>>> running under the postgres user. I get the same output if run with sudo: >>>> >>>> sudo systemctl status postgresql@9.4-main.service >>>> <mailto:postgresql@9.4-main.service> -l >>>> Error: could not exec start -D /var/lib/postgresql/9.4/main -l >>>> /var/log/postgresql/postgresql-9.4-main.log -s -o -c >>>> config_file="/etc/postgresql/9.4/main/postgresql.conf” >>>> >>> >>> >>> So you are talking about: >>> >>> /etc/init.d/postgresql >>> >>> which then calls: >>> >>> /usr/share/postgresql-common/init.d-functions >>> >>> Or is there another setup on your system? >>> >>> Any relevant information in the system logs? >>> >>>> Thanks, though. >>>> >>>> -Shawn >>> >>> >>> -- >>> Adrian Klaver >>> adrian.kla...@aklaver.com >> > > > -- > Adrian Klaver > adrian.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
