Thread: recovering database from a linux file system
All,
We recently had a server crash at my company which contained a program to monitor various network devices around the world. Of course the server was sitting in a dusty closet somewhere and the owner is long gone from the company, so we can't find where any backups were stored. At any rate, starting up the server reveals a completely locked down setup with no OS access. The only way to access the machine is over the network. Now, any access attempt over the network causes the machine to lock up/freeze. Trying to move the HDD to another machine only led us to the conclusion (later confirmed by the vendor) that the appliance is hardware-locked.
The vendor won't give us any way to access the machine and retrieve the DB, so I removed the HDD and connected it to my Linux laptop. I was able to grab all the DB files and copy them to my Windows desktop, where I then installed PostgreSQL 9.0 (to match the version that was on the server) with pgAdmin III. I changed the default directory to the folder containing the DB files using this tutorial: https://wiki.postgresql.org/wiki/Change_the_default_PGDATA_directory_on_Windows
...but when I try to start the DB after this, pgAdmin hangs for a few seconds, then gives the message "Starting Service....Done", but the server doesn't actually start and I can't access the DB. At this point, I'm guessing there may be some incompatibility between the default PostgreSQL implementation and whatever the vendor did when putting together their product. That being said, is there any way to resurrect a DB from its component files?
Thanks,
Alka Gupta
On 3/10/2016 12:05 PM, Alka Gupta wrote: > The vendor won't give us any way to access the machine and retrieve > the DB, so I removed the HDD and connected it to my Linux laptop. I > was able to grab all the DB files and copy them to my Windows desktop, > where I then installed PostgreSQL 9.0 (to match the version that was > on the server) with pgAdmin III. I changed the default directory to > the folder containing the DB files using this tutorial: > https://wiki.postgresql.org/wiki/Change_the_default_PGDATA_directory_on_Windows I would try installing postgres on linux, and try running it with a copy of this data directory. skip the pgadmin thing entirely as its just another layer of obfuscation, stick with CLI tools. -- john r pierce, recycling bits in santa cruz
Thank you John! Do you know if there is any encryption or security or will plainly copying the files will work? Do I need to know any db usernames and passwords, which obviously I don't have? -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of John R Pierce Sent: Thursday, March 10, 2016 12:10 PM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] recovering database from a linux file system On 3/10/2016 12:05 PM, Alka Gupta wrote: > The vendor won't give us any way to access the machine and retrieve > the DB, so I removed the HDD and connected it to my Linux laptop. I > was able to grab all the DB files and copy them to my Windows desktop, > where I then installed PostgreSQL 9.0 (to match the version that was > on the server) with pgAdmin III. I changed the default directory to > the folder containing the DB files using this tutorial: > https://wiki.postgresql.org/wiki/Change_the_default_PGDATA_directory_o > n_Windows I would try installing postgres on linux, and try running it with a copy of this data directory. skip the pgadmin thing entirely as its just another layer of obfuscation, stick with CLI tools. -- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
On 03/10/2016 12:25 PM, Alka Gupta wrote: > Thank you John! > > Do you know if there is any encryption or security or will plainly copying > the files will work? Do I need to know any db usernames and passwords, which > obviously I don't have? The files should not be encrypted. There will be database usernames and possibly passwords. I would assume the usual default superuser name postgres. To get around the password see pg_hba.conf: http://www.postgresql.org/docs/9.5/interactive/auth-pg-hba-conf.html In particular you want the below at the top of the entries, assuming you are connecting on from the same machine as the server: local all all trust The above says just trust anyone connecting over the local socket. Assuming you get in then: \du postgres role name | Attributes | Member of -----------+------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication | {} to verify you are superuser and then: select * from pg_shadow ; to see the users and whether they have passwords. > > > > -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org] On Behalf Of John R Pierce > Sent: Thursday, March 10, 2016 12:10 PM > To: pgsql-general@postgresql.org > Subject: Re: [GENERAL] recovering database from a linux file system > > On 3/10/2016 12:05 PM, Alka Gupta wrote: >> The vendor won't give us any way to access the machine and retrieve >> the DB, so I removed the HDD and connected it to my Linux laptop. I >> was able to grab all the DB files and copy them to my Windows desktop, >> where I then installed PostgreSQL 9.0 (to match the version that was >> on the server) with pgAdmin III. I changed the default directory to >> the folder containing the DB files using this tutorial: >> https://wiki.postgresql.org/wiki/Change_the_default_PGDATA_directory_o >> n_Windows > > > I would try installing postgres on linux, and try running it with a copy > of this data directory. skip the pgadmin thing entirely as its just > another layer of obfuscation, stick with CLI tools. > > > > -- > john r pierce, recycling bits in santa cruz > > > -- Adrian Klaver adrian.klaver@aklaver.com
On 3/10/2016 12:25 PM, Alka Gupta wrote:
> Do you know if there is any encryption or security or will plainly copying
> the files will work? Do I need to know any db usernames and passwords, which
> obviously I don't have?
plain copy should be fine, any encryption would be file system level,
and if it was so encrypted you wouldn't have even been able to /see/ the
files.
modify pg_hba.conf to have...
local all all trust
as the first non-comment line, and pooof, no security on the databases
for local direct connections.
there's nearly always a 'postgres' user which is the server owner, and
primary database administrator account. you should create a unix user
'postgres', and use this user to start the database server via...
pg_ctl -D /path/to/pg/data (other options if need) start
and you should see any startup problems displayed on the console. if the
server actually starts, then it should start logging to
$PGDATA/pg_log/..... and you might tail the newest of those files to
see whats going on.
Q: is the pg_hba.conf and postgresql.conf files in the data directory,
or was this a ubuntu/debian setup where they put them in /etc/pgsql/...
? if its a debian/ubuntu setup a bunch of things were moved
around, logging is in /var/log/... the config files are in /etc and
so forth.
--
john r pierce, recycling bits in santa cruz
Hi, Le 10/03/2016 21:10, John R Pierce a écrit : > On 3/10/2016 12:05 PM, Alka Gupta wrote: >> The vendor won't give us any way to access the machine and retrieve >> the DB, so I removed the HDD and connected it to my Linux laptop. I >> was able to grab all the DB files and copy them to my Windows desktop, >> where I then installed PostgreSQL 9.0 (to match the version that was >> on the server) with pgAdmin III. I changed the default directory to >> the folder containing the DB files using this tutorial: >> https://wiki.postgresql.org/wiki/Change_the_default_PGDATA_directory_on_Windows > > > I would try installing postgres on linux, and try running it with a copy > of this data directory. skip the pgadmin thing entirely as its just > another layer of obfuscation, stick with CLI tools. Yes. Also, make sure that you have the _same architecture_ than your dusty server, i.e. 32 bit vs. 64 bits, and maybe other "details". Since postgresql data files are *very* close to what happens in the server's RAM, a $PGDATA contents will not be readable on a different architecture. Which OS was your old dusty server running on? Regards (and courage!) Pierre -- ____________________________________________________________________________ Pierre Chevalier PChGEI: Pierre Chevalier Géologue Et Informaticien Partenaire DALIBO Mesté Duran 32100 Condom Tél+fax : 09 75 27 45 62 06 37 80 33 64 Émail : pierrechevaliergeolCHEZfree.fr icq# : 10432285 jabber: pierre.chevalier1967@jabber.fr http://pierremariechevalier.free.fr/pierre_chevalier_geologue ____________________________________________________________________________