企业官网建设流程全解析

1. 这不是“定时任务入门”，而是你每天凌晨都在用却未必真懂的 crontab 实战手册

你有没有过这样的经历：在某台服务器上写了一行0 1 * * * /sbin/reboot，自以为设好了“每天凌晨1点重启”，结果某天早上登录发现机器根本没重启——或者更糟，它在不该重启的时候突然断连了？我第一次遇到这问题时，是在维护某高校实验室的一套图像处理集群，三台服务器配置完全一样，其中一台总在凌晨1:03左右掉线，另外两台稳如老狗。查日志、比配置、重装系统……折腾两天才发现，问题就出在那行看似简单的 crontab 语句里：时区没对齐、reboot 权限被 systemd 限制、甚至/sbin/reboot在容器化环境中根本不存在。crontab 表面是 Linux 系统里最基础的定时工具，但它的语法陷阱、执行环境差异、权限边界和实际生效逻辑，远比man 5 crontab里那几页文档复杂得多。本文不讲“什么是 cron”，也不堆砌所有字段说明，只聚焦一个真实高频场景——“每天凌晨1点重启一遍”，把它拆到骨子里：为什么必须用0 1 * * *而不是0 1 * * 0-6？为什么直接写reboot会失败？如何确保重启命令在 systemd、systemd-boot、容器、云主机等不同环境下都可靠触发？怎么验证它真的执行了而不是静默失败？以及，更重要的是——绝大多数人根本没意识到，“每天凌晨1点重启”这个需求本身，在现代运维中往往是个危险信号，背后暴露的是服务设计缺陷或资源管理盲区。如果你正要给生产服务器加这条定时重启，或者刚被同事甩来一行 crontab 让你“看看有没有问题”，那么这篇内容就是为你写的。它适合刚接触 Linux 的运维新人、需要写自动化脚本的开发同学，也适合那些已经用了十年 crontab 却还在靠“试错+重启”排查问题的老手。我们不谈理论，只讲实操现场、真实报错、可抄的配置、踩过的坑，以及那些藏在 man page 页脚、没人告诉你但决定成败的细节。

2. 内容整体设计与思路拆解：为什么“每天凌晨1点重启”不能只写一行命令？

2.1 核心需求的本质不是“重启”，而是“保障服务可用性”的妥协方案

先说结论：在绝大多数现代系统中，“每天凌晨1点强制重启”不是一个健康的操作习惯，而是一个临时补救措施。它通常出现在以下几种真实场景中：

• 某个老旧 Java 应用存在内存泄漏，连续运行72小时后 RSS 内存占用飙升至95%，但业务方拒绝升级或重构；
• 容器化部署前的物理机集群，内核模块加载异常导致网卡偶发丢包，重启网卡驱动无效，只能整机重启；
• 某些嵌入式设备固件不支持热更新，厂商明确要求“每日重启以释放缓存”。

这些场景的共同点是：问题根源无法根治，只能靠周期性重置状态来维持短期可用。因此，我们的 crontab 设计目标从来不是“让机器准时重启”，而是“在最小扰动下，以最高成功率完成状态重置，并留下完整证据链证明它确实发生了”。这就决定了方案不能只是一行0 1 * * * reboot，而必须包含：

1. 前置健康检查：确认当前无关键任务在运行（如数据库备份、大文件传输），避免粗暴中断造成数据损坏；
2. 执行环境隔离：确保命令在正确的 shell 环境、PATH 和用户权限下运行，而非依赖当前终端的环境变量；
3. 结果可观测性：记录执行时间、退出码、stdout/stderr，便于事后审计和故障回溯；
4. 失败自动降级：若 reboot 失败（如权限不足、系统忙），应有 fallback 机制（如仅重启关键服务）；
5. 防误触保护：避免因编辑错误、环境变量污染导致非预期重启（比如把* * * * *写成* * * * *）。

提示：很多新手直接crontab -e写命令，却忽略了 crontab 的执行环境与交互式 shell 完全不同——它默认使用/bin/sh，PATH 是/usr/bin:/bin，不加载.bashrc或.profile。这意味着你终端里能直接敲reboot，cron 里却可能报command not found，因为reboot实际在/sbin/reboot，而/sbin不在默认 PATH 中。

