@julyclyde 感谢, 跟这个条件多半有关系, 又测试了一段时间, 当 error count 增加时能正常触发异常流程发送邮件的. 就是不知道有没有配置能监控几个关键指标异常时一直发送邮件, 而不是产生变化才发送.

删除 state 文件没有作用. 我再找找其他配置, 看能不能在不改代码的前提下修改下这个行为.

代替 typora 的话有没有比较好的最佳实践或者插件推荐下? typora 主要是所见即所得, 几个好用的快捷键, 以及配合插件的复制上传图片到图床的功能 .

@seers 是的, 其实我想问的就是这个回滚靠不靠谱.

@mikewang 是的, 我认为核心问题其实在 ext4 的 data=journal, writeback 设计里就已经涉及了, 无非是 btrfs 的文件系统具体实现机制不同. 拜读了下提到的文章, 还真挺有意思, 原来也不是所有数据库都能处理崩溃一致性.


*其实我想问的问题本质上应该就是数据库软件能否正确处理崩溃一致性问题. *系统中其他的程序大部分只是写个日志, 损坏关系也不大. 提这个问题的原因是我把数据库相关的目录都关闭了 COW 属性, 如果不考虑碎片直接基于 btrfs 做快照, 会比 ext4 data=order 挂载安全, 因为 metadata 和 data 都有"日志", 虽然仍然保证不了崩溃瞬间业务的一致性.
当然, 还一个问题就是提到的内存数据没有刷回硬盘, 甚至硬盘缓存没有刷回存储介质.

@loading 只是请教下各种方法下的优劣势, 实际使用可以停机的. 比较关心 快照正在使用(正在向硬盘写数据)的数据库, 然后再用这份快照恢复会怎么样. 个人样本比较少, 不太容易测试得到可靠的结论.

@limon 原理应该都一样, 跟用什么发行版无关.

@cgglyle 没重启进程数据应该还跑在原来的子卷上, 比如安装 samba 前快照一次, 安装完成后恢复快照, 实际还能执行 samba 命令.

@msg7086 嗯, 这样莫不如直接重启了.

@mokiki 那请问 xfs 恢复根文件系统一般是怎么个做法? 需要重启吗? 类似我上面描述的这种情况, 不是系统损坏,而是想回退一些操作.

@documentzhangx66 请教下, 如果把 linux 的数据备份到 Windows Server 2019 上, 如何保留 linux 特有的文件系统权限? 比如软链接. 如果用 smb 这种协议应该是不行的, 请问是怎么处理的? 换成 nfs 共享?
毕竟要恢复的时候, 这些权限最好跟备份时是一模一样的.

第 2 个问题, 如果用 SyncBackPro 备份 + windows server 去重的话, linux 数据盘用 btrfs 是不是就没意义了? 还影响磁盘写入速度.

第 3 个问题, SyncBackPro 这个方案相比于 rsync 增量备份的优点是什么?

@rrfeng 交互模式是有告警的... 测试了下.

@leonshaw 对的, 但因为 Q'已经在 gitlab 上了, 所以并不能保证没人 pull 到这个 commit... 为了稳妥期间, 才选择 revert 的.

@optional .... 见我后面的补充, dev 分支存在比较久... 到 rebase 的时候不一定记得有这么个坑要填....知道有这个问题了还是比较好处理的.

@leonshaw 这个需求是比较奇怪, 原先最朴素的想法是这个问题在主线上的某个产品出现, 所以要求直接提 MR 给主线, 但是修改人提交的 MR TARGET branch 选错了, 变成了 dev 分支, 而 dev 分支上在开发其他产品, 跟这个 bug 没关系, 就直接 revert 了.
注: 这个 bug 改的不是公共代码, 而是主线上某个产品分支的代码, 而这个产品分支在 dev 上不涉及, 换句话说, dev 分支上在开发其他产品.

@godpeo 这是种解决方案, 但 dev 是公共分支, 在开发期间 reset 等价于修改公共分支的历史, 有较大的风险, 因此不太想这么做.

@rrfeng
> If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped and warnings will be issued (if the merge backend is used). For example, running git rebase master on the following history (in which A' and A introduce the same set of changes, but have different committer information):

https://git-scm.com/docs/git-rebase

@kyuuseiryuu 实际 dev 分支存在时间比较久... 不一定记得有这么个坑在.

@renmu 是指变基完成后再 revert 一遍吗? 实际因为 dev 分支开发比较久, 在变基时不一定记得有这个坑在里面...

@Pastsong 那 main 分支上的 Q 修改就丢了, 因为 dev 上没改这个.