1. 把默认机制吃透：restore 文件与 potfile 到底在干什么
先说一个很多人会忽略的事实：hashcat 不是没有自动保存，而是它默认已经有一套“进度保存”机制，只是大多数人从来没去了解过这套机制的工作原理，等到进度丢了才追悔莫及。
这套机制由两部分组成。第一是potfile，也就是“已破解密码档案”。hashcat 每跑出一个明文密码，都会立刻追加写入 potfile 文件，默认路径是当前工作目录下的hashcat.potfile，如果找不到就在家目录里创建。你可以随时用它去查已经出了哪些结果，跑包中途哪怕进程被直接杀死，已破解的部分也在文件里躺着，这部分永远不会丢，因为它是一条一条实时写盘的。
第二是restore 文件，这是整个“断点续跑”的核心。hashcat 会周期性地把当前攻击的整套状态写进.restore文件，默认存放在$HOME/.hashcat/restore目录下，文件名通常是会话名加.restore后缀。这个状态包含的内容比你想象的多：当前用的攻击模式（字典、掩码、混合等）、哈希类型、当前跑到的字典文件偏移位置、掩码的位移、规则文件的进度、设备分配情况、甚至 GPU 内核状态参数等等。也就是说，它记录的不是“跑出来了几个”，而是“我正跑在哪一步”。
很多人误以为中断之后重新跑一遍就行，这是最痛的误解。在大型字典和复杂规则集下，前面跑的几十个小时可能都是在探路，重跑一遍就像把一份已经改完的文档删了再重新打字，纯属浪费生命。所以搞清楚这两套机制，是解决“定时自动保存”问题的第一块地基。
另一个关键知识点是 restore 文件的写入频率。hashcat 默认是每 60 秒更新一次 restore 文件，这个间隔可以通过--restore-timer参数调整，比如设为 5 秒、10 秒，甚至 1 秒。很多人以为 hashcat 没有这个能力，其实只是没去调。到这里你应该已经意识到——所谓“定时自动保存”，hashcat 本身就给了一部分答案。
但为什么默认机制还不够用？我后面会说，这涉及到远程跑包、崩溃恢复、版本兼容、磁盘坏道等一系列现实问题，远比书面理论复杂。
2. 真正需要“定时自动保存”的场景，以及我踩过的坑
既然默认机制存在，那为什么还会有人问“hashcat 如何定时自动保存破译进度”？因为默认机制有四个场景下确实兜不住，而这四个场景恰恰是实际工作中最容易碰到的。
场景一：远程服务器跑包，机器被机房重启了。很多人在云主机或者办公室的一台显卡机器上跑大型任务，跑了两三天，结果运维半夜打补丁重启了服务器。hashcat 进程被系统强制杀死，SIGINT 根本没有机会触发，restore 文件只停留在最近一次周期更新的节点。损失多少，取决于你当时设置的刷新间隔。如果你用默认 60 秒，那其实损失可控；但如果你跑了整整三天，过程中某次崩溃让 restore 文件损坏，那就真的回到解放前了。
场景二：hashcat 版本升级 / 换了一台机器继续跑。这里有个大坑，restore 文件对 hashcat 版本极其敏感。同一个哈希类型，你从 hashcat 5.1 升到 6.0，旧版本生成的 restore 文件可能直接无法使用，hashcat 会报 “Restore file is incompatible”，然后拒绝恢复。又或者你从 A 服务器转战到 B 服务器，B 机器上 hashcat 版本一致，但它找不到你在 A 机器上指定的那个字典文件的绝对路径，一切恢复都会被相对路径问题卡死。
场景三：并行多会话跑同一个哈希列表。hashcat 支持用多个会话跑同一个任务，比如一个跑字典，一个跑掩码，各自都有独立的 restore 文件。这时候如果不对会话做规范化管理，很容易出现两个进程争抢同一份 restore 文件的情况，导致其中一个报错退出。更常见的是跑完一个会话后忘了备份，下一次那个文件被新一轮 session 覆盖掉，之前的进度就没了。
场景四：磁盘爆满 / 写入异常。我之前就碰到过一次现场：机器上挂了一个跑了两天的任务，为了节省空间，我把 potfile 和 restore 目录都放在系统盘，结果系统盘日志把空间撑满了，potfile 写入出现 IO 错误，hashcat 直接原地崩溃。这属于典型的“进度文件本身被环境搞死”的情况，如果当时有一个定期备份的机制，顶多损失几分钟的进度，不至于整个任务推倒重来。
这四个场景归结起来就是一句话：默认机制保证了“单机、单会话、进程被正常中断”情况下的存活率，但对人为操作失误、环境异常和版本漂移毫无防御力。所以“定时自动保存”的真正需求不是让 hashcat 再发明一个轮子，而是围绕 restore 文件和 potfile 建立一套外部备份体系，同时把内部刷新频率调到合理值。
这里给一个铁律：任何超过 6 小时的任务，跑之前先想清楚问题——“如果这台机器今晚原地蒸发，我能不能在另一台机器上第一时间恢复进度？”想不清楚这个问题的答案，就不要开始跑。
3. 断点续跑的完整链路：保存、恢复、验证的每一条命令
这一节我把从启动任务到中途恢复的完整命令链路列出来，每条命令我都会解释它存在的理由。
第一步：启动时明确指定会话名、potfile 路径、恢复文件目录。千万不要用默认的 session 名。默认会话名是hashcat，如果你同时在 A 目录跑一个任务、B 目录跑另一个，两个进程的 restore 文件就会互相打架。规范化做法是：
hashcat -m 22000 -a 0 hashes.txt rockyou.txt \ --session wpa_main \ --potfile-path /data/hashcat/potfile/wpa_main.pot \ --restore-file-path /data/hashcat/restore/wpa_main.restore \ --restore-timer 15--session的参数是整个恢复机制的主键。--restore-file-path很多人不知道，默认 stash 在$HOME/.hashcat/restore也够用，但如果你有多个任务、多台机器在跑，强烈建议给每个任务指定独立的 restore 文件路径，后续备份和恢复都清晰得多。
--restore-timer 15是我比较推荐的折中值。太短了频繁写盘影响性能，太长了恢复时损失大。默认 60 秒对短任务无所谓，但一旦跑超过 24 小时，损失一分钟都心疼。15 秒不会对 IO 造成明显压力，又能把进度损失控制在极小范围。
第二步是正常中断与恢复。hashcat 在收到 Ctrl+C（SIGINT）时，会先把当前完整状态写入 restore 文件，再安全退出。这属于最理想的中断方式。恢复时直接用：
hashcat --restore --session wpa_main注意，--restore模式下，大部分参数都不需要重新指定，hashcat 会从 restore 文件里读取攻击模式、字典路径、掩码等配置。你只需要保证三样东西就位：恢复文件本身存在、potfile 路径可写、所需的字典/规则文件还在原路径。这也是为什么我不建议用相对路径去指定字典和掩码，后面会展开讲。
第三步，也是最容易被忽略的：恢复后验证进度。很多人恢复完发现 hashcat 已经开始跑步了，就以为万事大吉，其实有几个验证点必须做。第一个是确认已破解数量：
hashcat --show --potfile-path /data/hashcat/potfile/wpa_main.pot第二个是确认还有多少没跑完：
hashcat --left --potfile-path /data/hashcat/potfile/wpa_main.pot这两个命令能直接告诉你恢复后的真实状态。尤其是--left，它列出的是当前攻击模式下还没尝试过的有效密码组合数量，如果恢复失败或者误导了，这个数字会和预期严重不符。我见过一个恢复成功的案例，表面上看一切正常，但--left显示的剩余量比中断前还多，查来查去发现是 potfile 路径写错了，hashcat 重新从零开始跑，白白浪费了半天。所以恢复完第一件事，输出--left看看数字，别急着去干别的。
第三步如果中途中断用的是kill -9、断电、或者机器重启，那 hashcat 来不及写 restore 文件，恢复时只能恢复到最近一次定时刷新点。这时候--restore-timer就显灵了，你设得越短，损失就越小。这个参数平时感受不到它的价值，真到了意外崩溃的那一天，你就知道 15 秒和 60 秒的差别有多大。
4. 进度丢失的典型排查过程：别急着重跑，先看这四个地方
我知道遇到进度丢失的时候，大多数人慌得不行，第一反应是重跑一遍。我强烈建议你先冷静下来，按照下面四条链路排查一遍，很多情况下进度其实没丢，只是被某种假象蒙住了。
排查点一：restore 文件到底在哪，文件名长什么样。这是最典型的翻车现场。你跑的时候用了--session mytask，恢复的时候却直接敲hashcat --restore，hashcat 会去找默认会话名的恢复文件，找不到就报No restore file found。这时候别急着骂工具，先在目录里看一眼：
ls -la /data/hashcat/restore/hashcat 的 restore 文件名有讲究，wpa_main.restore对应的是 sessionwpa_main。如果你不指定--restore-file-path，它会自动拼接出来，但路径不同、文件名带不带后缀，都会导致找不到。你用了--restore-file-path /data/hashcat/restore/wpa_main.restore启动，恢复时却只用--session wpa_main，hashcat 可能还是会去默认位置找。所以恢复时要么也带上同样的--restore-file-path，要么直接用完整路径指定。
排查点二：是不是 hashcat 版本不兼容了。如果你在 A 机器上跑，后来换了一台机器或者升级了 hashcat，恢复时大概率会看到类似 “Restore file is incompatible with current hashcat version” 的提示。原因在于 restore 文件里嵌入了版本信息和内部数据结构版本标记，跨版本加载会直接拒绝。这种情况下的唯一解是用旧版本 hashcat 恢复，或者接受损失，重跑。网上有些人说“手动改文件头”可以救回来，我没试成功过，也不建议你去试，容易把文件彻底搞坏。
排查点三：字典、掩码、规则文件的路径是否还活着。这是最隐蔽的坑。启动 hashcat 时，如果你用的是相对路径：
hashcat -m 22000 -a 0 hashes.txt ./dict/mydict.txt --session mytask恢复时 hashcat 会老老实实地去读 restore 文件里记录的那个路径，也就是./dict/mydict.txt。如果你的当前工作目录变了，或者目录结构被调整过，这个相对路径就失效了。hashcat 会直接报错退出，或者更恶心的是它不会报错，只是在日志里默默提示字典加载失败，然后进入一种奇怪的状态。所以从第一天起，字典、规则、掩码文件全部用绝对路径指定。这不是强迫症，这是断点续跑的保命操作。
排查点四：设备数量变化导致的恢复异常。假设中断前你用的是 4 张显卡并行，恢复时机器只剩 2 张可用了。hashcat 通常会降低设备利用率继续恢复，但有时候会因为内存分配或内核编译参数不同而报错。更常见的情况是恢复了，但速度明显下降，你以为正常，其实是设备位图没有正确恢复。我的经验是：遇到设备数量变化，先把--force这类参数去掉，让工具自动适配，如果还不行，就把-d设备参数显式指定当前可用设备，再试。
这四条排查完了，进度能不能救回来大概就有数了。真的一点都救不回来时，也别急着从头跑，看看有没有 potfile 备份、有没有跑包日志，至少把已经跑出的结果保下来。剩下的损失，就是没做外部备份的代价。
5. 自动备份脚本的一个实用思路：给跑包机上保险
讲完原理和排查，最后进入实操环节。我现在的做法不复杂，就是一套脚本加定时任务，把 restore 文件和 potfile 按小时备份到独立位置。这套机制我跑了很长时间，至少帮我在三次事故里把损失控制在 10 分钟以内。
核心思路其实很简单：hashcat 自己会定时写 restore 文件，我要做的只是把这个文件定期复制出去。但有几处细节必须注意：不能只备份一个文件，要连同 potfile 一起备份；不能覆盖备份目录，要按时间戳生成版本；备份目录不要和源文件在同一个磁盘分区。
下面是我用的一个参考脚本，你可以根据自己的路径改：
#!/bin/bash RESTORE_SRC="/data/hashcat/restore/" POTFILE_SRC="/data/hashcat/potfile/" BACKUP_BASE="/backup/hashcat_snapshots/" STAMP=$(date +%Y%m%d_%H%M%S) BACKUP_DIR="${BACKUP_BASE}/${STAMP}" mkdir -p "$BACKUP_DIR" cp -a "$RESTORE_SRC" "$BACKUP_DIR/restore/" cp -a "$POTFILE_SRC" "$BACKUP_DIR/potfile/" # 只保留最近 48 份快照，防止磁盘被撑爆 ls -1dt "$BACKUP_BASE"/*/ | tail -n +49 | xargs rm -rf -- 2>/dev/null # 顺手记录一下任务状态，方便恢复时快速检查 date > "$BACKUP_DIR/backup_time.txt"用crontab每小时执行一次，或者更频繁的话，用系统定时器也行：
0 * * * * /data/hashcat/scripts/backup_hashcat.sh这个脚本有两点值得解释。第一，cp -a保留文件属性和时间戳，因为 restore 文件里可能包含和文件时间相关的校验信息，用普通cp复制后属性变了，恢复时有一定概率触发怪问题。第二，为什么只保留 48 份？因为恢复点并不是越多越好，一份 restore 文件只要还在，它对应的就是“最近一次保存点”，旧快照基本上只是为了应对“最近一份文件损坏”的情况，留两天的量足够，再多只会把磁盘写满。
备份脚本部署之后，还有一件事值得做：定期验证备份是否可恢复。我每隔一段时间会挑一份备份目录，在一个干净的临时环境里试着加载一次，确认能出恢复界面再关掉。这个动作很多人懒得多做，但等你真正需要靠它救命时，发现备份文件本身是坏的，那才是真正的灾难。
另外一个增强思路是：如果你在局域网内有 NAS 或共享存储，把备份目录直接指到远程挂载点上，效果会更好。比如把BACKUP_BASE设为一个 NFS 或 SMB 挂载目录，这样即使整台机器物理损坏，备份也安然无恙。代价只是拷贝速度慢一点，但跑包任务本来就不抢这一秒两秒的 IO。
最后提醒一句和进度保存无关、但同样要命的事：不管跑包还是做密码恢复，一定要明确授权边界，只在你有合法授权的范围内操作。这既是职业底线，也是保护自己的基本常识。
6. 恢复操作的最后一道工序：把状态记在纸上
脚本备份解决了文件层面的问题，但实际操作中还有一个容易被忽略的环节：你自己得有一份“这个任务当初是怎么启动的”的笔记。我在跑大型任务前，会在一个文本文件里记录启动命令、hashcat 版本、字典路径、规则文件、具体参数、预计规模，甚至 GPU 型号和数量。这份笔记看起来土，但它和 restore 文件是互补的——restore 文件告诉 hashcat“跑到了哪里”，笔记告诉人类“这到底是个什么任务”。
为什么这份笔记重要？因为 restore 文件不是万能的，当你换机器恢复时，它只保证 hashcat 内部状态能被读取，但你的新机器有没有对应的字典文件、规则文件、GPU 驱动版本符不符合要求，这些机器层面的信息 restore 文件里写不进去，只能靠人脑。我在一次事故里就吃过亏：任务在 A 机器上启动，用的字典是 A 机器的本地路径，后来转到 B 机器恢复，B 机器上根本不存在那个路径，我靠着当初随手记的笔记才想起来要重新建一个软链接指向同一份字典，问题几分钟就解决了。如果不记笔记，光靠回忆，那个任务大概率就废了。
实际操作中我的习惯是这样的：每个任务建一个独立目录，目录里放notes.txt、字典文件、规则文件、hashes 文件，restore 和 potfile 的路径也统一在这个目录底下，然后用 session 名和目录名保持一致。这样整个任务的全部上下文都在一个文件夹里，备份脚本只需要打包这整个目录，恢复的时候拷回任意一台机器，路径不变，所有东西就都活着。
整理一下这套组合拳：
--session唯一命名的会话，恢复时按名索引。--restore-timer 15把内部保存频率调高，损失控制在 15 秒内。--restore-file-path和--potfile-path显式指定到任务专属目录。- 绝对路径启动所有字典和规则文件，拒绝相对路径。
- 定时脚本把整个任务目录快照到独立磁盘或远程存储。
- 手工维护一份 task notes，记录启动命令和机器环境。
这些东西看着琐碎，但每一条都是在真实事故里换来的。跑包本来就够耗时了，要是因为保存机制没做好重跑一次，那种挫败感我是深有体会。希望这套思路能帮你少走一段弯路。
