On Apr 6, 2013, at 2:24 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote:

> Incidentally, I bumped into another custom backup script just a few weeks 
> back that also excluded backup_label. I don't know what the author was 
> thinking when he wrote that, but it seems to be a surprisingly common 
> mistake. Maybe it's the "label" in the filename that makes people think it's 
> not important. Perhaps we should improve the documentation to make it more 
> explicit that backup_label must be included in the backup. The docs already 
> say that, though, so I suspect that people making this mistake have not read 
> the docs very carefully anyway.
> 
> Perhaps a comment in the beginning of backup_label would help:
> 
> # NOTE: This file MUST be included in the backup. Otherwise, the backup
> # is inconsistent, and restoring it may result in a corrupt database.
> 
> Jeff B., assuming that you excluded backup_label from the backup for some 
> reason, do you have any thoughts on what would've helped you to avoid that 
> mistake? Would a comment like above have helped - did you look inside 
> backup_label at any point?


I think such a comment could be helpful. The base backups did contain 
backup_label. That is how another script would determine what WAL files to 
remove. It looked at the oldest base backup's backup_label file to get the 
oldest WAL file to keep.

My problem was that backup_label was excluded from the data directory when it 
was sync'd from the base backup. (We keep base backups separate from data 
directories, so they can be reused.) I guess it was excluded because it was 
assumed to not be used by archive recovery. So, clarifying backup_label's 
importance there seems helpful.

Thank you for your help,
- Jeff
--
Jeff Bohmer | Corporate Technology Manager | VisionLink, Inc.
First National Center | 3101 Iris Avenue, Suite 240 | Boulder CO, 80301

Office 303.402.0170 x121

Other ways to stay in touch - Blog | Twitter | Facebook | LinkedIn | Web

This message and any attachments may contain information that is privileged, 
confidential or exempt from disclosure under applicable law or agreement. If 
you 
have received this message in error, please reply and delete the message and 
any attachments without opening the attachment. Thank you.



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to