如何检查postgresql备份是否成功?

发布于 2024-11-15 14:07:43 字数 594 浏览 7 评论 0原文

我们有一个 postgresql 数据库,每晚通过 cron 作业使用以下命令进行备份:

su postgres -c "pg_dump our_database | gzip > /home/smb/shared/database_backup.bak.gz"

最近我们遇到了磁盘故障,从一些坏扇区开始,在那段时间 pg_dump 退出并出现以下错误

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: catalog is missing 17 attribute(s) from relid 20158
pd_dump: The command was: LOCK TABLE public.obvez IN ACCESS SHARE MODE

现在,因为它处于 cron 作业中,没有人注意到错误消息,备份被中断,但它的大小不是零,一切似乎都正常,错误没有被注意到,直到最终磁盘故障,当我们意识到我们没有备份时。

我们设法从较旧的备份中恢复数据,但现在我想知道检查 pg_dump 是否成功完成其工作的正确方法是什么?

We have a postgresql database that is backed up nightly from a cron job with a following command:

su postgres -c "pg_dump our_database | gzip > /home/smb/shared/database_backup.bak.gz"

recently we had a disk failure that started with a few bad sectors and during that time pg_dump exited with the following errors

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: catalog is missing 17 attribute(s) from relid 20158
pd_dump: The command was: LOCK TABLE public.obvez IN ACCESS SHARE MODE

Now, since it was in cron job, nobody noticed error messages, the backup was interrupted but it wasn't zero sized, everything seemed ok and the error went unnoticed until final disk failure when we realized we didn't have backup.

We managed to restore data from an older backup but now I would like to know what would be the proper way to check if pg_dump finished its job with success or not?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

明月夜 2024-11-22 14:07:43

我将结果写入日志文件,并在 cronjob 结束时,将日志文件的内容发送到我的电子邮件地址。这样,当出现问题时我就会知道。

su postgres "pg_dump our_database 2>> $LOG_FILE | gzip > /home/smb/shared/database_backup.bak.gz"
cat $LOG_FILE | mailx $MAINTAINERS -s "Postgresql backup"

ADDENDUM:如果您只想在出现问题时才发送电子邮件,您可以检查 pg_dump 的返回码:

LOG_FILE=/tmp/pgdump.err

if ! pg_dump -U backupuser "our_database" 2> $LOG_FILE 
then 
    cat $LOG_FILE | mailx 'youremailaddress' -s "Postgresql backup failure!"
fi

I write the outcome into a logfile, and at the end of the cronjob, I send the content of the logfile to my e-mail address. That way, I'll know when something went wrong.

su postgres "pg_dump our_database 2>> $LOG_FILE | gzip > /home/smb/shared/database_backup.bak.gz"
cat $LOG_FILE | mailx $MAINTAINERS -s "Postgresql backup"

ADDENDUM: if you want to send the e-mail only if anything went wrong, you can check the return code of pg_dump:

LOG_FILE=/tmp/pgdump.err

if ! pg_dump -U backupuser "our_database" 2> $LOG_FILE 
then 
    cat $LOG_FILE | mailx 'youremailaddress' -s "Postgresql backup failure!"
fi
手心的海 2024-11-22 14:07:43

有些程序在类 UNIX 系统上的管道中使用时表现不佳。例如,我使用通过 gzip 管道传输的 pg_dump,如下所示:

损坏的脚本:错误条件永远不会发生

export PGPASSWORD=secret
pg_dump -h host -U user db | gzip - > backup.sql.gz

if [ $? -ne 0 ]; then
    ### Never happens: gzip never fails! ###
    echo Backup failed.
    exit 1
fi

这使用检查上一个命令 ($?) 退出状态的正常方法,但它不起作用。如果 pg_dump 由于任何原因失败,gzip 不会返回任何错误响应。 $?设置为0,表示成功。

幸运的是,有更好的方法。在 bash 中, PIPESTATUS 环境变量是一个数组,其中最后一个管道中执行的所有命令的返回代码。检查总体返回状态和 pg_dump 的状态现在如下所示:

正确的脚本:单独检查 pg_dump 的结果

export PGPASSWORD=secret
pg_dump -h host -U user db | gzip - > backup.sql.gz

if [ $? -ne 0 -o ${PIPESTATUS[0]} -ne 0 ]; then
    echo Backup failed.
    exit 1
fi

现在我可以确定我的自动数据库备份不会默默地失败。

来自 https://mattryall.net/blog/piped-exit-status

Some programs don't behave nicely when used in a pipe on unix-like systems. For example, I was using pg_dump piped through gzip like so:

Broken script: error condition never occurs

export PGPASSWORD=secret
pg_dump -h host -U user db | gzip - > backup.sql.gz

if [ $? -ne 0 ]; then
    ### Never happens: gzip never fails! ###
    echo Backup failed.
    exit 1
fi

This uses the normal way of checking the exit status of the previous command ($?), but it doesn't work. If the pg_dump fails for any reason, gzip doesn't return any error response. $? is set to 0, indicating success.

Fortunately, there's a better way. In bash, the PIPESTATUS environment variable is an array with the return codes of all the commands executed in the last pipe. Checking for the overall return status and the status of pg_dump is now done like this:

Correct script: check the result of pg_dump separately

export PGPASSWORD=secret
pg_dump -h host -U user db | gzip - > backup.sql.gz

if [ $? -ne 0 -o ${PIPESTATUS[0]} -ne 0 ]; then
    echo Backup failed.
    exit 1
fi

Now I can be sure my automated database backups aren't going to fail silently.

From https://mattryall.net/blog/piped-exit-status

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文