You are looking for point in time recovery (for them awkward moments when you forget the where clause "delete from customers")
Barman sounds like a good way to go. Barman uses built in Postgres functionality but makes managing the base backups and WAL logs a lot easier (backup and WAL log cataloger, Point in time recovery manager, manage many servers from 1 location)
Your suggested strategy sounds fine, you can set the backup location in the barman conf to point at your NAS, you can then set the archive_command in postgresql.conf to rsync WAL's to your NAS as they are rotated.
There is documentation on their website http://docs.pgbarman.org/#introduction
Most likely, you have both Postgresql 8.4 and Postgresql 9.2 installed on this server.
Prior to pg9.0, the RPM packages for postgresql were configured such that you could only have one version installed at a time. Upgrading the RPM replaced the old version with the new.
From pg 9.0, the RPM packages have been configured to allow installation of multiple versions side by side. This is to facilitate in-place upgrade of databases (which requires both versions installed during the conversion). The packages are names postgresql92, postgresql93, etc.
Also note that it would not be possible for both versions to run simultaneously on the same port.
My guess is that your server was rebooted, and when it came up, either they were both configured to start and the 8.4 version started first, or perhaps the 9.2 version is not configured to start at boot at all.
You can confirm this with:
yum list installed "postgres*"
to see that you have both versions installed. You can check which versions are configured to start at boot with:
chkconfig --list | grep postgres
To stop the 8.4 version and start the 9.2 version, so that you can access your data:
service postgresql stop
service postgresql-9.2 start
To make sure that 9.2 starts up next time you boot, and 8.4 does not:
chkconfig postgresql-9.2 on
chkconfig postgresql off
All the above commands executed as root.
If you do not specifically need the 8.4 postgresql installed on your server I would recommend you remove it.
Best Answer
OK, first, you shouldn't need a heads-up that an upgrade is coming because you should have backups anyway. All the time. A disk failure, power surge or fire doesn't come with a few days advance warning either. (Ironically, you posted on world backup day).
32-bit PostgreSQL data files are not compatible with 64-bit binaries or vice versa. So you must, somehow, get the 32-bit binaries if you wish to read your data and dump it.
If you cannot do that on the NAS its self, you will need to:
Copy the data directory to another location ( you should do this anyway, for safekeeping )
Make another copy somewhere safe and read-only. Don't touch it again.
Install the same major version of PostgreSQL for the same operating system and architecture on a test system or VM. For example, if the NAS runs on an x86_64 CPU but was running 32-bit i386 PostgreSQL 9.3.1 binaries, you could install Ubuntu 32-bit x86 and PostgreSQL 9.3.10 and expect it to read your data. Probably. There are some possible differences if the PostgreSQL on the NAS was compiled with special non-standard settings, but hopefully it wasn't.
Start 32-bit PostgreSQL to use your copied directory
Use
pg_dumpall --globals-onlyto dump users, etc. Then for each database usepg_dump -Fcto dump the database.Restore the dumps to your new database. Or, preferably, set up a database server somewhere safe that you have reasonable control over.
Now go yell at the people who made this incredibly stupid change without telling anyone.
If you find that you can't load the data files on a regular Ubuntu 32-bit VM with the same PostgreSQL major version (x.y, e.g. if you had 9.4.1 you need 9.4.x and can't use 9.3.x or 9.5.x; yes, PostgreSQL's version numbering is stupid) then you might need to find an old version of the NAS's firmware and extract the PostgreSQL binaries from it, then get them to run on a VM. Or compile your own PostgreSQL with the same non-standard options the NAS people used. Thankfully this isn't likely, as few people change the block size, wal segment size, etc... and I really wish they weren't ./configure options at all.