Thread: how to recover database back from /data folder
hi to all last time my redhat 9 is corrupt so at that time itake backup of my postgresql database /data folder 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@banasdairy.coop
On 12/10/06, yogesh@banasdairy.coop <yogesh@banasdairy.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@banasdairy.coop > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
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)
Thanks,
----------
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On 12/10/06, Rajesh Kumar Mallah < mallah.rajesh@gmail.com> wrote:
On 12/10/06, yogesh@banasdairy.coop <yogesh@banasdairy.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@banasdairy.coop
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.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