begriffs open source - ai-pg/blob - full-docs/src/sgml/html/backup-file.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>25.2. File System Level Backup</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="backup-dump.html" title="25.1. SQL Dump" /><link rel="next" href="continuous-archiving.html" title="25.3. Continuous Archiving and Point-in-Time Recovery (PITR)" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">25.2. File System Level Backup</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="backup-dump.html" title="25.1. SQL Dump">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="backup.html" title="Chapter 25. Backup and Restore">Up</a></td><th width="60%" align="center">Chapter 25. Backup and Restore</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="continuous-archiving.html" title="25.3. Continuous Archiving and Point-in-Time Recovery (PITR)">Next</a></td></tr></table><hr /></div><div class="sect1" id="BACKUP-FILE"><div class="titlepage"><div><div><h2 class="title" style="clear: both">25.2. File System Level Backup <a href="#BACKUP-FILE" class="id_link">#</a></h2></div></div></div><p>
   3    An alternative backup strategy is to directly copy the files that
   4    <span class="productname">PostgreSQL</span> uses to store the data in the database;
   5    <a class="xref" href="creating-cluster.html" title="18.2. Creating a Database Cluster">Section 18.2</a> explains where these files
   6    are located.  You can use whatever method you prefer
   7    for doing file system backups; for example:
   8
   9 </p><pre class="programlisting">
  10 tar -cf backup.tar /usr/local/pgsql/data
  11 </pre><p>
  12   </p><p>
  13    There are two restrictions, however, which make this method
  14    impractical, or at least inferior to the <span class="application">pg_dump</span>
  15    method:
  16
  17    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
  18       The database server <span class="emphasis"><em>must</em></span> be shut down in order to
  19       get a usable backup. Half-way measures such as disallowing all
  20       connections will <span class="emphasis"><em>not</em></span> work
  21       (in part because <code class="command">tar</code> and similar tools do not take
  22       an atomic snapshot of the state of the file system,
  23       but also because of internal buffering within the server).
  24       Information about stopping the server can be found in
  25       <a class="xref" href="server-shutdown.html" title="18.5. Shutting Down the Server">Section 18.5</a>.  Needless to say, you
  26       also need to shut down the server before restoring the data.
  27      </p></li><li class="listitem"><p>
  28       If you have dug into the details of the file system layout of the
  29       database, you might be tempted to try to back up or restore only certain
  30       individual tables or databases from their respective files or
  31       directories. This will <span class="emphasis"><em>not</em></span> work because the
  32       information contained in these files is not usable without
  33       the commit log files,
  34       <code class="filename">pg_xact/*</code>, which contain the commit status of
  35       all transactions. A table file is only usable with this
  36       information. Of course it is also impossible to restore only a
  37       table and the associated <code class="filename">pg_xact</code> data
  38       because that would render all other tables in the database
  39       cluster useless.  So file system backups only work for complete
  40       backup and restoration of an entire database cluster.
  41      </p></li></ol></div><p>
  42   </p><p>
  43    An alternative file-system backup approach is to make a
  44    <span class="quote">“<span class="quote">consistent snapshot</span>”</span> of the data directory, if the
  45    file system supports that functionality (and you are willing to
  46    trust that it is implemented correctly).  The typical procedure is
  47    to make a <span class="quote">“<span class="quote">frozen snapshot</span>”</span> of the volume containing the
  48    database, then copy the whole data directory (not just parts, see
  49    above) from the snapshot to a backup device, then release the frozen
  50    snapshot.  This will work even while the database server is running.
  51    However, a backup created in this way saves
  52    the database files in a state as if the database server was not
  53    properly shut down; therefore, when you start the database server
  54    on the backed-up data, it will think the previous server instance
  55    crashed and will replay the WAL log.  This is not a problem; just
  56    be aware of it (and be sure to include the WAL files in your backup).
  57    You can perform a <code class="command">CHECKPOINT</code> before taking the
  58    snapshot to reduce recovery time.
  59   </p><p>
  60    If your database is spread across multiple file systems, there might not
  61    be any way to obtain exactly-simultaneous frozen snapshots of all
  62    the volumes.  For example, if your data files and WAL log are on different
  63    disks, or if tablespaces are on different file systems, it might
  64    not be possible to use snapshot backup because the snapshots
  65    <span class="emphasis"><em>must</em></span> be simultaneous.
  66    Read your file system documentation very carefully before trusting
  67    the consistent-snapshot technique in such situations.
  68   </p><p>
  69    If simultaneous snapshots are not possible, one option is to shut down
  70    the database server long enough to establish all the frozen snapshots.
  71    Another option is to perform a continuous archiving base backup (<a class="xref" href="continuous-archiving.html#BACKUP-BASE-BACKUP" title="25.3.2. Making a Base Backup">Section 25.3.2</a>) because such backups are immune to file
  72    system changes during the backup.  This requires enabling continuous
  73    archiving just during the backup process; restore is done using
  74    continuous archive recovery (<a class="xref" href="continuous-archiving.html#BACKUP-PITR-RECOVERY" title="25.3.5. Recovering Using a Continuous Archive Backup">Section 25.3.5</a>).
  75   </p><p>
  76    Another option is to use <span class="application">rsync</span> to perform a file
  77    system backup.  This is done by first running <span class="application">rsync</span>
  78    while the database server is running, then shutting down the database
  79    server long enough to do an <code class="command">rsync --checksum</code>.
  80    (<code class="option">--checksum</code> is necessary because <code class="command">rsync</code> only
  81    has file modification-time granularity of one second.)  The
  82    second <span class="application">rsync</span> will be quicker than the first,
  83    because it has relatively little data to transfer, and the end result
  84    will be consistent because the server was down.  This method
  85    allows a file system backup to be performed with minimal downtime.
  86   </p><p>
  87    Note that a file system backup will typically be larger
  88    than an SQL dump. (<span class="application">pg_dump</span> does not need to dump
  89    the contents of indexes for example, just the commands to recreate
  90    them.)  However, taking a file system backup might be faster.
  91   </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="backup-dump.html" title="25.1. SQL Dump">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="backup.html" title="Chapter 25. Backup and Restore">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="continuous-archiving.html" title="25.3. Continuous Archiving and Point-in-Time Recovery (PITR)">Next</a></td></tr><tr><td width="40%" align="left" valign="top">25.1. <acronym class="acronym">SQL</acronym> Dump </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 25.3. Continuous Archiving and Point-in-Time Recovery (PITR)</td></tr></table></div></body></html>