2.2 方案选型：为什么不用 systemd timer？为什么不用 at 命令？

面对“每天固定时间执行”，Linux 其实有多个工具可选：

• crontab：传统、通用、几乎所有发行版预装，语法稳定，但缺乏依赖管理和执行状态追踪；
• systemd timer：现代 systemd 系统的原生方案，支持OnCalendar=、Persistent=true（错过时间自动补执行）、依赖其他 unit 启动，但要求系统运行 systemd，且在容器或精简版系统中可能不可用；
• at 命令：适合单次执行，不支持周期性；
• 第三方工具（如 anacron）：针对不常开机的设备（如笔记本），保证“每天至少执行一次”，但精度低，不适合服务器场景。

我们坚持用 crontab 的核心理由有三点：

1. 最大兼容性：从 CentOS 6 到 Ubuntu 24.04，从树莓派到阿里云 ECS，只要装了 cronie 或 vixie-cron，语法就完全一致，无需判断 systemd 版本或 init 系统类型；
2. 最小侵入性：不需要创建额外的.timer和.service文件，不修改系统 unit 目录，审计时一眼可见（crontab -l即可查看）；
3. 运维习惯固化：绝大多数企业运维规范、安全基线检查脚本、自动化巡检工具，都默认将 crontab 作为定时任务的事实标准，改用 systemd timer 反而增加合规成本。

当然，这不是贬低 systemd timer。如果你的系统确定运行 systemd 且长期在线，systemd-run --on-calendar="01:00" --scope reboot确实更优雅。但本文聚焦“通用、可靠、可复现”的方案，所以 crontab 是唯一选择。

2.3 语法结构再认识：0 1 * * *的五个字段到底在控制什么？

crontab 的时间字段是分 时 日 月 周，共五个空格分隔的字段，每个字段代表一个时间维度的匹配规则。很多人死记硬背“*代表任意”，却忽略了字段间的逻辑关系和隐含约束。以0 1 * * *为例：

这里有个致命误区：当“日”和“周”字段同时为*时，cron 会认为“满足任一条件即触发”，而不是“必须同时满足”。也就是说，0 1 * * *的实际含义是：“每天凌晨1点，或者每周的每一天凌晨1点”——这听起来是废话，但关键在于：如果某天既是“每月1号”又是“周日”，它不会执行两次，cron 内部做了去重。然而，一旦你把*改成具体值，比如0 1 1 * *（每月1号1点）和0 1 * * 0（每周日1点），那么1号恰逢周日时，该命令会执行两次！这是大量线上事故的根源。

注意：某些旧版 cron（如早期 Vixie Cron）对0和7的处理不一致，建议统一用0表示周日，避免歧义。现代系统（cronie >= 1.5.2）已标准化，但为兼容性，仍推荐0。

2.4 为什么不用@daily？它真的等价于0 0 * * *吗？

crontab 支持几个预定义时间别名，如@reboot、@hourly、@daily、@weekly。表面看，@daily似乎就是为“每天执行”量身定制的，比0 0 * * *更简洁。但实际使用中，我强烈建议禁用所有预定义别名，全部手写五字段格式。原因有三：

1. 语义模糊：@daily的官方定义是 “run once a day, at midnight”，但“midnight”指 00:00 还是 24:00？不同实现有差异。而0 0 * * *明确指向 00:00:00；
2. 调试困难：当你crontab -l查看时，看到的是@daily，无法直观判断它对应的具体时间点，必须查文档或测试；
3. 兼容性风险：部分精简版 cron（如某些嵌入式 BusyBox 的 crond）根本不支持@daily，直接忽略该行，且不报错。

实测对比（在 CentOS 7 和 Ubuntu 22.04 上）：

• @daily→ 解析为0 0 * * *（即 00:00）
• @midnight→ 同上，但@midnight并非 POSIX 标准，部分系统不识别
• @hourly→ 解析为0 * * * *（每小时第0分钟）

所以，如果你的需求是“凌晨1点”，就必须写0 1 * * *，而不是@daily加偏移——没有这种语法。记住：预定义别名是糖衣炮弹，手写五字段才是真功夫。

3. 核心细节解析与实操要点：从“能跑”到“稳跑”的七层防护

3.1 第一层防护：绝对路径与环境变量隔离

