I gathered you some links you should read:
Basically your workflow might be the following, which is extracted as a combination of all tips of the above links:
- Turn on postgres setting
fsync if it is not.
synchronous_commit to "on" (or "local") if it is set to "off".
diskchecker.pl just for sanity to see if you bought something good and it is configured correctly.
- See what sync method postgres selected automatically with
- and use it's output to
- check if you are affected by
FLUSH CACHE EXT/
SYNCHRONIZE CACHE problem.
- decide on the basis of the additional information provided here (in paragraph wal_sync_method) and here (in paragraph test_fsync and below) what value to set
- Check if your BBU and file-system prohibit partial writes of 8kb pages, if yes you may disable
full_page_writes (see last paragraph here).
Remark (why this might not be enough)
Note that this seems very reliable, but quoted from one of the links above:
Critics of the battery backup approach suggest that if you run such a system under load, eventually you’ll have a failure in this relatively complicated cache method that will corrupt your database in a way that’s nearly impossible to detect or recover from.
So even having a BBU and a correctly configured server instance, this does not remove the burden to backup everything regularly, and does not remove the possibility to loose some data.
I am not responsible for any lost data ;) neither due to lack of advice here or a wrong tip, nor through anything else.