[ Bug ]: 最新版 image 备份到 github repo，如果超时或失败，会把新添加的 server 进行回滚

[FireTable]

问题描述

版本：fscarmen/argo-nezha:latest (近两天更新的

假如有 4 台 server A B C D，将 C D 移除，再添加一个 E，此时面板展示 A B E 如果触发备份（自动备份或者 ./backup.sh ），并且无法连接 github，将会变回 A B C D

复现步骤

1. A B C D => A B => A B E
2. 不允许设备 fq（ban 掉 github）
3. 触发备份

期望结果

A B C D => A B => A B E => 备份失败 => 依然是 A B E

可能的解决方案

1. backup 脚本 git push 增加超时 tag
2. stoped 后，如果发生错误，那么不应该丢失数据

[FireTable]

低优先级，是我把树莓派的 fq 禁止了，额外发现的问题

[fscarmen2]

我理解大概过程是

1. 原来 A B C D 时，你备份成功，并把“压缩包1”成功上传到 gh，本地记录为“数据1”， gh 上记录着最新数据为也为“数据1”
2. 改到 A B E 时，当手动或自动运行备份脚本 backup.sh 时，这时网络等原因上传备份不成功，导致“压缩包2”上传不了，但这时本地记录为新的“数据2”， gh 上的记录仍然为旧的 “数据1”，因为本地与gh上的不同，则会触发还原到 gh上的“数据1”，即是包含 A B C D 的。（如果本步上传“数据2”成功，则不会出现这样的bug）

对于这个用了这么多个月，还是极罕见事件 解决办法： 如果第2步上传数据不成功，不改本地记录为“数据2”，继续保持原来的“数据1”，这样就会与gh上的保持一致，不会触发恢复的动作，导致还原了不想要的数据。

由于这几天要处理 sing-box 脚本全家桶脚本，同时这个情况应该不会经常发生，预计稍过几天处理。

谢谢你的支持和宝贵意见。

[fscarmen2]

2023年10月7日已处理，加了上传备份到 github 的判断，如果成功，才改 /dbfile ，如果不成功，保持原来的值（这时与 github 的 README.md 记录的一致），则不会触发还原。保留原参数重新部署即可。

[FireTable]

verified and fixed backup 失败后依然正常显示 Backup Test，感谢 @fscarmen2

[fscarmen2]

现在设计是在后面上传数据的时候

[fscarmen2]

1.按你的情况，在你的环境下试试这个把backup.sh 开头几行参数复制，就是 GH_PAT=。。。。。。 GH_BACKUP_USER=。。。。。。 GH_EMAIL=。。。。。。 GH_REPO=。。。。。。

2.再运行这个

wget -qO- --header="Authorization: token $GH_PAT" https://api.github.com/repos/$GH_BACKUP_USER/$GH_REPO

3.上面那个应该不成功，最后运行

echo $?

麻烦把结果反馈一下。

[fscarmen2]

我针对你的反馈，又更新了一下，备份脚本一开始检测连不到github，后面的工作全部不做（停哪吒，备份，上传，开哪吒面板），直接提示并退出了，麻烦一下你测一下，是不是一开始就退出备份了。

[FireTable]

等 github action 跑完我看看

[fscarmen2]

你重新部署可以了，我再完善了一下，模拟了一下不能连 github 时的情况，已经测了

[FireTable]

可用 👍🏻

[fscarmen2]

其实你cn的机器，加个gh代理就能连啦，你主动不连的？

[FireTable]

其实你cn的机器，加个gh代理就能连啦，你主动不连的？

我上次不小心禁了 NAS 的 fq（在 shell clash 里面添加错黑名单了），无意中发现的 一般都是连着的 ：D