最经典的错误：在终端里which reboot得到/sbin/reboot，于是 crontab 里写0 1 * * * reboot，结果没反应。原因？cron 使用最小化环境，PATH 默认为/usr/bin:/bin，而/sbin不在其中。解决方案只有两个：

• 显式写绝对路径：0 1 * * * /sbin/reboot
• 在命令前设置 PATH：0 1 * * * PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin /sbin/reboot

我推荐第一种，简洁且无歧义。但要注意：/sbin/reboot在不同系统中位置可能不同：

• RHEL/CentOS/Fedora：/sbin/reboot
• Debian/Ubuntu：/sbin/reboot（符号链接到/bin/systemctl）
• Alpine Linux（Docker 常用）：/sbin/reboot（需安装openrc或busybox-initscripts）

实操心得：永远用ls -l $(which reboot)确认真实路径。在容器中，reboot命令可能根本不存在，因为容器默认无权操作宿主机。此时必须改用kill 1（向 PID 1 发送 SIGTERM）或调用宿主机 API，这已超出 crontab 范畴。

3.2 第二层防护：权限与 sudo 绕过

普通用户 crontab 无法执行reboot，会报Permission denied。常见错误做法是：

• 0 1 * * * sudo reboot→ 失败，因为 cron 不启动交互式 shell，sudo 无法读取密码；
• 0 1 * * * sudo -S reboot < /path/to/passwd.txt→ 极度危险，明文密码泄露；

正确方案是：为特定用户授予免密 reboot 权限。编辑/etc/sudoers（务必用visudo）：

# 允许用户 'admin' 无需密码执行 reboot admin ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown

然后 crontab 写：

0 1 * * * sudo /sbin/reboot

注意：NOPASSWD后必须跟绝对路径，且只授权最小必要命令。切勿写NOPASSWD: ALL，这是严重安全漏洞。

3.3 第三层防护：执行前健康检查——避免“重启了但业务已崩”

强制重启最大的风险不是机器宕机，而是重启时业务正在执行关键操作。例如：

• 数据库正在做全量备份（mysqldump占用大量 I/O）；
• 某个 Python 脚本正在处理 10GB 日志文件；
• 容器编排系统（如 Kubernetes）正在滚动更新 Pod。

此时重启会导致备份中断、文件损坏、服务雪崩。因此，必须加入前置检查：

# 检查是否有 mysqldump 进程在运行 if ! pgrep -f "mysqldump" > /dev/null; then # 检查是否有大文件传输（如 rsync） if ! pgrep -f "rsync" > /dev/null; then /sbin/reboot else logger "CRON: rsync running, skip reboot" fi else logger "CRON: mysqldump running, skip reboot" fi

这段脚本逻辑清晰：只有当mysqldump和rsync都未运行时，才执行 reboot。logger命令将信息写入系统日志（/var/log/messages或journalctl），便于审计。

提示：pgrep -f比ps aux | grep更可靠，因为它直接匹配完整命令行，避免 grep 自身进程被误匹配。

3.4 第四层防护：结果记录与可观测性——让每一次重启都有据可查

没有日志的定时任务等于没做。必须记录：

• 计划执行时间（cron 触发时刻）；
• 实际执行时间（命令开始时刻）；
• 命令退出码（0=成功，非0=失败）；
• stdout/stderr 输出（如有）。

标准写法：

0 1 * * * /bin/sh -c 'echo "[$(date "+%Y-%m-%d %H:%M:%S")] START REBOOT" >> /var/log/cron-reboot.log; /sbin/reboot >> /var/log/cron-reboot.log 2>&1; echo "[$(date "+%Y-%m-%d %H:%M:%S")] EXIT CODE: $?" >> /var/log/cron-reboot.log'

但这行太长，易出错。更优方案是写成独立脚本：

# /usr/local/bin/daily-reboot.sh #!/bin/bash LOGFILE="/var/log/cron-reboot.log" TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S") echo "[$TIMESTAMP] START" >> "$LOGFILE" # 执行健康检查... if [ ... ]; then /sbin/reboot echo "[$(date "+%Y-%m-%d %H:%M:%S")] REBOOT TRIGGERED" >> "$LOGFILE" else echo "[$(date "+%Y-%m-%d %H:%M:%S")] SKIPPED: health check failed" >> "$LOGFILE" fi

