VPS折腾笔记

  先说结论 Windows 文件备份到云服务器，不用在服务器上装任何软件。用 FinalShell 的 SFTP 功能，手动把文件上传到服务器上的备份目录就行。服务器零改动，备份这件事只发生在你 Windows 这一侧。 为什么选手动 SFTP 备份方案一开始有好几个选项：装同步软件、搭网盘服务、写自动脚本。最后定的是最简单的那一个，理由就一条： 服务器上什么都不用装 。 云服务器上每多装一个服务，就多一个要维护、要更新、要防出问题的东西。只为备份文件，不值得。SFTP 是 SSH 自带的文件传输能力，服务器装好 SSH 就能用，Windows 这边用 FinalShell 连上去就能传，不用双方再装任何东西。 四步传上去 第一步：FinalShell 连上服务器。 正常登录就行，跟平时连服务器一样。 第二步：打开 SFTP 面板。 FinalShell 连上之后，界面下方（或者侧边）有 SFTP 的文件浏览区，左边是你 Windows 本地的文件，右边是服务器上的目录。 第三步：右边进备份目录。 在服务器那一侧，进到事先建好的备份目录，比如 /Backup_Win 。注意两点： Linux 路径区分大小写， /Backup_Win 和 /backup_win 是两个不同的地方，字母大小写要一模一样； 这个目录在根目录 / 下面，不是 /root 下面，别进错了。 第四步：左边选文件，上传。 在本地一侧选中要备份的文件或文件夹，拖到右边，或者点上传按钮。传完先别急着关，看一眼右边的目录，文件是不是都在。 备份前先想好：备什么 别一上来就把整个 C 盘往上搬。先定一个范围，比如： 文档、表格、自己写的稿子； 照片、重要的聊天记录备份； 浏览器导出的书签、软件的配置备份。 范围定好了，每次备份就是同一批东西，传得快，也容易发现有没有漏。 传完验证一下 手动备份最容易漏的一步就是"传完不检查"。养成习惯，传完做两件事： 对一下数量和大小：本地选了多少文件、右边是不是同样的数量； 抽查一个：随便在服务器侧双击打开一个刚传上去的文件，能打开就是真传上去了。 如果上传中途报失败，先别怀疑文件和服务器，按第二篇的经验： 先断开重连再试 ，FinalShell 会话挂久了 SFTP 通道发僵也会导致上传失败。 手动备份的短板，和升级路线 手动备份只有一...

  先说结论 Linux 改时区就一行命令，不用改配置文件、不用重启： timedatectl set-timezone Asia/Tokyo 改完立即生效，再跑 date 验证一下，显示的时间就是新时区的了。 我踩过的一次：时区要按机器所在地设，不是按人所在地设 有一次我要给几台云服务器改时区。第一反应是"时区设为当地"，顺手就把一台大阪的机器设成了 Asia/Shanghai——因为"当地"在我脑子里就是我所在的地方。 结果马上被纠正了： 服务器的时区，应该按服务器所在地设 。大阪的机器就是 Asia/Tokyo，美国盐湖城的机器就是 America/Denver。时区跟的是机器，不是跟人。 这个纠正很关键，因为后面所有看日志、排定时任务的人，都默认服务器时间就是当地时间。设错了，每次看日志都得在脑子里换算，迟早会看错一次。 三步：查、改、验 第一步：查现在是什么时区。 timedatectl 输出里有一行 Time zone: ，就是当前时区。新装的云服务器默认经常是 Etc/UTC（协调世界时），看着跟北京时间差 8 小时，日志时间全对不上本地感觉。 第二步：改。 timedatectl set-timezone Asia/Tokyo 把 Asia/Tokyo 换成你要的时区。不知道完整名字可以先列出来找： timedatectl list-timezones | grep -i tokyo 常见的几个：上海是 Asia/Shanghai，东京是 Asia/Tokyo，美国盐湖城是 America/Denver。 第三步：验。 date 显示的时间和时区缩写对了，就是改成了。改时区不需要重启机器，也不需要重启服务，立即生效。 两个容易混淆的概念 第一，服务器时区不等于浏览器显示的时区。 有一次我用浏览器走大阪节点的代理，打开一个显示时区的网站，页面上写着 SHANGHAI。当时差点以为是服务器时区没改对。其实不是：网站显示的时区，取的是你访问设备的系统时区（我电脑就是上海时区），跟服务器时区没关系。服务器时区只影响服务器自己的日志和定时任务。 第二，夏令时不用手动调。 像 America/Denver 这种带夏令时的时区，夏令时期间是 MDT（UTC-6），夏令时结束自动变 MST（UTC-7）。用 timedat...

