Greetings, * julyanto SUTANDANG (julyanto@xxxxxxxxxxxx) wrote: > Best practice in doing full backup is using RSYNC, but before you can copy > the DATADIR, you might you pg_start_backup to tell the server not to write > into the DATADIR, because you are copying that data. After finished copy > all the data in DATADIR, you can ask server to continue flushing the data > from logs, by commanding pg_stop_backup. Remember, not to copy the XLOG > dir. Whoah. That is not, at all, correct, if I'm understanding what you're suggesting. PG most certainly *does* continue to write into the data directory even after pg_start_backup() has been run. You *must* use archive_command or pg_receivexlog to capture all of the WAL during the backup to have a consistent backup. > There are another way more simpler, which is applying command > pg_basebackup, which actually did that way in simpler version. pg_basebackup has options to stream the WAL during the backup to capture it, which is how it handles that. > if you did pg_dump, you wont get the exact copy of your data, and you will > take longer downtime to recover the backup data. By that way, recovering is > only starting up the postgres with that copy. pg_dump will generally take longer to do a restore, yes. Recovering from a backup does require that a recovery.conf exists with a restore_command that PG can use to get the WAL files it needs, or that all of the WAL from the backup is in pg_xlog/pg_wal. Please do not claim that PG stops writing to the DATADIR or BASEDIR after a pg_start_backup(), that is not correct and could lead to invalid backups. Thanks! Stephen
Attachment:
signature.asc
Description: Digital signature
