正如您所说的“相反,它总是在最后一个 tar 文件开始时立即执行”,通常这意味着行尾有一个 '&' 或者您确定 tar 真的有效吗?您是否正在查看早期创建的旧 tar.gz?确保它是大小正确的新 tar 文件。
编辑我并不是说您必须删除文件,只是 dbl-检查放入最终 tar 的内容是否有意义。
您是否正在检查最终 tar cmd 的输入文件的大小?(/home/temp_db.gz /backup/temp_ftp.tar)?编辑我的意思是,未压缩的 tar 文件 (temp_ftp.tar) 应该略大于它包含的所有文件的大小总和。如果您知道您有 1 Meg 的文件组成 temp_ftp.tar,并且该文件是 1.1 Meg,那很好,如果是 0.5 Meg,那就不好了。(还可以考虑对整个内容进行 gzip 压缩以减少到远程主机的传输时间)。您的压缩数据库文件,很难说,大概是工作,如果文件大小是 25 字节左右,那么这表明创建文件时出错。
否则你所说的似乎是不可能的。这是其中一件事情,或者其他事情正在把事情搞砸。
调试最后一个 tar 花费多长时间的一种方法是将命令包装在两个日期命令中,即
date
tar -Pcf /backup/temp_backup.tar /home/temp_db.gz /backup/temp_ftp.tar
rc=$?
date
printf "return code from quick tar was ${rc}\n"
此外,根据您的标题“检查上一步”,我添加了从 tar 捕获返回码并打印该值。
再次强调一下,在 linux shell 脚本中,一个命令无法在前一个命令完成之前开始执行(除了带有 '&' 字符的后台作业)。
编辑文件的所有权和权限可能会搞砸文件的所有权和权限。采用 \
ls -l /backup/temp_backup.tar /home/temp_db.gz /backup/temp_ftp.tar
确认您的用户 ID 拥有这些文件并且您可以写入它们。如果您愿意,请编辑您的帖子以包含该信息。
此外,您的标题显示“cron”:您是否捕获了该脚本的所有可能输出以帮助调试情况?set -vx
在makebackup.sh 的顶部附近打开 shell 调试。将调试输出添加到您的 tar cmd '-v'。
捕获整个过程的 cron 输出,例如
59 23 31 12 * { /path/to/makebackup.sh 2>&1 ; } > /tmp/makebackup.`/bin/date +\%Y\%m\%d.\%H\%M\%S.trace_log
并确保您没有发现任何错误消息。
( Crontab 示例,min hr day mon(星期几,0-6 或 *),更改日期/时间以满足您的测试需求)
你的期望脚本使用'\r',你不想在 Unix/linux 环境中使用'\n'。如果您是基于 Windows 的服务器,那么您需要 '\r\n' 。
编辑期望脚本是否有效,您是否证明您对正在复制文件感到满意,它们在备份站点上的大小是否相同,日期是否更改?
如果您希望有一天备份能够保存您的系统,那么您必须更好地了解整个过程应该如何工作以及它是否按预期工作。根据您的情况和备用计算机的可用性,您应该安排一个恢复备份的测试,看看它们是否真的有效。当您使用 -P 保留完整路径信息时,您确实需要小心不要用旧文件覆盖您的工作系统。
总结我的建议,仔细检查一切。
我希望这有帮助。