系统崩溃后scp无法运行，必须先用Live USB挂载原磁盘（如sudo mount /dev/sda2 /mnt），再通过rsync -avz推送数据到远程主机，全程需验证路径、空间、权限及SSH连通性。
必须先挂载原系统磁盘，再用 scp 或 rsync 拷贝 —— 系统起不来时，scp 本身无法运行，得靠另一台能工作的 Linux 机器中转
系统完全崩溃后，scp 命令根本用不了
很多人第一反应是“用 scp 把文件传出去”，但这个想法在系统已无法启动时直接失效：没有 shell、没有 SSH 服务、scp 进程根本不存在。此时你面对的是一块裸磁盘，不是一台“服务器”。真正能用的只有外部可启动环境（如 Live USB）或另一台正常 Linux 机器。
- Live USB 启动后，原系统分区只是未挂载的块设备（如
/dev/sda2），需手动mount才能访问文件 - 若原系统用 LVM、加密（LUKS）、Btrfs 子卷等，挂载前得先激活/解密，否则
ls /mnt是空的 - 数据库文件（如
/var/lib/mysql/）不能直接拷贝就当“备份”——若 mysqld 正在写入时断电，文件可能处于不一致状态，恢复后大概率报错
从 Live USB 挂载后用 rsync 推送到远程机器
这是最可控的方式：Live 环境里有完整工具链，rsync 支持增量、压缩、保留权限，比 cp 更适合传大量数据。关键不是“怎么传”，而是“挂载路径对不对”和“推到哪台机器上”。
- 先确认目标分区：
lsblk -f查 ext4/xfs 类型，避开swap和 EFI 分区 - 挂载示例：
sudo mount /dev/sda2 /mnt；若挂载点含空格或特殊字符，路径必须加引号 - 推送命令示例：
rsync -avz --progress /mnt/home/user/project/ user@192.168.1.100:/backup/crash_recovery/ - 如果远程机器没开 SSH，或者防火墙拦了 22 端口，这条命令会卡在 “ssh: connect to host … port 22: Connection refused” —— 先用
ping和nc -zv 192.168.1.100 22确认通路
两台服务器直连时，用 scp -r 要小心路径末尾斜杠
当原服务器还能 ping 通但 SSH 登录失败（比如 systemd 卡死、sshd 未启动），别硬试 scp。但如果它其实只是“没加载桌面或没启网络服务”，而 SSH 本身还活着，那 scp 可能意外可用——但路径写错会导致静默覆盖或空目录。
-
scp -r /data user@10.10.10.20:/backup/→ 把/data目录整个复制过去，目标生成/backup/data/ -
scp -r /data/ user@10.10.10.20:/backup/→ 复制/data/下所有内容，目标是/backup/*，/data本身不出现 - 数据库目录（如
/var/lib/postgresql/）包含 socket 文件、PID 文件等运行时产物，直接拷会传一堆无效文件；应只传base/和global/子目录，且目标机 PostgreSQL 版本必须严格一致
导出前务必验证目标磁盘空间和用户权限
崩溃现场常伴随时间紧迫和操作慌乱，最容易忽略的是“远程机器有没有足够空间”和“目标用户能不能写”。df -h 和 id 不是摆设。
- 执行
ssh user@192.168.1.100 'df -h /backup'提前查空间，别等传到 95% 才发现只剩 2GB - 若远程目标路径属 root，而你用普通用户登录，
scp会报Permission denied (publickey)—— 实际是写入失败，错误信息极具误导性 - 遇到
Host key verification failed，不是网络问题，是~/.ssh/known_hosts里存了旧指纹，删掉对应行或加-o StrictHostKeyChecking=no（仅临时应急）
真正棘手的永远不是命令怎么写，而是你不知道磁盘是否已损坏、数据库文件是否已腐坏、远程机器的 SSH 配置是否悄悄改过。每次执行前多敲一行 ls -lh 和 ssh -v，比重装系统快得多。
