them to flush
   data to the platters on write-back-enabled drives.  Unfortunately, such
   file systems behave suboptimally when combined with battery-backup unit
   (<acronym>BBU</acronym>) disk controllers.  In such setups, the synchronize
   command forces all data from the controller cache to the disks,
   eliminating much of the benefit of the BBU.  You can run the
   <xref linkend="pgtestfsync"/> program to see
   if you are affected.  If you are affected, the performance benefits
   of the BBU can be regained by turning off write barriers in
   the file system or reconfiguring the disk controller, if that is
   an option.  If write barriers are turned off, make sure the battery
   remains functional; a faulty battery can potentially lead to data loss.
   Hopefully file system and disk controller designers will eventually
   address this suboptimal behavior.
  </para>

  <para>
   When the operating system sends a write request to the storage hardware,
   there is little it can do to make sure the data has arrived at a truly
   non-volatile storage area. Rather, it is the
   administrator's responsibility to make certain that all storage components
   ensure integrity for both data and file-system metadata.
   Avoid disk controllers that have non-battery-backed write caches.
   At the drive level, disable write-back caching if the
   drive cannot guarantee the data will be written before shutdown.
   If you use SSDs, be aware that many of these do not honor cache flush
   commands by default.
   You can test for reliable I/O subsystem behavior using <ulink
   url="https://brad.livejournal.com/2116715.html"><filename>diskchecker.pl</filename></ulink>.
  </para>

  <para>
   Another risk of data loss is posed by the disk platter write
   operations themselves. Disk platters are divided into sectors,
   commonly 512 bytes each.  Every physical read or write operation
   processes a whole sector.
   When a write request arrives at the drive, it might be for some multiple
   of 512 bytes (<productname>PostgreSQL</productname> typically writes 8192 bytes, or
   16 sectors, at a time), and the process of writing could fail due
   to power loss at any time, meaning some of the 512-byte sectors were
   written while others were not.  To guard against such failures,
   <productname>PostgreSQL</productname> periodically writes full page images to
   permanent WAL storage <emphasis>before</emphasis> modifying the actual page on
   disk. By doing this, during crash recovery <productname>PostgreSQL</productname> can
   restore partially-written pages from WAL.  If you have file-system software
   that prevents partial page writes (e.g., ZFS),  you can turn off
   this page imaging by turning off the <xref
   linkend="guc-full-page-writes"/> parameter. Battery-Backed Unit
   (BBU) disk controllers do not prevent partial page writes unless
   they guarantee that data is written to the BBU as full (8kB) pages.
  </para>
  <para>
   <productname>PostgreSQL</productname> also protects against some kinds of data corruption
   on storage devices that may occur because of hardware errors or media failure over time,
   such as reading/writing garbage data.
   <itemizedlist>
    <listitem>
     <para>
      Each individual record in a WAL file is protected by a CRC-32C (32-bit) check
      that allows us to tell if record contents are correct. The CRC value
      is set when we write each WAL record and checked during crash recovery,
      archive recovery and replication.
     </para>
    </listitem>
    <listitem>
     <para>
      Data pages are checksummed by default, and full page images
      recorded in WAL records are always checksum protected.
     </para>
    </listitem>
    <listitem>
     <para>
      Internal data structures such as <filename>pg_xact</filename>, <filename>pg_subtrans</filename>, <filename>pg_multixact</filename>,
      <filename>pg_serial</filename>, <filename>pg_notify</filename>, <filename>pg_stat</filename>, <filename>pg_snapshots</filename>