很多 Node.js 项目的源码并不复杂，但一旦没有及时备份，配置文件、脚本、环境约定和依赖记录丢失后，恢复成本往往比想象中更高。本文按照 Debian 上最常见的命令行流程，整理出手动打包、备份文件转移、是否单独保留 node_modules 以及脚本自动化几种做法，方便你根据项目大小和恢复需求判断该备份哪些内容。
先完成一次基础备份
最直接的做法，是先进入 Node.js 项目目录，再用 tar 生成一个 .tar.gz 压缩包。假设项目位于 /home/username/my-nodejs-project，先执行：
cd /home/username/my-nodejs-project然后把当前目录内容打包成备份文件：
tar -czvf my-nodejs-project-backup.tar.gz .这里的 . 表示“当前目录”，也就是你已经进入的项目目录。命令执行完成后，项目目录里会生成一个名为 my-nodejs-project-backup.tar.gz 的压缩包。
这条 tar 命令具体做了什么
这一步的重点不只是“打包”，而是把当前项目目录里的内容集中封装成一个文件，后续无论是复制到其他磁盘、远程同步，还是手动恢复，都会更方便。对于只想先保住源码和配置文件的场景，这已经是最基本也最实用的一步。
把备份文件移到独立目录
备份文件如果继续留在项目目录里，项目所在磁盘损坏、误删目录或批量清理文件时，备份本身也可能一起丢失。因此，打包完成后，最好立刻把压缩包移动到单独的备份目录。
先确认备份目录存在；如果没有，可以先创建：
mkdir -p /home/username/backups再将压缩包移过去：
mv my-nodejs-project-backup.tar.gz /home/username/backups/这样做的好处很直接：项目目录和备份目录分离，后续无论做版本清理、重新部署，还是误操作删除项目目录，至少还有一份独立的压缩包可用。
是否需要单独备份 node_modules
这一步是可选的。原始步骤里给出了单独备份 node_modules 的方式，适合网络受限、依赖来源不稳定，或者确实希望连当前已安装依赖一起保留下来的场景。
进入 node_modules 目录后，可以执行：
cd node_modules
tar -czvf node_modules-backup.tar.gz .
cd ..需要注意的是，node_modules 往往体积较大，单独打包会明显增加备份时间和存储占用。对于大多数可重复安装依赖的项目来说，通常优先保证源码、配置文件和锁文件完整即可；只有在依赖恢复成本高时，再考虑把 node_modules 一并备份。
用 Shell 脚本自动执行备份
如果你需要定期备份，手动重复输入命令就显得繁琐。这时可以把步骤写进一个脚本，后续直接运行脚本即可。
先创建脚本文件：
nano backup-nodejs-project.sh把下面内容写入文件：
#!/bin/bash
# 导航到项目目录
cd /home/username/my-nodejs-project
# 打包项目目录
tar -czvf my-nodejs-project-backup.tar.gz .
# 将备份文件移动到安全的位置
mv my-nodejs-project-backup.tar.gz /home/username/backups/
# （可选）备份node_modules目录
cd node_modules
tar -czvf node_modules-backup.tar.gz .
cd ..保存后，为脚本添加可执行权限：
chmod +x backup-nodejs-project.sh之后就可以直接运行：
./backup-nodejs-project.sh这种方式适合固定目录、固定命名的备份任务。尤其在个人项目、小型服务或测试环境中，它能把重复操作压缩成一次执行，减少漏掉步骤的概率。
备份完成后，恢复时怎么处理
完成备份后，后续如果需要恢复项目，基本思路就是把压缩文件解压，再把文件放回原始位置。原始说明里没有展开恢复命令，但恢复原则很明确：先找到你保存的 .tar.gz 备份文件，再解压到目标目录，最后根据项目情况补齐运行环境即可。
如果你此前还单独备份了 node_modules，恢复时也可以按同样思路处理。不过在实际使用中，是否恢复这部分内容，仍然要看项目是否更依赖“当前安装状态”，还是更依赖 package.json / 锁文件重新安装依赖。
