Revision 13293
Added by Aaron Marcuse-Kubitza over 10 years ago
| index.htm | ||
|---|---|---|
| 732 | 732 |
## in postgresql.conf: |
| 733 | 733 |
### set wal_level = hot_standby |
| 734 | 734 |
### set wal_keep_segments to long enough that the WAL chain spans the duration of the backup |
| 735 |
#### to determine this, measure how quickly WAL segments are created at peak DB usage
|
|
| 735 |
#### to determine this, put the DB into peak usage and measure how many WAL segments are created in the time it takes an rsync with minimal changes to complete (about a few seconds)
|
|
| 736 | 736 |
## $ sudo service postgresql restart |
| 737 | 737 |
# run: |
| 738 | 738 |
## copy files using rsync, etc. |
| ... | ... | |
| 798 | 798 |
<DD>"A checkpoint is a point in the transaction log sequence at which all data files have been updated to reflect the information in the log" |
| 799 | 799 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/backup-file.html" name="http://www.postgresql.org/docs/9.3/static/backup-file.html" ADD_DATE="1397776134" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: File System Level Backup</A><a name="PostgreSQL: Documentation: 9.3: File System Level Backup" href="#PostgreSQL: Documentation: 9.3: File System Level Backup" style="margin-left: 0.5em;">¶</a> |
| 800 | 800 |
<DD>"The database server must be shut down in order to get a usable backup. Half-way measures such as disallowing all connections will not work (in part [...] because of internal buffering within the server)." |
| 801 |
** in practice, this is not necessarily the case. it is entirely possible to get a usable filesystem-level backup, using the approaches described at http://vegpath.org/links/#backups . |
|
| 802 |
this is important because filesystem-level backups have several significant advantages over traditional database-level backups with pg_dump: |
|
| 803 |
1) only changed files will be backed up each time, rather than the entire database |
|
| 804 |
2) no CPU time needs to be spent on intensive compression of the data |
|
| 805 |
3) most importantly, the backup is instantaneously restorable simply by swapping the backup and primary database directories. by comparison, a pg_dump backup can take many hours to restore. |
|
| 801 | 806 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/app-pgbasebackup.html" name="http://www.postgresql.org/docs/9.3/static/app-pgbasebackup.html" ADD_DATE="1397778881" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: pg_basebackup</A><a name="PostgreSQL: Documentation: 9.3: pg_basebackup" href="#PostgreSQL: Documentation: 9.3: pg_basebackup" style="margin-left: 0.5em;">¶</a> |
| 802 | 807 |
</DL><p> |
| 803 | 808 |
<DT><a name="disk space" href="#disk space"><H3 ADD_DATE="1340661986">disk space</H3></a> |
Also available in: Unified diff
fix: web/links/index.htm: updated to Firefox bookmarks: PostgreSQL: backups: wal_keep_segments method: clarified how to determine the value of wal_keep_segments. filesystem-level backups: documented the advantages of filesystem-level backups over traditional database-level backups with pg_dump.