<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Pg_dump on Evan Hoffman</title><link>https://evan.wtf/tags/pg_dump/</link><description>Recent content in Pg_dump on Evan Hoffman</description><generator>Hugo</generator><language>en-US</language><copyright>Evan Hoffman</copyright><lastBuildDate>Thu, 26 Sep 2013 09:12:05 +0000</lastBuildDate><atom:link href="https://evan.wtf/tags/pg_dump/index.xml" rel="self" type="application/rss+xml"/><item><title>Goodbye, pg_dump</title><link>https://evan.wtf/2013/09/26/goodbye-pg_dump/</link><pubDate>Thu, 26 Sep 2013 09:12:05 +0000</pubDate><guid>https://evan.wtf/2013/09/26/goodbye-pg_dump/</guid><description>&lt;p&gt;I&amp;rsquo;ve been a Postgres user and administrator for a while. Over the years, my views on backups have evolved.&lt;/p&gt;&#10;&lt;p&gt;Originally, like most people, I started out with good old pg_dump. With a reasonably small database (under 50 GB) dumping to a flat text file is a fine option. I&amp;rsquo;d generally do something like &lt;code&gt;pg_dump -Upostgres dbname | gzip &amp;gt; dbname.sql.gz&lt;/code&gt; to compress it on the fly and save space. For years this seemed perfect: dumping the entire database in a single transaction into a single file that can be restored anywhere.&lt;/p&gt;</description></item><item><title>Using WAL archiving &amp; Compellent snapshots for PostgreSQL backups</title><link>https://evan.wtf/2011/07/13/using-wal-archiving-compellent-snapshots-for-postgresql-backups/</link><pubDate>Wed, 13 Jul 2011 13:46:40 +0000</pubDate><guid>https://evan.wtf/2011/07/13/using-wal-archiving-compellent-snapshots-for-postgresql-backups/</guid><description>Changing my Postgres DB backup strategy from nightly &lt;code&gt;pg_dump&lt;/code&gt;s to WAL archiving with SAN snapshots.</description></item></channel></rss>