Re: how to recover database back from /data folder

Is it the same version of PostgreSQL you have installed again? more if you
can tell the exact error on the starting database server, that might help as
well... also make the permission on the data folder are all good as it were
before

Thanks,
----------
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)

On 12/10/06, Rajesh Kumar Mallah <mallah(dot)rajesh(at)gmail(dot)com> wrote:
>
> On 12/10/06, yogesh(at)banasdairy(dot)coop <yogesh(at)banasdairy(dot)coop> wrote:
> > hi to all
> > last time
> > my redhat 9 is corrupt so at that time itake backup of my postgresql
> database
> > /data folder
>
> Yogesh,
>
> Backup of postgresql is done by a specific process.
> Simply copying /data ( PGDATA) is not the way (generally)
> have you been doing pg_dump or pg_dumpall for your database
> regularly ?
>
> http://www.postgresql.org/docs/8.0/static/backup-file.html
>
> 22.2. File system level backup
>
> An alternative backup strategy is to directly copy the files that
> PostgreSQL uses to store the data in the database. In Section 16.2 it
> is explained where these files are located, but you have probably
> found them already if you are interested in this method. You can use
> whatever method you prefer for doing usual file system backups, for
> example
>
> tar -cf backup.tar /usr/local/pgsql/data
>
> There are two restrictions, however, which make this method
> impractical, or at least inferior to the pg_dump method:
>
> 1.
>
> The database server must be shut down in order to get a usable
> backup. Half-way measures such as disallowing all connections will not
> work (mainly because tar and similar tools do not take an atomic
> snapshot of the state of the file system at a point in time).
> Information about stopping the server can be found in Section 16.6.
> Needless to say that you also need to shut down the server before
> restoring the data.
> 2.
>
> If you have dug into the details of the file system layout of
> the database, you may be tempted to try to back up or restore only
> certain individual tables or databases from their respective files or
> directories. This will not work because the information contained in
> these files contains only half the truth. The other half is in the
> commit log files pg_clog/*, which contain the commit status of all
> transactions. A table file is only usable with this information. Of
> course it is also impossible to restore only a table and the
> associated pg_clog data because that would render all other tables in
> the database cluster useless. So file system backups only work for
> complete restoration of an entire database cluster.
>
>
>
> >
> > so after two days i restall the redhat 9
> > than i try to copy old /data folder over newly /data folder
> >
> > but it does not start postgresql service
> > so please any one give me solution
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by BanasDairy Mailserver , and is
> > believed to be clean.For any query contact at
> > system(at)banasdairy(dot)coop
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> > message can get through to the mailing list cleanly
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>