kopia调用影子备份失败，未自动切换quicker调用

verity 创建于 2022-08-31 20:53

如果勾选 “通过quicker而不是kopia调用影子备份"一切都正常，仅在备份时能明显感觉到电脑CPU升高。

取消勾选，则仅在电脑重启后备份一次，之后则不再备份。

20：21分是quicker调用影子备份，20：21至20：38是Kopia调用影子备份，这之间一直有学习，但没有备份，20：38的备份是重启电脑后kopia的备份，之后再不备份

99版本，100版本均出现这种情况。

添加评论

回复内容

风未知 2022-08-31 21:31

自动切换是依靠控制台输出相关的错误代码来判断的，由于 95 更新对影子备份脚本进行了修改，之后我没有再遇到过错误的情况，因此也没有新的控制台的错误输出来进行自动切换的判断

我需要你进行以下操作来获取控制台的错误输出：

右键 quicker 托盘图标——终止动作——智能备份，确保动作没有运行
打开再关闭 sm，这样可以更改文件数据触发备份
在设置中取消 quicker 调用的勾选，我们要用 kopia 调用方式测试
按住 右 shift 键点击右键菜单项中的手动影子备份。如果 1 2 正常，应该不会弹出数据没有更改无需备份的提示。
当 4 完成后会弹出调试文件，先打开快照列表检查备份是否成功，如果成功了这份调试文件可能没有意义，我们需要备份失败了的调试文件
按 Ctrl F 搜索 2.1.4.1.2.1 或 kopia 影子备份，若搜不到就等待一会儿加载完全，复制控制台输出内容发出来

verity 回复风未知 2022-09-01 00:20 :

测试了好几次，但显示备份成功，调试文件可能没有意义，但我也贴出来了

verity 最后更新于 2022-09-01 00:20

verity 2022-09-01 00:14

1、2都没有问题

3、操作前是有勾选。

4、没有弹出数据没有更改无需备份的提示

5、弹出调试文件，但快照列表显示备份成功，测试了4-5次，重启电脑也测试了，还是一样，调试文件没有意义，但还是贴出来吧

Snapshotting 66810@desktop-hdff1aj:D:\001-Supermemo ...\n

\r | 0 hashing, 0 hashed (0 B), 1 cached (385 B), uploaded 0 B, estimated 78.9 MB (0.0%) 188h44m46s left\r / 1 hashing, 14 hashed (257.1 KB), 123 cached (20.4 MB), uploaded 206 B, estimated 78.9 MB (26.2%) 9s left\r - 0 hashing, 15 hashed (331.2 KB), 240 cached (25.5 MB), uploaded 206 B, estimated 78.9 MB (32.8%) 7s left\r \ 0 hashing, 15 hashed (331.2 KB), 334 cached (28.4 MB), uploaded 206 B, estimated 78.9 MB (36.5%) 6s left\r | 0 hashing, 18 hashed (354.1 KB), 465 cached (32.3 MB), uploaded 206 B, estimated 78.9 MB (41.4%) 5s left\r / 0 hashing, 18 hashed (354.1 KB), 669 cached (39.7 MB), uploaded 206 B, estimated 78.9 MB (50.8%) 4s left\r - 0 hashing, 18 hashed (354.1 KB), 815 cached (40.9 MB), uploaded 206 B, estimated 78.9 MB (52.3%) 3s left\r \ 0 hashing, 18 hashed (354.1 KB), 893 cached (41 MB), uploaded 206 B, estimated 78.9 MB (52.4%) 4s left \r | 0 hashing, 18 hashed (354.1 KB), 1032 cached (41.2 MB), uploaded 206 B, estimated 78.9 MB (52.7%) 4s left\r / 0 hashing, 18 hashed (354.1 KB), 1114 cached (42.2 MB), uploaded 206 B, estimated 78.9 MB (54.0%) 4s left\r - 0 hashing, 18 hashed (354.1 KB), 1252 cached (42.4 MB), uploaded 206 B, estimated 78.9 MB (54.2%) 4s left\r \ 0 hashing, 18 hashed (354.1 KB), 1322 cached (43.8 MB), uploaded 206 B, estimated 78.9 MB (56.0%) 5s left\r | 0 hashing, 18 hashed (354.1 KB), 1508 cached (44.2 MB), uploaded 206 B, estimated 78.9 MB (56.4%) 4s left\r / 0 hashing, 18 hashed (354.1 KB), 1633 cached (48.3 MB), uploaded 206 B, estimated 78.9 MB (61.7%) 3s left\r - 0 hashing, 18 hashed (354.1 KB), 1747 cached (48.8 MB), uploaded 206 B, estimated 78.9 MB (62.3%) 4s left\r \ 0 hashing, 18 hashed (354.1 KB), 1820 cached (51 MB), uploaded 206 B, estimated 78.9 MB (65.1%) 3s left \r | 0 hashing, 18 hashed (354.1 KB), 2019 cached (62.4 MB), uploaded 206 B, estimated 78.9 MB (79.5%) 1s left\r / 0 hashing, 18 hashed (354.1 KB), 2138 cached (65 MB), uploaded 206 B, estimated 78.9 MB (82.8%) 1s left \r - 0 hashing, 18 hashed (354.1 KB), 2321 cached (65.3 MB), uploaded 206 B, estimated 78.9 MB (83.3%) 1s left\r \ 0 hashing, 18 hashed (354.1 KB), 2454 cached (65.7 MB), uploaded 206 B, estimated 78.9 MB (83.7%) 1s left\r | 0 hashing, 18 hashed (354.1 KB), 2652 cached (66.1 MB), uploaded 206 B, estimated 78.9 MB (84.3%) 1s left\r / 0 hashing, 18 hashed (354.1 KB), 2705 cached (66.5 MB), uploaded 206 B, estimated 78.9 MB (84.8%) 1s left\r - 0 hashing, 18 hashed (354.1 KB), 2977 cached (69.5 MB), uploaded 206 B, estimated 78.9 MB (88.6%) 0s left\r \ 0 hashing, 18 hashed (354.1 KB), 3166 cached (72 MB), uploaded 206 B, estimated 78.9 MB (91.8%) 0s left \r | 0 hashing, 18 hashed (354.1 KB), 3493 cached (72.6 MB), uploaded 206 B, estimated 78.9 MB (92.5%) 0s left\r / 0 hashing, 18 hashed (354.1 KB), 3646 cached (72.8 MB), uploaded 206 B, estimated 78.9 MB (92.8%) 0s left\r - 0 hashing, 18 hashed (354.1 KB), 3759 cached (73.2 MB), uploaded 206 B, estimated 78.9 MB (93.3%) 0s left\r \ 0 hashing, 18 hashed (354.1 KB), 4041 cached (73.6 MB), uploaded 206 B, estimated 78.9 MB (93.7%) 0s left\r | 0 hashing, 18 hashed (354.1 KB), 4286 cached (74.2 MB), uploaded 206 B, estimated 78.9 MB (94.6%) 0s left\r / 0 hashing, 18 hashed (354.1 KB), 4394 cached (74.5 MB), uploaded 206 B, estimated 78.9 MB (94.9%) 0s left\r - 0 hashing, 18 hashed (354.1 KB), 4756 cached (75.1 MB), uploaded 206 B, estimated 78.9 MB (95.6%) 0s left\r \ 0 hashing, 18 hashed (354.1 KB), 5141 cached (75.5 MB), uploaded 206 B, estimated 78.9 MB (96.2%) 0s left\r | 0 hashing, 18 hashed (354.1 KB), 6041 cached (76.3 MB), uploaded 206 B, estimated 78.9 MB (97.2%) 0s left\r / 0 hashing, 28 hashed (381.3 KB), 6877 cached (77 MB), uploaded 206 B, estimated 78.9 MB (98.1%) 0s left \r * 0 hashing, 31 hashed (391.4 KB), 6905 cached (78.5 MB), uploaded 206 B, estimated 78.9 MB (100.0%) 0s left\n

