ECC 在我这里是强烈建议，之所以不是必须是因为 ECC 在其他方面要做出相当多的妥协。
https://t.me/bupt_moe/2385 上个月刚碰到的 bitfilp

首先说一下 3-2-1 备份原则：3 份数据，2 个介质，1 份（物理）异地。
这就意味着一般来说你的数据存放方式是这样的
1. 保持随时可用的一份（比如群晖）
2. 移动硬盘一份
3. 异地（云服务或者离线硬盘）一份

然后是定价：
1. 云服务：这个取决于你们访问的频率，云服务一般都是存储便宜流量非常贵；
2. 本地硬盘：HC570 22TB 京东价格 3099 ，这个就是标杆价。

之后是管理：
如果你打算长期存储，定期验证数据是必不可少的（建议在线的一个月一次，离线的半年一次）。我自己是用 btrfs 并定期 scrub ，你们实验室可以自己确定一下验证数据的方案（如果你们的数据自带校验是最好的）。
压缩的话也就是自己压或者交给文件系统压，没什么特别多的说法。

碰到网络相关的问题，先抓包（有线抓两边，无线听中间）。

我建议网络分开单独处理

我自己现在公网接入是用的一家小机房提供商，阿里云只用 S3 服务

系统盘是啥 fs 啊，如果是 btrfs/zfs 可以直接 send 过去，xfs 好像也有工具。

上不上云取决于几点
1. 贵司的业务模型，是否存在突发流量？是否存在大量存储？
2. 有没有和云平台相对应 devops 团队？会不会被锁在一家云平台上？
3. 既然顾问说上云合算，贵司的运维团队是什么说法？
4. 上云之后如果云平台自己故障了，有没有相应的灾备方案？

安全相关的我觉得这个不构成上云的障碍，air-gap 的东西大家都做过。

顺便主密码我是这么解决的：手动记住一个非常长的复杂密码，形成肌肉记忆。

1. 有 passkey 的用 passkey ，这个不谈；
2. 如果服务支持 Google/Github/QQ 等大平台的三方登录，优先使用；
3. 支持 2FA 的，可以用一个短密码+2FA ；
4. 随机密码+密码管理器；
5. 如果支持手机密码重置的，把密码重置当作登录方式（

https://imgur.com/a/TDRHxHB
我自己的主力 NAS
https://imgur.com/a/tyAmhc4
测试 NAS （连了电视）
个人感觉：只要是一个正常的主机都可以承担 NAS 任务，你如果想用 NAS 干啥要先看一下你的预定任务的性能要求。

@drymonfidelia btrfs 给人灵的感觉是因为它的检查多，不会惯着不老实的设备，而且很不幸地是不老实的设备挺多的。
它真正出问题一般是因为你碰了 zoned 、subpage 、RAID5/6 以及这些特性的排列组合。

你这种没有啥明确需要单线程性能的可以把核数看的重一点。
J4105 都”还能用“的话我感觉随便上什么都只会比这个更好。

首先重要数据 3-2-1 备份。
其次你需要的”稳定性“是数据持久（即数据不会丢）还是数据可用（即一直在跑 SMB 服务）?
我自己的是一个 ArchLinux ，文件系统是 btrfs ，跑的 ECC 内存。因为我喜欢捡二手（甚至三、四手）所以可用性不是特别好（有过莫名其妙的、未查出原因的死机），但是迄今为止数据没丢过（ pacman.log 显示 2019-12-28 第一次安装），上面跑了 smbd 和 transmission ，有的时候会跑一些游戏服务器和 kernel 交叉编译。
uptime 保持不住因为我要重启更新 kernel 。
内存吃满是很正常的事情，毕竟放在那里也是放着不如拿来加速 IO ，要用的时候会让出来的。
我个人的经验就是上服务之前一定要搞清楚这个服务是干什么的，有无 plan B 。

如果是 linux 、同时不存 vm 和数据库的话可以考虑用 btrfs ，打快照备份方便很多

SSH 是典型的私钥签名，公钥验证……

要用 RAMMap.exe 看

正规 CA 是不允许替用户生成私钥的，如果 LZ 碰到了这种 CA （而不是什么代理商）可以举报。

可以用 cilium/pwru 查一查