How to determine in early stages in PostgreSQL something beginning to fail?

Good day!
Tell me, please, are there any methods of checking the database and the Postgres errors?
Something like a self-test of the DB server?
In particular, are faced with a situation when the problems started with the service table and I noticed it only when I get an error on the next backup.
The problem was that started to fail map memory, where he worked for Postgres.
I agree that you can not use a memory card and hard drive, etc., but nothing lasts forever and nothing is perfect.
Because I would like to be able to identify these errors early, in order to be able to properly extract the data and either fix, but rather to reinstall Postgres.
April 4th 20 at 13:29
2 answers
April 4th 20 at 13:31
Nothing lasts forever and nothing is perfect, except for a cluster behind a few hours replica and a clear plan backuping.

Your case is not about Postgres. To avoid problems with the file system important databases are usually put on occasionsteile storage.
@reanna_Kuph Yes, I agree that is not tied to a specific DB server, but I think you never know, suddenly it came up with something for self-diagnosis.
Resilient storage is cool, but in this situation I would like a cheaper solution because no way to ensure quality storage. Therefore the question arose about the diagnosis or when starting or periodically in the process. - frederique_Kiehn commented on April 4th 20 at 13:34
@frederique_Kiehn, regular fsck, in theory, should help to catch problems with FS. - reanna_Kuph commented on April 4th 20 at 13:37
regular fsck, in theory, should help to catch problems with FS.

Thanks, but as I understand it you cannot use it for file system check during operation of this system file? - frederique_Kiehn commented on April 4th 20 at 13:40
April 4th 20 at 13:33
If the media is unreliable - then it adds additional codes of the Hamming type to restore the damaged bits after a crash. 99% of normal carriers is implemented in hardware. If your flash drive fails or is not very reliable then it is advisable to buy a new one. If you still want to nakovyryat gold in the muck, look in the direction of the par2 utility she to ten percent will increase the size of your backups but will guarantee fixing a few bits if that will. It runs over a file system and its control codes are just additional files side by side.

And check whether backup vosstanovit in principle - impossible. As in that of philosophical thought - it is impossible to know what the pudding until you have eaten. Therefore, to guarantee integrity the backup at the logical level is possible only after the simulation of a full recovery in DB.
@Leopol, thanks for the advice.
But at the moment I'm not so much worried about the question of how to save the resulting backup (which I can throw on an external media or sent over the network periodically), and the question of control of the database server in order to be able to fix something. - frederique_Kiehn commented on April 4th 20 at 13:36

Find more questions by tags PostgreSQLDatabase administration