然后 crontab 调用：0 1 * * * /usr/local/bin/daily-reboot.sh。

注意：脚本必须有执行权限（chmod +x /usr/local/bin/daily-reboot.sh），且第一行#!/bin/bash指定解释器，避免 cron 调用/bin/sh导致 bash 特有语法（如[[ ]]）报错。

3.5 第五层防护：防误触与幂等性设计

crontab 编辑错误可能导致灾难：

• 把0 1 * * *误写成* * * * *→ 每分钟重启一次；
• 复制粘贴时多了一个空格，变成0 1 * * * /sbin/reboot（末尾空格）→ cron 解析失败，静默跳过；
• 多个用户同时编辑，覆盖彼此配置。

防御手段：

1. 使用crontab -e而非直接编辑/var/spool/cron/文件，前者有语法检查；
2. 添加注释和唯一标识：

   # === DAILY REBOOT FOR SERVICE STABILITY - DO NOT EDIT === # Managed by: admin@20240520 # Purpose: Prevent memory leak in legacy app (ref: JIRA-123) 0 1 * * * /usr/local/bin/daily-reboot.sh

3. 幂等性检查：在脚本开头加锁，防止同一时间多个实例并发执行：

   LOCKFILE="/tmp/daily-reboot.lock" if [ -f "$LOCKFILE" ] && kill -0 "$(cat $LOCKFILE)" > /dev/null 2>&1; then echo "[$(date)] Another instance is running" >> "$LOGFILE" exit 1 fi echo $$ > "$LOCKFILE" trap "rm -f $LOCKFILE" EXIT

3.6 第六层防护：时区一致性——为什么你的“凌晨1点”可能是别人的下午1点？

这是最隐蔽的坑。Linux 系统有两个时区概念：

• 系统时区（/etc/localtime）：date命令显示的时间；
• cron daemon 时区：由CRON_TZ环境变量或/etc/default/cron中的TZ设置，默认跟随系统时区，但可被覆盖。

问题来了：如果你的服务器在 UTC 时区，而业务要求“北京时间凌晨1点”，那么0 1 * * *实际在 UTC 时间 17:00（即北京时间次日1:00）触发，完全错乱。

解决方案：

• 方法1（推荐）：统一使用 UTC 时区，所有定时任务按 UTC 编写。例如，北京时间 01:00 = UTC 17:00，所以写0 17 * * *；
• 方法2：显式设置 CRON_TZ。在/etc/default/cron中添加：

  TZ=Asia/Shanghai

  然后重启 cron：systemctl restart cron；
• 方法3：在 crontab 文件顶部声明（仅对当前用户 crontab 有效）：

  CRON_TZ=Asia/Shanghai 0 1 * * * /usr/local/bin/daily-reboot.sh

实操验证：sudo systemctl status cron查看 cron 进程环境，或sudo cat /proc/$(pgrep cron)/environ | tr '\0' '\n' | grep TZ。

3.7 第七层防护：云环境与容器特殊处理

在 AWS EC2、阿里云 ECS 等云主机上，reboot命令行为与物理机不同：

• EC2：reboot会触发实例重启，但 EBS 卷保持挂载，实例 ID 不变；
• 阿里云：reboot等效于控制台“重启”，但需确保实例未启用“停机不收费”模式（否则会关机而非重启）；
• Docker 容器：容器内执行reboot通常无效，因为容器共享宿主机内核，reboot会尝试重启整个宿主机（需特权模式且极危险）。

正确做法：

• 云主机：直接使用reboot即可，但建议在脚本中加入云平台 SDK 检查（如aws ec2 describe-instances确认实例状态）；
• 容器：放弃reboot，改用kill 1（向容器 PID 1 发送信号，触发容器退出，由 docker daemon 重启）；
• Kubernetes：绝不要在 Pod 内执行 reboot，应通过kubectl rollout restart deployment/xxx或 HPA 策略实现滚动重启。

4. 实操过程与核心环节实现：从零搭建一个可审计、可回溯、可扩展的每日重启方案

4.1 准备工作：确认系统环境与权限

第一步永远是侦察。登录目标服务器，执行以下命令：

