From: | George Neuner <gneuner2(at)comcast(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Recover corrupted data |
Date: | 2017-04-19 17:54:55 |
Message-ID: | cu4ffc1th6pssmac0hq0otqdakfp85chfd@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 19 Apr 2017 13:25:41 -0300, Alexandre <psybox(at)gmail(dot)com>
wrote:
> :
>But there is no solution for [file corruption]?
The only solutions are to guard against it: make frequent backups and
make use of safety mechanisms in Postgresql and in the OS.
Postgresql logs (WAL) intended changes to the database before it makes
them. NTFS *can* do similar change logging for files - but its
logging may or may not be turned on by default.
If you are using NTFS on a hard disk, then for maximum crash
resistance make sure that both journaling (usn) and self-healing
(repair) are turned on.
If the hard disk was formatted by a (relatively) recent version of
Windows, then it is likely that journaling is on already. But best to
check because prior to Vista the default was OFF, and a number of
internet "tweak" sites advise to turn off journaling deliberately to
enhance write performance. Disabling journaling is [maybe] acceptable
for a personal workstation, but not for a server.
If you are using SSD, then OS journaling will be off by default. If
the SSD is battery backed, then journaling *probably* is not necessary
and you can choose whether to trade enhanced crash resistance against
increased SSD wear and (slightly) reduced write performance.
See:
fsutil usn ...
https://technet.microsoft.com/en-us/library/cc788042(v=ws.11).aspx
fsutil repair ...
https://technet.microsoft.com/en-us/library/ff621565(v=ws.11).aspx
George
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2017-04-19 18:31:11 | Re: Recover corrupted data |
Previous Message | David Rowley | 2017-04-19 17:07:20 | Re: Why so long? |