先说结论 用 FinalShell 双击打开远程服务器上的文件，弹出“下载失败”，第一反应应该是 先断开连接、重新连一次，再试一次 。很多时候这一步就好了，根本不用动服务器上的任何东西。 我踩过一次：当时先怀疑文件权限，查了一圈服务器，文件可读、磁盘有空间、SSH 的 SFTP 配置也正常，最后断开重连，立刻就能打开了。问题不在文件，也不在服务器，在 FinalShell 那个挂了很久的会话本身。 症状长这样，你就按这篇来 典型的表现是“一半正常、一半不正常”，很容易误导人： 左侧文件列表还能正常显示，服务器明明连着； 双击某个文件想打开编辑，却报“下载失败”； 换个文件试，还是打不开。 看到这种“列表在、下载不通”的组合，先别急着下结论。文件列表走的是会话里还能用的部分，下载走的是已经发僵的那条 SFTP 通道，两边状态不一样，才会出现这种半正常现象。 正确的排查顺序 第一步：断开，重连，再打开。 在 FinalShell 里把当前连接断开，重新连上服务器，再双击同一个文件。如果能打开了，事情就结束了，不用再往下查。 第二步：还打不开，再看服务器侧。 按这个顺序过一遍，别跳步： 文件是不是真的存在、当前登录账号能不能读它； 服务器磁盘是不是满了； SSH 服务和 SFTP 相关配置有没有被改坏。 第三步：最后才考虑改权限。 只有确认了“确实是权限不够”再改。权限改错了比不改更麻烦：改松了是安全口子，改错了属主还可能把原来能跑的服务弄停。把“改权限”放在最后，本身就是在省事。 为什么重连会好 FinalShell 的会话挂久了，里面的 SFTP 通道会发僵：连接看着还在，实际上下载数据的那条路已经不通了。断开重连就是换一条新的通道，文件、服务器什么都没变，路通了自然就好了。 所以这条经验可以记成一句话： FinalShell 报下载失败，先重连，再查服务器，最后才动权限。 顺序反过来，前面查的那一圈全是白费功夫。

先说结论 甲骨文云免费套餐里，ARM 实例（A1.Flex）的免费额度是 全账号共用的一池子小时数 ，不是按台算的。一个月按 730 小时算， 2 核 12G 常开一个月，正好吃掉约 1460 OCPU 小时 + 8760 GB 小时，刚好卡在免费额度里面 。这就是为什么 2 核 12G 是"免费甜点"，往上调任何一点都会开始计费。 免费额度其实是两本账 很多人第一次算错，是因为把两种免费额度混成了一本。其实是分开的： 第一本账：A1.Flex，按小时池算。 全账号每月共用 1500 OCPU 小时 + 9000 GB 内存小时 （2026 年 6 月之后减半后的口径，之前是两倍）。一台机器开多久、什么规格，都从这个池子里扣。 第二本账：E2.1.Micro，按台数算。 全账号最多 2 台，和 A1 的小时池互不相干。E2 的机器不吃 A1 的池子，A1 的机器也不占 E2 的名额。 算账的时候先分清你开的是哪种，A1 只看小时池。 算一遍就明白了 一个月按 730 小时算（365 天 ÷ 12 个月 × 24 小时，实际月份有 28–31 天，数字会略有浮动）： 2 核 12G 常开 ：2 × 730 = 1460 OCPU 小时 ，12 × 730 = 8760 GB 小时 。对照 1500 / 9000 的池子，两项都刚好在里面，只剩一点零头。 4 核 24G 常开 ：4 × 730 = 2920 OCPU 小时，24 × 730 = 17520 GB 小时。两项全部超标，超出的部分按量计费。 哪怕只加到 3 核 18G ：3 × 730 = 2190 OCPU 小时，18 × 730 = 13140 GB 小时。还是超。 所以纪律很简单： A1 的规格只许保持 2 核 12G，往上调任何一点都会溢出 。再开第二台 A1 也一样，约等于每月多花几十美元量级的费用。 三个容易踩的坑 第一，免费不等于不会扣费。 升级成按量付费（PAYG）之后，闲置回收那套就不适用了：超免费额度的部分是真扣费，不是关机回收。所以规格纪律比以前更重要。 第二，公网 IPv4 不收费。 这一点我专门核对过甲骨文官方的虚拟网络定价页：公网 IPv4 地址本身没有按小时收费，别被网上搬错的价目表吓到。 第三，主区域定死不能改。 注册时选的主区域（比如大阪）是永...