不是，timeshift恢复时，还会对当前@做快照，也就是说@会被创建一个名称为时间的副本

而你要还原的日期被重新定向为@

这里面的操作逻辑全部是btrfs的创建

https://github.com/linuxmint/timeshift/blob/cfd191e3c6f5908bc3ff95d0c969dd76d893846c/src/Core/Subvolume.vala

参考相关代码

我水平不行，一个是不懂语法，一个是代码规模一上来函数一多，我看着感觉比goto还乱😂 ……

大概看着好像是有删除@和@home的动作？

我也没懂它是怎么做到不影响当前@环境的情况下实现重启后切换快照的。直接删除的话会把当前系统搞坏。

我虚拟机里试了一次是可以的；物理机上试了一次，应该是正好赶上它自动提交删除任务了，最后只能用livecd来救了。

可能是删除@和重新做快照@之间的时间间隔要够短，趁它还没自动提交，先把快照重新做好。

我后面碰到了再试试把这两个命令一起执行。

sudo btrfs subvolume delete /mnt/@ && sudo btrfs subvolume snapshot /mnt/@20240101-0100 /mnt/@

用终端拉起timeshift 就能看到些细节啦，如图

貌似是mv ，btrfs好像会自动调整mount关系，看下图

btrfs yyds

不要delete ，太危险了

试着确实不能delete，不提交也不行……

现在看着这个更迷糊了……

点了回退快照之后，它这个先给@做了个快照，然后把新快照挂到根，但实际当前的根还是之前的@，然后重启后@变成了老的备份快照。

另外点了回退快照后，如果这时候在老快照目录里加个文件，重启后，@里面就没这个新加的文件。

我手动恢复过，说下自己对timeshift恢复快照的理解，不对的请大家指正

1 按日期创建目录后，将 @ @home mv 到 该目录下（由于子卷的id没变，只是路径变了，内核能自动处理，当前系统运行不受影响）

2 将备份子卷快照成 @ @home

3 重启系统后，按恢复后的子卷引导系统，完成系统恢复

ps ：回退完成后，老快照跟当前的子卷没啥关系了，增减文件，自然也看不到了

牛牛牛，我虚拟机里试了下，你是对的👍，多谢多谢！

那它还原快照的过程就是这个了：

1、打开timeshift，自动挂载对应分区（如根分区）到某个目录，如（/mnt/timeshift/backup）

2、创建快照时，它是先把@这个，mv到一个目录名带时间的目录下，btrfs sub list / -ts看确实ID没变，然后mount看它就是用的这个新的备份目录的@。

3、然后它再把要还原的快照，再做一个@快照，放到/mnt/timeshift/backup目录下，这时候查看，它的ID号是顺序+1。

由于上面2、3两步换了根分区位置，所以如果这时候直接touch /test，那这个test文件是写到目录名带时间的目录下的@中。而/mnt/timeshift/backup/@中还是保留和要还原的快照一致，没有这个test文件。

我也是请教了大佬，问了一下原理，应该大差不差

如果手头没有timeshift ，自己也可以手动恢复了