# 1. 确认 cron 是否运行 systemctl status cron || systemctl status crond # 2. 查看当前用户 crontab（如果是 root，用 sudo crontab -l） crontab -l # 3. 确认 reboot 命令位置和权限 which reboot ls -l $(which reboot) # 检查是否在 sudoers 中授权 sudo -l | grep reboot # 4. 查看时区设置 timedatectl status | grep "Time zone" # 检查 cron 当前时区 grep -i "tz\|cron_tz" /etc/default/cron /etc/crontab 2>/dev/null || echo "No CRON_TZ set" # 5. 创建日志目录（如果不存在） sudo mkdir -p /var/log/cron-reboot sudo chown root:root /var/log/cron-reboot sudo chmod 755 /var/log/cron-reboot

记录所有输出。如果which reboot返回空，说明系统无 reboot 命令（如某些 minimal 镜像），需安装sysvinit-tools或systemd。

4.2 创建可审计的重启脚本

新建/usr/local/bin/daily-reboot.sh：

#!/bin/bash # Daily reboot script with health check and logging # Version: 1.2 # Author: System Admin # Configuration LOGFILE="/var/log/cron-reboot/reboot-$(date +%Y%m).log" LOCKFILE="/tmp/daily-reboot.lock" REBOOT_CMD="/sbin/reboot" HEALTH_CHECKS=("mysqldump" "rsync" "backup.sh") # Ensure log directory exists mkdir -p "$(dirname "$LOGFILE")" chown root:root "$(dirname "$LOGFILE")" chmod 755 "$(dirname "$LOGFILE")" # Function to log messages log_message() { local level=$1 local msg=$2 echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$level] $msg" >> "$LOGFILE" } # Acquire lock if [ -f "$LOCKFILE" ] && kill -0 "$(cat "$LOCKFILE")" > /dev/null 2>&1; then log_message "WARN" "Another instance is running, exiting" exit 1 fi echo $$ > "$LOCKFILE" trap "rm -f $LOCKFILE" EXIT # Log start log_message "INFO" "Script started" # Health check: iterate through processes for proc in "${HEALTH_CHECKS[@]}"; do if pgrep -f "$proc" > /dev/null; then log_message "WARN" "Process '$proc' is running, skipping reboot" exit 0 fi done # All checks passed, proceed to reboot log_message "INFO" "All health checks passed, triggering reboot" $REBOOT_CMD log_message "ERROR" "Reboot command returned, this should not happen!" exit 1

赋予执行权限：

sudo chmod +x /usr/local/bin/daily-reboot.sh

手动测试脚本：

sudo /usr/local/bin/daily-reboot.sh # 此时应立即重启，但为安全，先注释掉 reboot 命令，测试日志和锁机制

4.3 配置 crontab 并设置时区

编辑 root 用户 crontab：

sudo crontab -e

添加以下内容（注意替换时区）：

# === DAILY REBOOT FOR SYSTEM STABILITY === # Timezone: Asia/Shanghai (UTC+8) # Trigger: Every day at 01:00 Beijing Time = 17:00 UTC # Managed by: admin@20240520 CRON_TZ=Asia/Shanghai 0 1 * * * /usr/local/bin/daily-reboot.sh

保存退出。crontab -e会自动检查语法，如有错误会提示。

4.4 验证 cron 是否加载新配置

cron 不需要重启即可加载新配置，但需确认：

# 查看 root crontab 是否包含新行 sudo crontab -l | grep -A2 -B2 "daily-reboot" # 检查 cron 日志（Ubuntu/Debian 在 /var/log/syslog，RHEL/CentOS 在 /var/log/cron） sudo tail -f /var/log/cron | grep "daily-reboot" # 或使用 journalctl sudo journalctl -u cron -f | grep "daily-reboot"

为验证是否真在 01:00 触发，可临时改为* * * * *（每分钟），观察日志是否每分钟出现一条记录，确认无误后再改回0 1 * * *。

4.5 日志轮转与磁盘空间管理

日志文件会无限增长，需配置 logrotate：
新建/etc/logrotate.d/cron-reboot：

