Thread: Disaster recovery (server died)
Hi, the worst have ocurred, my server died (cpu), so i reinstalled another server with the same postgres version.
I have the old data directory from the old server, how can i restore my databases from this directory to the new one?
I dont have a backup (pg_dump,etc), just the main previus live data directory from the old server.
best regards
I have the old data directory from the old server, how can i restore my databases from this directory to the new one?
I dont have a backup (pg_dump,etc), just the main previus live data directory from the old server.
best regards
On Friday 19 June 2009, Miguel Miranda <miguel.mirandag@gmail.com> wrote: > Hi, the worst have ocurred, my server died (cpu), so i reinstalled > another server with the same postgres version. > I have the old data directory from the old server, how can i restore my > databases from this directory to the new one? > I dont have a backup (pg_dump,etc), just the main previus live data > directory from the old server. > best regards Just copy it into place where the new postmaster expects to live. -- WARNING: Do not look into laser with remaining eye.
Miguel Miranda wrote: > Hi, the worst have ocurred, my server died (cpu), so i reinstalled > another server with the same postgres version. > I have the old data directory from the old server, how can i restore my > databases from this directory to the new one? > I dont have a backup (pg_dump,etc), just the main previus live data > directory from the old server. > best regards First, make a copy. DO NOT USE your backup until done. :) Now then, assumin *nix; stop the postgresql daemon, copy the data directories into place and restart the daemon. Be sure to restore your config files like pg_hba.conf and such while the daemon is stopped. If your backup is in a consistent (or recoverable) state, you should be golden. For more specific instructions, post your OS and PgSQL versions. Best of luck! Madi
Well, i just didnt explain in detail, what i have is just the 16897 directory where i was storing the database, i tried just copying the files but it didnt work,
should it be posible to import this database is any way?
the Os is Freebsd 6.2 and PG version is 8.1.3
thank you.
should it be posible to import this database is any way?
the Os is Freebsd 6.2 and PG version is 8.1.3
thank you.
On Fri, Jun 19, 2009 at 3:46 PM, Madison Kelly <linux@alteeve.com> wrote:
First, make a copy. DO NOT USE your backup until done. :)Miguel Miranda wrote:Hi, the worst have ocurred, my server died (cpu), so i reinstalled another server with the same postgres version.
I have the old data directory from the old server, how can i restore my databases from this directory to the new one?
I dont have a backup (pg_dump,etc), just the main previus live data directory from the old server.
best regards
Now then, assumin *nix;
stop the postgresql daemon, copy the data directories into place and restart the daemon. Be sure to restore your config files like pg_hba.conf and such while the daemon is stopped.
If your backup is in a consistent (or recoverable) state, you should be golden. For more specific instructions, post your OS and PgSQL versions.
Best of luck!
Madi
Miguel Miranda wrote: > Well, i just didnt explain in detail, what i have is just the 16897 > directory where i was storing the database, i tried just copying the > files but it didnt work, > should it be posible to import this database is any way? > > the Os is Freebsd 6.2 and PG version is 8.1.3 > thank you. I am not familiar with FreeBSD's directory structure, so if someone pipes up, take their word over mind. However; Your backups, what is the root directory(ies)? Ie: Did you backup '/var/lib/postgresql', '/etc/postgres*', ? You should be able to stop postgres, use a tool like 'rsync' to copy the data back into place, then restart postgres. Something like: /etc/init.d/postgresql stop rsync -av /backup/var/lib/postgresql /var/lib/ rsync -av /backup/etc/postgres* /etc/ /etc/init.d/postgresql start At this point, you should be golden. Not that it matters now, but why had you not been using pg_dump to do periodic backups? How big is the database? lastly, depending on the value of the database, you may want to look at hiring someone to help you. Also, make sure you are recovering to the same versions of the OS and PostgreSQL that you old server had. This is not the time to be doing an upgrade. :) Madi
On Fri, Jun 19, 2009 at 8:43 PM, Miguel Miranda<miguel.mirandag@gmail.com> wrote: > Well, i just didnt explain in detail, what i have is just the 16897 > directory where i was storing the database, i tried just copying the files > but it didnt work, > should it be posible to import this database is any way? Nope, you need the whole data directory.
On Friday 19 June 2009, Scott Marlowe wrote: > On Fri, Jun 19, 2009 at 8:43 PM, Miguel > > Miranda<miguel.mirandag@gmail.com> wrote: > > Well, i just didnt explain in detail, what i have is just the 16897 > > directory where i was storing the database, i tried just copying the > > files but it didnt work, > > should it be posible to import this database is any way? > > Nope, you need the whole data directory. What I don't get is this: you said your CPU died. For me that's the processor or maybe some interpret that as the main board. So why don't you grab the harddisk from that server and plug it into the new one? Maybe something might be corrupt due to the failure, but most of the data should be on the disk (unless you use disks which lie about fsync). Yep - another reason why one has at least a daily backup (in my case 2 replicas for every production server I run. I never had a major failure in over 15 years - knock on wood - but if that happens I don't lose a heck of a lot due to the backups and slony replicas) Uwe
On Sat, Jun 20, 2009 at 12:45 AM, Uwe C. Schroeder<uwe@oss4u.com> wrote: > What I don't get is this: you said your CPU died. For me that's the processor > or maybe some interpret that as the main board. > So why don't you grab the harddisk from that server and plug it into the new > one? x 2 Should work fine. In fact this is essentially what we do to produce new machines, in that we use ghost There may be some driver issues but they should be straightforward. -- “Don't eat anything you've ever seen advertised on TV” - Michael Pollan, author of "In Defense of Food"
Uwe C. Schroeder wrote: > On Friday 19 June 2009, Scott Marlowe wrote: >> On Fri, Jun 19, 2009 at 8:43 PM, Miguel >> >> Miranda<miguel.mirandag@gmail.com> wrote: >>> Well, i just didnt explain in detail, what i have is just the 16897 >>> directory where i was storing the database, i tried just copying the >>> files but it didnt work, >>> should it be posible to import this database is any way? >> Nope, you need the whole data directory. > > What I don't get is this: you said your CPU died. For me that's the processor > or maybe some interpret that as the main board. > So why don't you grab the harddisk from that server and plug it into the new > one? Maybe something might be corrupt due to the failure, but most of the > data should be on the disk (unless you use disks which lie about fsync). > Yep - another reason why one has at least a daily backup (in my case 2 > replicas for every production server I run. I never had a major failure in > over 15 years - knock on wood - but if that happens I don't lose a heck of a > lot due to the backups and slony replicas) > > > Uwe For smaller databases, I run nightly pg_dumps to a file with the day of the week number appended to the dump file. This way my nightly backups grab the day's changes and my database sits in a nice plain text file. For larger databases, I either stop PostgreSQL and rsync *all* the Postgres files then restart or, if stopping isn't an option, use LVM and make snapshots. A third option is to have PostgreSQL sit on a DRBD partition. However, if the DRBD link is only 1 GBit, it will be noticeably slower on writes, but if that's okay it can be a solution useful for more than just PostgreSQL. A few options for people who feel replication is not feasible. :) Of course, when you can, it is the best option. You never lose anything that way. Madi