@torical 有考虑过这个方案但是不是说频繁的启停对硬盘的寿命会有比较大的影响么？要么一直转着要么冷备份比较好。

我目前的方案是主力盘不休眠，然后备份盘每周备份之后休眠。

顺带虽然劳动法执行不严密但是按照劳动法你这个行为使用了公司的设备和生产资料，也就是说按照法理上你 Nas 里面的小姐姐不是你的而是你老板的，是不是有一种莫名牛头人的感觉 （手动狗头）

楼上中肯，国内的的隐私协议是 txt 并不是 exe 只是政策原因卡一道而已，并不是有了这套机制所有厂商都尊重隐私了，而且就算厂商都合规了也会出现 “把隐私交给政府有何不可” 的问题，在国内谈隐私不如谈谈为什么 “大数据比你更了解你自己”。

可以用内网穿透工具但是不建议，一般公司的 IT 部门都不会同意你这么干的毕竟这肯定会有安全问题。一般公司有自己的内网也会有自己的 VPN 的，你应该是直接 VPN 回到公司内网去访问 NAS 而不是给 NAS 公网 IP 或者打洞。当然如果你是公司老板当我没说。

推荐 PVE 里面带 Debian 手动部署 Nas 的文件服务熟悉各种坑点，之后刚好可以练手如何将系统备份并迁移到新的 PVE 里。

@msg7086 我能接受网卡损坏导致按照 Mac 的配置无法上网，也能接受用新的网卡刚插上去没配置无法上网，因为这些和网络是相关的，但 “插一块 SSD 导致断网” 则是反直觉且不可预测的，只不过这个是各种方案折中妥协后必然会出现的一个潜在问题而我刚好遇到了而已。

只能说就很黑色幽默。

@msg7086 我之后查阅了资料了解到这个机制确实比 ethX 规则更进步的地方也知道有办法自己固定网卡名称。

槽点在于这个设计下会出现 “我就插了一块新的 SSD 怎么就忽然断网了？” 的情况，对于没那么熟悉 Linux 设计的人而言这个设计完全就是 “不可预测的”，而他们将这套机制命名为 “可预测网卡名称”…

如果他们用 “网卡自动命名机制” 这个名字我反而觉得可以理解是不得已而为之

@AkinoKaedeChan 用户如何在不知道这套机制存在的情况下避免这个问题，这才是槽点

@AkinoKaedeChan 我知道这个机制的存在是必要的是有意义的，但是他避免不了

[新手运维第一次增减 PCIe 设备后断网]

的问题，如果这个设计是无可奈何的话那么有人骂他这套设计不好一样也是无可奈何的

@AkinoKaedeChan 核心问题在于 enp2s0 这种命名规则本身是不稳定的，比如你插入一张新的网卡此时 enp2s0 可能指向新的网卡而原本的网卡则漂移到 enp3s0 去了。这个规则的设计者认为：

1. 保证网卡名称不冲突比保证网卡名称的稳定性更重要
2. 更短的网卡名称比 mac 地址更便于维护
3. 设计一套自动记忆 mac 地址和网卡名称的机制会增加系统复杂度且没必要
4. 再添加一个手动配置网卡地址的机制让开发者可以固定名称
5. 再添加一个再散列机制，保证自动网卡名称和用户固定的名称不冲突

这个设计是他们认为折中之后最好维护并且对绝大部分人用户最友好或者说最可以接受的机制，而在这套机制下新手用户注定会在第一次增减 PCIe 设备时遇到断网的问题，然后祝这个机制的开发者全家人身体健康之后去固定网卡地址。

说实话，如果他们把这套机制命名为 “网卡自动命名机制” 的话我还可以接受，但他们却将这套机制命名为：

[可预测网卡名称]

@AkinoKaedeChan 作为一个普通的软件开发者觉得这块明显设计有问题。

你看上面有些应该是有运维经验的大佬都提到他们公司是使用了 udev 来固定网卡名称，或者使用 pve 自带的功能来固定网卡名称，这说明固定网卡名称确实是一种更常见的需求，同时企业级的设备也需要固定网卡名称。

我的想法是，如果一个功能的最终下场是让大家不要使用这个功能，那么这个功能一开始就不应该存在或者应该有更好的设计。

肯定上 PVE 玩虚拟化但就算这样性能也过剩的，功耗就更是过剩了一年估摸 800~1000¥ 的电费，现在家庭宽带也没办法跑 PCDN 赚点电费，真想不出有什么生产力需求能顶得上这个消耗的

@poxiaogg 我使用的是 PVE 9.0 按理说已经是最新的系统了

@ragnaroks 可以用 Predictable network interface names 作为关键字搜索，就目前我找到的资料都是把这个当成一个 feature 或者新机制的，而非当成一个 bug

Tmux 和手机上的 Chrome