Created snapshot with root kf2a122a38f88380ea098703ddf95b0d3 and ID 1de976c8437da36c0342af353fde4ad0 in 15s\n

风未知回复 verity 2022-09-01 00:25 :

“3、操作前是有勾选。”

我们需要的是不勾选，就像这样

毕竟是 kopia 调用方式有问题，要测的当然是不勾选时的情况

如果仍然无法捕获到错误的控制台输出，倒也可以换一种思路，如果没有生成快照也判定为出错。不过这样有可能会误判，能精准一点还是精准一点好

风未知最后更新于 2022-09-01 00:30

verity 回复 verity 2022-09-01 00:29 :

我描述的不是这个意思，我是说原来是有勾选，在按照你说的1-6步骤操作时，去掉了勾选，是用kopia调用的

verity 最后更新于 2022-09-01 00:31

风未知回复 verity 2022-09-01 00:35 :

暂时弄不到错误输出的话，我就先按照别的思路解决了。比如控制台输出不包含 Created 就判定为出错，再比如直接检查快照列表是否有变化。今天有点晚了，明天更新

verity 回复风未知 2022-09-01 00:42 :

感谢，辛苦啦，这样会不会每次都先用kopia不成功，再切换到Quicker调用，要是这样的话，不如直接勾选，一直用quicker备份，目的还是想用kopia调用影子备份，更无感。

verity 最后更新于 2022-09-01 00:44

风未知回复 verity 2022-09-01 01:06 :

我现在有一个怀疑，可能不是 kopia 调用失败了，是动作卡死了。

kopia 调用和 quicker 调用在动作里有一个很大的区别，quicker 不捕获控制台输出，kopia 捕获。之所以 quicker 不捕获，是因为有一位用户在捕获控制台输出的情况下会在那一步卡死。kopia 在 95 版本前一直没法用，也就没听过这方面的问题。但现在想来，我觉得很有可能是因为捕获控制台输出导致的卡死，卡死了自然后面就不会再有备份了。也就是说，如果直接不捕获控制台输出，可能啥问题都没有了

我会考虑往这个方向更新，你可以先按照以下方式修改动作尝试一下：

右键编辑动作，搜索 kopia 影子备份回车