以前にサーバーが攻撃されたため、データベースは常にランサムウェアです前の記事では、セキュリティを向上させるためのいくつかの方法を説明しましたが、それでもまだ信頼性は低いと思います。また、スケジュールバックアップのスクリプトに関する以前の調査と組み合わせて、今日はスケジュールバックアップデータに関する記事を書きます。
1つは、スクリプト
私のMySQLはdockerを使用してデプロイされているので、バックアップコマンドはdockerを介してコンテナーに入り、バックアップコマンドを実行します。
#!/bin/bash
# 设置mysql的登录用户名和密码(根据实际情况填写)
mysql_user="root"
mysql_password="root"
mysql_host="localhost"
mysql_port="3306"
mysql_charset="utf8mb4"
# 备份文件存放地址(根据实际情况填写)
backup_location=/usr/local
# 是否删除过期数据
expire_backup_delete="ON"
expire_days=7
backup_time=`date +%Y%m%d%H%M`
backup_dir=$backup_location
welcome_msg="Welcome to use MySQL backup tools!"
# 备份指定数据库中数据(此处假设数据库是mysql_backup_test)
docker exec -it mysql mysqldump -h$mysql_host -P$mysql_port -u$mysql_user -p$mysql_password -B test1 > $backup_dir/mysql_backup_test-$backup_time.sql
# 删除过期数据
if [ "$expire_backup_delete" == "ON" -a "$backup_location" != "" ];then
`find $backup_location/ -type f -mtime +$expire_days | xargs rm -rf`
echo "Expired backup data delete complete!"
fi
注：
上記は主に変数の定義であり、詳細に説明されていますが、ここでは主にバックアップコマンドについて説明します
docker exec -it mysql mysqldump -h$mysql_host -P$mysql_port -u$mysql_user -p$mysql_password -B test1 > $backup_dir/mysql_backup_test-$backup_time.sql
これらは別にして、コンテナに入ってバックアップコマンドをテストし、最初にコマンドを分解して分析しましょう
# docker进入容器的命令
docker exec -it 容器名
# 备份数据库的命令
mysqldump -uroot -p123456 -B 数据库名 > /usr/111.sql
接続します（これは私の注文です。実際の状況に応じて変更できます）
docker exec -it mysql01 mysqldump -uroot -p123456 -B cj > $backup_dir/cj-$backup_time.sql
2、タイミングタスク
# 启动定时任务
crontab -e
# 将定时任务写入其中 分 时 日 月 年
* * * * * /bin/bash /usr/data/backup/backupdb.sh
# 查看定时任务列表
crontab -l
2020年7月6日19:43:44の2番目の補足
今朝起きて、サーバーに行って、昨夜書かれたスケジュールされたバックアップスクリプトが正常に実行されたかどうかを確認します。バックアップディレクトリに移動して、ファイルが生成されたことを確認します。その後、猫チェックは出力がないことを発見しました。奇妙です。手動での実行は昨日成功しましたが、crontabに入れられました。どうして？
この問題で、私は長い間、長い間、そして長い間、Baiduを利用してきました。一般的に、インターネットには2つのケースがあります。1つ目は、mysqldumpコマンドのパスが完全に提供されていないこと、2つ目は、環境変数が追加されていないことです。
これらの2つの方向を組み合わせて、すべての解決策を試しましたが、すべて失敗に終わりました。
失敗1、mysqldumpコマンドのパスを完了する
。MySQLをサーバーに直接インストールする場合、それほど複雑ではない可能性があります。ほとんどのオンラインソリューションはこれに基づいていますが、MySQLはdockerによってインストールされます。そのため、彼のmysqldumpの場所を見つけるためにコンテナーに入る必要があります。次に完了する
docker exec -it mysql01 /usr/bin/mysqldump -uroot -p123456 -B cj > $backup_dir/cj-$backup_time.sql
このうち、/ usr / binはコンテナー内のmysqldumpファイルのパスです。
結果：失敗
失敗2、環境変数
way1を追加：スクリプトに追加
ソース/ etc / profileに
は、ここで注釈が付けられています
結果：失敗
way2：タスクを実行するスクリプトを追加します
crontab -e
*/1 0 * * * source profile；/home/backup/mysql_backup_test_backup.sh 2>&1
结果：失败
然后又林林总总找了很多办法，但是出发点和方向都是这两个，而且也一直没有成功，看网上信誓旦旦说的一定成功，评论也有成功的，可是我就成功不了，搞得我很怀疑人生；最后我开始怀疑这个命令是不是有问题？虽然手动执行是正常的，也许因为什么原因，自动执行就出现问题了，于是我开始百度“crontab执行docker”，不得不说，百度对方向真的很重要，划重点。一百度就找到问题了
跟加了 -it参数有关系
Your docker exec command says it needs “pseudo terminal and runs in interactive mode” (-it flags) while cron doesn’t attach to any TTYs.
大致意思 exec 加了 -it 参数就开启了一个终端，计划任务是无法进入任何终端的。
把 docker exec 的参数 -it 去掉后问题解决了。
看了这个我才知道原来是这个原因，然后再想想之前他们的帖子，貌似也确实没有 -it的参数，然后放入定时任务执行，果然成功了，哎，真艰辛！
docker exec mysql01 mysqldump -uroot -p123456 -B cj > $backup_dir/cj-$backup_time.sql