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
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).
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.