| 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: | Whole Thread | Raw Message | 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? |