/var/log/cron-reboot/*.log { daily missingok rotate 12 compress delaycompress notifempty create 644 root root sharedscripts postrotate # Reload cron if needed (some systems require it) if command -v systemctl >/dev/null 2>&1; then systemctl try-reload-or-restart cron 2>/dev/null || true fi endscript }

手动测试轮转：

sudo logrotate -d /etc/logrotate.d/cron-reboot # debug mode sudo logrotate -f /etc/logrotate.d/cron-reboot # force rotate

4.6 扩展性设计：如何将此方案用于其他定时任务？

本方案的核心价值在于其可扩展架构。只需修改脚本中的HEALTH_CHECKS数组和REBOOT_CMD，即可适配其他场景：

• 每日清理临时文件：REBOOT_CMD="find /tmp -type f -mtime +7 -delete"；
• 每周备份数据库：REBOOT_CMD="mysqldump -u root db_name > /backup/db_$(date +%F).sql"，并把0 1 * * *改为0 2 * * 0（周日2点）；
• 每小时检查磁盘空间：REBOOT_CMD="df -h | awk '\$5 > 90 {print \$0}'"，配合邮件告警。

关键是：所有业务逻辑封装在脚本中，crontab 只负责调度，职责分离，易于维护和审计。

5. 常见问题与排查技巧实录：那些让你抓狂的“明明写了却没执行”问题

5.1 问题速查表：从现象反推原因

5.2 深度排查：如何捕获 cron 的 stderr？

cron 默认丢弃 stdout/stderr，除非重定向。但有时即使重定向了，还是看不到错误。终极调试法：

# 在 crontab 中添加调试行 * * * * * /bin/sh -c 'env > /tmp/cron-env.log 2>&1; echo "PATH=$PATH" >> /tmp/cron-env.log; date >> /tmp/cron-env.log'

然后等待一分钟，查看/tmp/cron-env.log，你会看到 cron 的真实环境变量，尤其是 PATH 和 SHELL，这往往是command not found的根源。

5.3 经典案例复盘：某公司 CDN 节点批量宕机事件

事件背景：某 CDN 公司为解决边缘节点内存泄漏，给 200 台服务器统一部署0 1 * * * reboot。第三天凌晨，37 台节点在 01:03 左右陆续离线，监控报警。

根因分析：

• 所有节点使用@daily，解析为0 0 * * *（00:00），但运维误以为是 01:00；
• 00:00 正好是全网流量低谷，但某台核心 DNS 服务器也在 00:00 执行备份，导致短暂 DNS 解析失败；
• 37 台节点的 crontab 中，reboot命令写成了/usr/sbin/reboot（错误路径），实际应为/sbin/reboot，因此 reboot 失败，脚本退出，但无日志记录（未重定向 stderr）；
• 由于无健康检查，节点在 DNS 故障期间重启，导致服务注册失败，进入雪崩。

修复措施：

1. 全量替换@daily为0 1 * * *；
2. 所有 reboot 命令强制使用$(which reboot)动态获取路径；
3. 新增 DNS 可达性检查：if ! ping -c1 -w2 8.8.8.8 >/dev/null; then exit 1; fi；
4. 所有 crontab 行强制添加>> /var/log/cron-debug.log 2>&1。

踩过的坑：不要相信“大家都这么写”。上线前，必须在测试环境模拟真实负载（如用stress-ng占满 CPU 和内存），再触发 cron，观察全流程。

5.4 高级技巧：用 systemd journal 实现集中日志审计

如果系统使用 systemd，可将 cron 日志接入 journal：

# 修改 /etc/rsyslog.d/50-default.conf，取消注释这两行： #*.info;mail.none;authpriv.none;cron.none /var/log/messages #cron.* /var/log/cron # 重启 rsyslog sudo systemctl restart rsyslog # 然后用 journalctl 查看 cron 日志 sudo journalctl -u cron -o short-iso | grep "daily-reboot"

更进一步，可配置journalctl --since "2024-05-20 00:00:00" --until "2024-05-20 02:00:00"精确查询某次重启的完整上下文。

5.5 安全加固：防止 crontab 被恶意篡改

crontab 是高危配置，需防篡改：

• 文件权限：/var/spool/cron/目录权限应为700，root 所有；
• 审计日志：启用 auditd 监控：

  sudo auditctl -w /var/spool/cron/ -p wa -k cron-change # 查看审计日志：ausearch -k cron-change

• 配置备份：每天自动备份 crontab：

  # 添加到 root crontab 0 2 * * * /usr/bin/crontab -