DD复制在terminal但不是由cron工作

你有你的“备份”脚本正在执行cron …并closurescron在脚本中，以防止cron作业在“备份”期间运行。 你真的不知道这里的问题在哪里？ 你的脚本closures了crond，但是crond正在运行你的脚本，因此，closurescrond将closures连接到你的脚本的描述符，这些描述符会随着一个坏的pipe道或者来自crond本身的中断信号而死掉。

由于脚本死亡，crond将不会重新启动。 这就是我们所说的“徒步自杀”。

即使在重新启动crond之后，它也不会注册完成该作业，因为它在执行期间被closures，并且/或者不得不发信号通知其终止。 无论是crond本身还是anacron（取决于你正在使用的cron调度器），它将不得不再次运行这个工作，有可能进入一个无限循环。

如果您在可靠性pipe理和灾难恢复方面没有实际经验，那么您的问题就是发明自己的“备份”解决scheme时出现问题的一个很好的例子。 更糟糕的是，缺乏系统工作的知识。

首先，也是最重要的一点， 您不要在活动文件系统上创build原始磁盘转储 。 文件系统是为了不直接触摸原始磁盘内容而发明的。 你想保存文件系统中存储的文件，这对你来说很重要。 所以你必须通过文件系统访问它们，而不是磁盘上存储的原始字节。 如果安装了分区，则绝对不能保证数据实际存储在磁盘上，并且在复制过程中磁盘将保持一致的状态。

即使可以以可恢复的方式快照磁盘的状态（如突然断电，这可以通过ext3等日志文件系统快速恢复），但对于热磁盘转储，情况永远不会如此。 磁盘转储需要很长时间才能完成，在转储的开始和结束之间几乎存在无限的中间状态，转储将包含这些状态的混合，即使使用日志文件系统，转储也可能无法恢复。

而且我还没有提到原始磁盘转储备份的所有其他问题：

• 使用和可用空间没有区别。 如果你有一个单一的100 kB文件或250 GB的数以万计的文件没有关系，一切都将被复制。 这是非常低效的。 只有当您需要磁盘的相同克隆，并且卸载磁盘时才使用此方法。
• 您不能执行差异备份或增量备份。 所有备份都必须完整备份。 各种低效率：
  1. 由于这占用了很多空间，通常只会保留所有数据的一个副本。 如果您的文件在备份之前被损坏或删除，并且您没有注意到，则损坏或删除的数据将复制到先前的备份中，使其无效。
  2. 由于您对以前的数据执行此操作，如果您的系统在转储过程中出现故障（从复制整个磁盘开始需要较长的时间），则原始系统和备份都将丢失。
  3. 如果自上次备份以来更改了100 kB数据，则仍会转储整个磁盘。 就你而言，这个效率至less要低一百万倍 。
• 您不能将此转储恢复到具有不同几何体的磁盘。 如果您的更换磁盘较小，则无需讨论。 如果您的replace磁盘较大，则可以恢复丢失额外空间或对分区表和分区超级块执行一些手动操作（对未初始化的操作有危险）。 你想相信你的文件，你的工作，这样的黑客？
• 即使您使用循环设备挂载原始图像并手动复制文件， 您最终将手动复制文件！ 那么你从原始磁盘转储中获得了什么？ 只要复制你该死的文件！

很多人都在那里，并且有很多关于灾难恢复的经验。 不要试图创造自己的备份解决scheme，你会结束这些事情。 使用适当的备份，如dump ， tar或rsync 。 如果您需要更强大的function，请使用Amanda或Bacula ，或者其他数百个可供使用的解决scheme之一。

可能不是你所期望的答案，但不得不说。

请注意，请不要使用dd来备份您的物理卷，因为您的问题的评论中所述的所有原因。

至less如果你想做磁盘到磁盘的备份使用像rsync （尽pipe这不是没有问题），如果你不能从cron工作，回来这里。

我怀疑你的cron行不正确。 请用下面的条目编辑你的crontab文件：

1 0 * * 2-6 /root/applog_backup.sh

请让我知道这是否解决您的问题。

我build议你花点时间，看看一个叫Bacula的产品。 这是开源（免费！），并做了一个伟大的工作。 设置起来很复杂，但是一旦你开始了，你会忘记再次担心备份。