Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>One way is to <a href="http://www.postgresql.org/docs/8.1/static/backup.html" rel="noreferrer">use</a> <code>pg_dump</code> to generate a flat sql dump, which you can gzip or whatever. This is certainly the easiest option, as the results can be piped back in to <code>psql</code> to re-load a database, and since it can also export as plain text, you can look through or edit the data prior to restore if necessary.</p> <p>The next method is to temporarily shut down your database (or if your filesystem supports atomic snapshots, in theory that might work) and <a href="http://www.postgresql.org/docs/8.1/interactive/backup-file.html" rel="noreferrer">backup</a> your PostgreSQL <code>data</code> directory.</p> <p><a href="http://www.postgresql.org/docs/8.1/interactive/backup-online.html" rel="noreferrer">This</a> page from the PostgreSQL site also explains how to do online backups and point-in-time recovery, which is definitely the most difficult to configure, but also the optimal method. The idea is that you perform a base backup (which you might do every day, couple of days or week) by running some special SQL (<code>pg_start_backup</code> and <code>pg_stop_backup</code>) and make a (filesystem-level) copy of your database directory. The database doesn't go offline during this time, and everything still works as normal. From then on, the database generates a Write Ahead Log (WAL) of any changes, which can then be pushed (automatically, by the database) to wherever you want. To restore, you take the base backup, load it into another database instance, then just replay all the WAL files. This way you can also do point-in-time recovery by not replaying all of the logs.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload