远程还原PSC备份卡顿主因是传输层不稳定、WinRM会话超时及NTFS附加属性阻塞；应改用rsync+ssh优化传输，调大WinRM超时，执行Unblock-File解除文件锁定。
远程还原 PSC 备份时卡在 pscp 或 scp 传输阶段
本质不是还原慢，而是传输层不稳定导致重传频繁、吞吐骤降。psc（powershell configuration）备份文件通常是压缩包（如 .zip 或 .psc1 自定义格式），但还原前必须完整传到目标服务器——一旦网络丢包率 >1%，scp 默认的加密+无拥塞控制机制就会反复重发 tcp 段，实际速度可能跌到标称带宽的 5% 以下。
实操建议：
- 改用
rsync+ssh，加--partial --progress --compress：断点续传 + 压缩传输（对文本类 PSC 配置效果明显），且rsync的滑动窗口比scp更适应高延迟链路 - 禁用
ssh的加密压缩（如果内网可信）：在~/.ssh/config中为该主机添加Compression no和Cipher aes128-gcm@openssh.com（比默认chacha20-poly1305@openssh.com更快） - 强制使用 IPv4（避免 DNS 双栈回退耗时）：
rsync -e "ssh -4" ...
还原脚本执行时反复连接超时或 Invoke-PSCCommand 报错
PSC 还原通常依赖远程 PowerShell 会话（如 Enter-PSSession 或 Invoke-Command），而默认会话超时是 60 秒，加上高延迟下 TLS 握手、Kerberos 票据获取失败，极易触发 The WinRM client received an HTTP status code of 401 或 Connection failed: timeout。
实操建议：
- 服务端调大 WinRM 超时：
winrm set winrm/config/winrs @{MaxTimeoutms="1800000"}（30 分钟） - 客户端显式指定认证协议和超时：
Invoke-Command -ComputerName srv01 -Credential $cred -ScriptBlock { ... } -SessionOption (New-PSSessionOption -OperationTimeout 1800000) - 避免交互式会话：不用
Enter-PSSession，全部走Invoke-Command单次执行，减少会话维持开销
Unblock-File 或解压后权限丢失导致还原失败
Windows 下从远程下载的 PSC 备份文件（尤其经浏览器或某些 FTP 工具中转）会被打上 NTFS Zone.Identifier 附加数据，导致 Import-PowerShellDataFile 或 Expand-Archive 直接报错 Cannot load configuration file because it is not digitally signed，这不是网络问题，但常被误判为“还原过程异常”。
实操建议：
- 传输完成后立即运行：
Unblock-File -Path "C:\backup\config.psd1"（注意路径必须是本地绝对路径） - 若用
Expand-Archive，务必加-Force参数，否则遇到已存在同名文件会静默跳过，后续还原找不到关键模块 - 检查解压后文件的
Attributes是否含ReadOnly：(Get-Item "C:\backup\config.psd1").Attributes，有则先Set-ItemProperty -Path "C:\backup\config.psd1" -Name Attributes -Value "Normal"
批量还原多个 PSC 配置时 CPU/内存飙升甚至 OOM
PowerShell 默认为每个 Invoke-Command 启一个新 powershell.exe 进程，若循环还原 20 个配置，就是 20 个独立进程加载 .NET Runtime + PowerShell Core，内存占用轻松破 2GB，加上远程 WinRM 的序列化开销，服务器响应变慢，进一步加剧网络超时连锁反应。
实操建议：
- 合并还原逻辑进单个脚本块，用
foreach在远程端内部遍历，而非本地循环调用Invoke-Command - 用
Start-Job -RunAs32（如果目标是旧版 x86 PowerShell）避免 64 位进程内存碎片问题 - 还原前手动清理远程会话：
Get-PSSession | Remove-PSSession，防止残留会话占满 WinRM 并发连接数（默认 5）
真正卡住你的往往不是带宽数字，而是 SSH 加密协商、WinRM 会话生命周期、NTFS 附加属性这三处——它们不报错，但会让整个流程像在泥里跑。
