问题
This is a general Postgres backup and restore method question, based on the following use case for a non production server (i.e. a local testing server).
I have a ~20gb database that I will mangle during the testing of a php script that will result in the need to drop it and recreate it quite often.
Running dumped SQL to restore it takes quite a lot of time, and I'm on a tight deadline, so I wondered if there was a method whereby I could speed up the process. I thought the following may work:
Create and populate the database initially
Copy its data files to a secondary location
mangle the database with my testing.
delete the data files and the copy the copies back restoring the original state.
But I don't know where to start or if there's some internal stuff happening that would prevent this from working.
Is the above possible, if so how is it achieved?
This isn't a closed question, if there are faster alternatives to what I'm asking for, please enlighten me. I'm open to suggestions.
Thanks.
回答1:
Your fastest solution is probably to just do this via the file system.
Stop the server and make a local copy of your entire database cluster, i.e. everything under $PGDATA, inclusive. Start the server and do your mangling. When you need to refresh your database, stop the server and copy the files back in from your backup location. Note that this affects the entire cluster, so you cannot do this if other databases in the same cluster are in production use: everything is frozen in the state it was in when you first made the backup.
The alternative is to use pg_dump in binary mode, but probably quite a bit slower than the manual method. It is the only solution if other databases in the cluster need to be preserved.
回答2:
You can't swap out some files, or just one database within a cluster, because the transaction IDs and the pg_clog that keeps track of committed / rolled back transactions are global. So if you copy an old file back into a PostgreSQL database it'll likely cause all sorts of chaos - PostgreSQL might've discarded its knowledge about the old transaction IDs it didn't need to remember anymore, and suddenly you've resurrected them.
As Patrick said, you can do a file system level copy and restore, but you must do so for the whole database cluster (entire datadir), not just some files. The manual describes this in more detail.
(Patrick's answer is correct, I'm just explaining why you can't do it the way you thought).
来源：https://stackoverflow.com/questions/22503185/is-it-possible-to-restore-a-postgres-database-by-simply-swapping-out-some-files