基于crontab和腾讯云oss备份方案

网站备份

笔者因为方便，所以使用halo开源框架搭建了自己的博客系统。但是因为某一天在服务器上测试安装脚本，导致服务器不可逆损坏，只能重装系统。前期考虑到只是一个个人博客系统，因此没考虑数据备份，导致辛辛苦苦记录的文章全部丢失。

因为笔者博客部署方式是以Docker Compose的方式部署，数据库数据和代码均在指定文件夹下，因此笔者只需要定时备份当前文件夹下的所有文件即可。数据备份频率为每天一次，通过crontab定时执行备份脚本，并实时上传到腾讯云oss对象存储中。

定时备份

安装COSCMD工具

• 检查服务器是否安装python和pip

• 利用pip安装coscmd

  pip install coscmd

创建配置oss文件~/.oss.conf

[common]
secret_id = 密钥ID
secret_key = 密钥Key
bucket = 存储桶名称
region = 存储桶地域
# 其他参数默认就好
max_thread = 5
part_size = 1
retry = 5
timeout = 60
schema = https
verify = md5
anonymous = False

测试coscmd是否配置成功

coscmd upload 源文件 存储桶所在目录

编写shell脚本backup_website.sh执行备份任务

#!/bin/bash

# 设置备份目录和文件名（绝对目录）
backup_dir="/backup_website"
backup_file="blog_backup_$(date +'%Y%m%d_%H%M%S').zip"

# 当前网站文件所在绝对目录
website_dir="/website/blog"

# 创建备份zip包
zip -r "$backup_dir/$backup_file" "$website_dir"

# 上传文件到 腾讯云 oss 对象存储中
echo "网站文件夹已备份并压缩为$backup_file"
coscmd upload "$backup_dir/$backup_file" "blog/"

# 定期清理旧备份文件
max_backup_files=5
cd "$backup_dir"

# 列出备份文件并按照修改时间进行排序
backup_files=($(ls -t docker_blog_*.zip))

# 计算备份文件数量
num_backup_files=${#backup_files[@]}

# 如果备份文件数量超过最大允许值，删除一个最老的备份文件
if [ $num_backup_files -gt $max_backup_files ]; then
    rm "${backup_files[$num_backup_files - 1]}"
    # 强制删除 oss 文件压缩包，只保留5个（ps：不强制删除的话，执行 coscmd delete 需要二次确认导致删除失败）
    coscmd delete blog/"${backup_files[$num_backup_files - 1]}" -f
    echo "已删除一个最老的备份文件 ${backup_files[$num_backup_files - 1]}"
fi

赋予文件执行权限

chmod 755 backup_website.sh

测试shell脚本

sudo ./backup_website.sh

配置定期执行shell脚本

查看crontab帮助信息

# 查看帮助
crontab -h

# 输出信息
crontab: invalid option -- 'h'
crontab: usage error: unrecognized option
usage:  crontab [-u user] file
        crontab [ -u user ] [ -i ] { -e | -l | -r }
                (default operation is replace, per 1003.2)
        -e      (edit user's crontab) # 编辑某个用户的crontab文件内容。如果不指定用户，则表示编辑当前用户的crontab文件。
        -l      (list user's crontab) # 显示某个用户的crontab文件内容，如果不指定用户，则表示显示当前用户的crontab文件内容。
        -r      (delete user's crontab) # 从/var/spool/cron目录中删除某个用户的crontab文件，如果不指定用户，则默认删除当前用户的crontab文件。
        -i      (prompt before deleting user's crontab) # 在删除用户的crontab文件时给确认提示。

配置定时任务

# 配置定期执行脚本命令
vim /etc/crontab

# 设置每天凌晨4点执行一次 
# 建议使用管理员账户，/path/to/backup_website.sh 为执行脚本绝对路径
0 4 * * * 用户 /path/to/backup_website.sh

重新启动cron服务

请注意，只有在更改了crontab文件后，才需要重启cron服务以使更改生效。通常情况下，修改crontab文件后，cron服务会自动加载更改，因此不需要频繁重启。只有在你怀疑服务出现问题或更改未生效时，才需要进行重启。

# 重新启动
sudo systemctl restart cron

# 查看状态
sudo systemctl status cron

# 输出：
cron.service - Regular background program processing daemon
     Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-08-01 00:51:02 CST; 9s ago
       Docs: man:cron(8)
   Main PID: 3420348 (cron)
      Tasks: 50 (limit: 4612)
     Memory: 307.0M
     CGroup: /system.slice/cron.service
             ├─   1936 /usr/local/qcloud/stargate/bin/sgagent -d
             ├─   5994 /usr/local/qcloud/YunJing/YDEyes/YDService
             ├─   6085 /usr/local/qcloud/YunJing/YDLive/YDLive
             ├─   6263 /bin/sh -c sleep 100
             ├─2642799 barad_agent
             ├─2642806 barad_agent
             ├─2642807 barad_agent
             └─3420348 /usr/sbin/cron -f

Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: cron.service: Found left-over process 6263 (sh) in control group while starting unit. Ignoring.
Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: cron.service: Found left-over process 2642799 (barad_agent) in control group while starting unit. Ignoring.
Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: cron.service: Found left-over process 2642806 (barad_agent) in control group while starting unit. Ignoring.
Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: cron.service: Found left-over process 2642807 (barad_agent) in control group while starting unit. Ignoring.
Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Aug 01 00:51:02 VM-0-15-ubuntu systemd[1]: Started Regular background program processing daemon.

通过如上配置，服务器就会在每天凌晨4点对网站文件进行压缩，并发送到oss对象存储桶中。在服务器备份文件夹下和oss对象存储桶中，会保留最近的5个压缩文件。后期服务器再次出现损坏的时候，只需要解压缩备份的文件，重新执行docker-compose up -d 命令即可恢复网站。

参考文档

• halo：docs.halo.run/getting-sta...
• crontab：baike.baidu.com/item/cronta...
• coscmd：cloud.tencent.com/document/pr...